Kampania MageCart ukrywa skimmer kart płatniczych w jednopíkselowym obrazie SVG

securitybeztabu.pl 10 godzin temu

Wprowadzenie do problemu / definicja

Nowa kampania wymierzona w sklepy internetowe opartych na Magento pokazuje, jak ewoluuje współczesny web skimming. Atakujący ukrywają złośliwy kod kradnący dane kart płatniczych wewnątrz pozornie niegroźnego elementu SVG o rozmiarze 1×1 piksela. Taka technika utrudnia wykrycie infekcji przez klasyczne skanery integralności i narzędzia monitorujące zewnętrzne skrypty JavaScript.

W skrócie

Badacze wykryli szeroko zakrojoną kampanię obejmującą blisko 100 sklepów internetowych korzystających z Magento. Złośliwy ładunek jest osadzany bezpośrednio w kodzie HTML jako niewidoczny element SVG z atrybutem onload, który uruchamia zakodowany w Base64 skimmer płatności. Po kliknięciu przycisku finalizacji zakupu ofiara widzi fałszywą nakładkę „Secure Checkout”, zbierającą dane karty oraz informacje rozliczeniowe. Skradzione dane są walidowane i przesyłane do infrastruktury atakujących w postaci zaciemnionego JSON-a.

Kontekst / historia

Incydent wpisuje się w znany od lat model działania grup określanych zbiorczo jako MageCart, które specjalizują się w kompromitowaniu platform e-commerce i przechwytywaniu danych płatniczych podczas procesu zakupowego. W tym przypadku analitycy wiążą kampanię z falą ataków wykorzystujących lukę PolyShell, ujawnioną w połowie marca 2026 roku. Problem dotyczy stabilnych wdrożeń Magento Open Source oraz Adobe Commerce 2 i umożliwia nieautoryzowane wykonanie kodu oraz przejęcie kont.

Wcześniejsze kampanie web skimmingu często polegały na dołączaniu zewnętrznych skryptów z podejrzanych domen lub modyfikowaniu istniejących bibliotek front-endowych. Obecna technika stanowi rozwinięcie tego podejścia: cały ładunek działa inline, bez konieczności ładowania osobnego pliku JavaScript, co znacząco obniża wykrywalność.

Analiza techniczna

Mechanizm ataku opiera się na osadzeniu w kodzie strony elementu SVG o wymiarach 1×1 piksela. Sam obraz nie pełni istotnej funkcji wizualnej, ale służy jako nośnik złośliwego kodu. Kluczowym elementem jest atrybut onload, w którym umieszczono cały payload skimmera. Kod ten został zakodowany przy użyciu atob(), a następnie uruchamiany z wykorzystaniem setTimeout().

Z perspektywy obronnej jest to istotne z kilku powodów. Po pierwsze, atak nie wymaga odwołań do zewnętrznych źródeł skryptów, które często są monitorowane przez mechanizmy CSP, WAF-y lub systemy wykrywania zmian w kodzie aplikacji. Po drugie, złośliwa logika ukryta w pojedynczym atrybucie HTML może zostać przeoczona podczas pobieżnego przeglądu plików szablonów lub wygenerowanego DOM.

Po aktywacji skrypt przechwytuje interakcję użytkownika z procesem checkout. Zamiast natychmiastowego przejścia do adekwatnej płatności ofiara otrzymuje wiarygodnie wyglądającą nakładkę formularza. Interfejs ten zbiera:

numer karty,
datę ważności,
kod CVV,
dane rozliczeniowe.

Dane wejściowe są dodatkowo sprawdzane po stronie złośliwego skryptu. Wykorzystywana jest między innymi walidacja algorytmem Luhna, dzięki czemu do operatora kampanii trafiają przede wszystkim rekordy o wysokiej jakości. Następnie informacje są serializowane do formatu JSON, szyfrowane prostą operacją XOR i dodatkowo zaciemniane przez kodowanie Base64 przed eksfiltracją.

Badacze wskazali także konkretne artefakty, które mogą pomóc w detekcji kompromitacji. Należą do nich:

ukryte znaczniki SVG zawierające onload i wywołania atob(),
obecność klucza _mgx_cv w localStorage przeglądarki,
żądania do ścieżki /fb_metrics.php,
komunikacja z nieznanymi domenami podszywającymi się pod usługi analityczne.

Konsekwencje / ryzyko

Ryzyko dla operatorów sklepów internetowych jest wysokie. Najbardziej oczywistą konsekwencją jest kradzież danych kart płatniczych klientów, co może prowadzić do strat finansowych, chargebacków, sporów z operatorami płatności oraz odpowiedzialności regulacyjnej. Równie istotne są skutki reputacyjne — kompromitacja procesu checkout bezpośrednio uderza w zaufanie do marki.

Dla zespołów bezpieczeństwa niepokojące jest również to, iż analizowana technika omija część standardowych metod wykrywania. Organizacje koncentrujące się wyłącznie na monitorowaniu zewnętrznych skryptów, zmian sum kontrolnych zasobów statycznych lub reputacji domen mogą nie zauważyć infekcji osadzonej bezpośrednio w kodzie HTML. Oznacza to potrzebę głębszej inspekcji DOM, atrybutów zdarzeń i nietypowych fragmentów inline scriptingu.

Jeżeli faktycznie punktem wejścia była luka PolyShell, zagrożenie ma także wymiar systemowy. Atakujący nie tylko wstrzykują skimmer, ale potencjalnie uzyskują szerszy dostęp do aplikacji, kont administracyjnych oraz środowiska serwera, co otwiera drogę do dalszej eskalacji i trwałej obecności w infrastrukturze.

Rekomendacje

Administratorzy Magento i Adobe Commerce powinni potraktować ten przypadek jako sygnał do natychmiastowego przeglądu bezpieczeństwa środowiska. W praktyce warto wdrożyć następujące działania:

Przeskanować pliki aplikacji i wygenerowany HTML pod kątem ukrytych elementów SVG z atrybutami onload, wywołaniami atob() oraz podejrzanymi łańcuchami Base64.
Zweryfikować, czy w przeglądarce użytkowników lub w środowisku testowym nie pojawia się klucz _mgx_cv w localStorage.
Monitorować ruch wychodzący aplikacji oraz przeglądarki klienta do nietypowych endpointów, w tym do ścieżek imitujących telemetrię lub analitykę, takich jak /fb_metrics.php.
Wdrożyć ścisłe polityki bezpieczeństwa treści, ograniczające możliwość wykonywania nieautoryzowanego kodu inline, o ile architektura sklepu na to pozwala.
Przeanalizować logi aplikacyjne, logi serwera WWW oraz historię zmian plików pod kątem śladów eksploatacji luki PolyShell.
Zastosować wszystkie dostępne poprawki, obejścia i mitigacje producenta, a tam gdzie to możliwe przejść na wersję systemu zawierającą poprawkę bezpieczeństwa.
Uruchomić ciągły monitoring integralności checkoutu, obejmujący nie tylko pliki JavaScript, ale także szablony, atrybuty DOM i dynamicznie generowany kod HTML.
Przygotować procedurę reakcji na incydent uwzględniającą obowiązki prawne, analizę zakresu wycieku oraz komunikację z operatorem płatności i klientami.

W środowiskach produkcyjnych warto również rozważyć izolację procesu płatności, segmentację paneli administracyjnych, wymuszenie MFA dla kont uprzywilejowanych oraz audyt rozszerzeń i modułów firm trzecich. To szczególnie ważne w przypadku platform e-commerce, gdzie kompromitacja pojedynczego komponentu może gwałtownie przełożyć się na masowy wyciek danych.

Podsumowanie

Opisany incydent pokazuje, iż web skimming staje się coraz bardziej dyskretny i lepiej dopasowany do mechanizmów obronnych stosowanych w nowoczesnym e-commerce. Ukrycie skimmera w jednopíkselowym obrazie SVG z kodem osadzonym w atrybucie onload to skuteczna metoda obejścia wielu tradycyjnych kontroli bezpieczeństwa. Dla operatorów Magento oznacza to konieczność rozszerzenia detekcji poza klasyczne wskaźniki kompromitacji i objęcia monitoringiem również nietypowych elementów HTML oraz logiki inline. W praktyce najważniejsze pozostają szybkie łatanie podatności, kontrola integralności checkoutu i bieżąca analiza ruchu eksfiltracyjnego.