Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa opisali nowy wariant skimmera płatniczego, który wykorzystuje kanały danych WebRTC do pobierania złośliwego ładunku i eksfiltracji danych kartowych ze sklepów internetowych. To istotna zmiana w krajobrazie zagrożeń dla e-commerce, ponieważ mechanizm ten pozwala ominąć część typowych kontroli opartych na ruchu HTTP oraz ograniczeniach Content Security Policy.
W praktyce oznacza to, że nawet organizacje stosujące restrykcyjne polityki bezpieczeństwa po stronie przeglądarki nie mogą zakładać, że same mechanizmy CSP wystarczą do zatrzymania nowoczesnych kampanii skimmingowych.
W skrócie
- Atak powiązano z kompromitacją sklepu internetowego producenta samochodów.
- Punktem wejścia była luka PolyShell dotycząca Magento Open Source i Adobe Commerce.
- Złośliwy skrypt wykorzystywał WebRTC DataChannel do pobierania kolejnego etapu ładunku i wykradania danych płatniczych.
- Technika utrudnia wykrywanie, ponieważ omija część standardowego monitoringu skoncentrowanego na HTTP i klasycznych regułach CSP.
- Ryzyko dotyczy zarówno kradzieży danych klientów, jak i długotrwałej, trudnej do zauważenia kompromitacji środowiska sklepu.
Kontekst / historia
Skimmery webowe od lat należą do najpoważniejszych zagrożeń dla platform sprzedażowych. Tradycyjnie złośliwy kod osadzany na stronie płatności przechwytuje dane formularzy i wysyła je do infrastruktury przestępców przez żądania HTTP, ukryte wywołania AJAX lub inne mechanizmy osadzone w kodzie strony.
W odpowiedzi organizacje wdrażały polityki CSP, monitoring integralności skryptów, analizę zmian w warstwie frontendu oraz inspekcję ruchu aplikacyjnego. Nowy przypadek pokazuje jednak ewolucję technik Magecart i podobnych operacji. Zamiast klasycznych ścieżek eksfiltracji wykorzystano WebRTC DataChannel, czyli mechanizm przeznaczony do bezpośredniej wymiany danych w czasie rzeczywistym.
Taka zmiana oznacza, że część środowisk skutecznie ograniczających nieautoryzowane połączenia webowe może nadal przepuszczać złośliwą komunikację realizowaną innym kanałem sieciowym.
Analiza techniczna
Łańcuch ataku składa się z dwóch głównych etapów: kompromitacji serwera sklepu oraz działania skimmera w przeglądarce ofiary. Według opublikowanych ustaleń luka PolyShell wynika z niewystarczającej walidacji przesyłanych plików w logice przetwarzania obrazów. Mechanizm sprawdza wybrane parametry, takie jak rozmiar czy typ MIME, ale nie zawsze rygorystycznie weryfikuje zgodność rozszerzenia z rzeczywistą zawartością pliku.
To otwiera drogę do przesłania pliku typu polyglot, który jednocześnie wygląda jak poprawny obraz i zawiera kod możliwy do późniejszego wykonania. Wektor miał być osiągalny przez endpoint REST związany z koszykiem gościa. Samo przesłanie pliku nie zawsze oznacza pełne zdalne wykonanie kodu, ponieważ kluczowe znaczenie ma konfiguracja serwera WWW oraz poziom utwardzenia katalogów dostępnych dla aplikacji.
Jeżeli jednak instancja sklepu zawiera odstępstwa od zaleceń bezpieczeństwa, brak odpowiednich blokad dostępu lub nieprawidłowe reguły wykonywania plików, atakujący może uzyskać możliwość trwałego osadzenia backdoora albo uruchomienia złośliwego kodu po stronie serwera.
Po uzyskaniu dostępu wdrażany jest skrypt po stronie klienta, który inicjuje połączenie WebRTC z adresem zakodowanym na stałe i pobiera dodatkowy kod JavaScript odpowiedzialny za kradzież danych płatniczych. To właśnie ten etap znacząco podnosi poziom zagrożenia, ponieważ właściwy ładunek może być dostarczony dynamicznie dopiero w przeglądarce ofiary.
Istota obejścia CSP polega na tym, że polityka Content Security Policy koncentruje się głównie na kontroli źródeł zasobów i połączeń webowych definiowanych w modelu przeglądarki, zwłaszcza dla żądań HTTP i HTTPS. Komunikacja przez WebRTC DataChannel przebiega innym torem, co utrudnia jej wykrycie przez narzędzia monitorujące przede wszystkim ruch aplikacyjny i logi HTTP.
Konsekwencje / ryzyko
Dla operatorów sklepów najpoważniejszym skutkiem jest oczywiście kradzież danych kart płatniczych i informacji rozliczeniowych klientów. Taki incydent może prowadzić do fraudów, sporów chargeback, kosztownych dochodzeń powłamaniowych, problemów zgodnościowych oraz poważnych strat reputacyjnych.
Drugim wymiarem ryzyka jest utrudniona detekcja. Jeśli organizacja opiera monitoring głównie na logach aplikacyjnych, WAF, analizie HTTP i standardowym CSP, skimmer wykorzystujący WebRTC może działać dłużej bez wzbudzania alarmów. To zwiększa skalę potencjalnych szkód oraz liczbę poszkodowanych użytkowników.
Nie bez znaczenia pozostaje także zagrożenie systemowe dla ekosystemu Magento i Adobe Commerce. Jeżeli luka wejściowa jest aktywnie skanowana i wykorzystywana masowo, na celowniku mogą znaleźć się nie tylko wybrane marki, lecz także szeroka grupa sklepów działających na podatnych wersjach lub posiadających niestandardową, słabiej zabezpieczoną konfigurację.
Rekomendacje
Operatorzy sklepów powinni traktować ten scenariusz jako połączenie podatności po stronie serwera z zaawansowanym skimmingiem po stronie klienta. Odpowiedź na zagrożenie musi więc obejmować kilka warstw jednocześnie.
- Jak najszybciej zastosować dostępne poprawki producenta i potwierdzić, czy używana wersja platformy zawiera zabezpieczenia dla opisywanego problemu.
- Zweryfikować konfigurację serwera WWW, zwłaszcza katalogów multimediów i lokalizacji wykorzystywanych do przechowywania przesłanych plików.
- Upewnić się, że pliki przesyłane przez użytkowników nie mogą być wykonywane jako kod po stronie serwera.
- Przeprowadzić pełne skanowanie instancji pod kątem web shelli, backdoorów, nieautoryzowanych plików oraz zmian w szablonach checkoutu i kodzie JavaScript.
- Rozszerzyć monitoring o nietypowe użycie WebRTC, zwłaszcza w obszarach koszyka i płatności.
- Wdrożyć kontrole integralności po stronie klienta oraz regularne testy bezpieczeństwa ścieżek zakupowych.
Szczególnie ważne jest odejście od założenia, że samo CSP zapewnia wystarczającą ochronę przed nowoczesnym skimmingiem. Współczesne kampanie coraz częściej wykorzystują legalne funkcje przeglądarki w sposób, który nie wpisuje się w klasyczne wzorce wykrywania.
Podsumowanie
Opisany przypadek pokazuje wyraźną ewolucję metod stosowanych przez cyberprzestępców atakujących sektor e-commerce. Połączenie luki PolyShell z eksfiltracją danych przez WebRTC tworzy skuteczny łańcuch ataku, który omija część tradycyjnych zabezpieczeń opartych na ruchu HTTP i restrykcyjnych politykach CSP.
Dla organizacji korzystających z Magento Open Source i Adobe Commerce oznacza to konieczność równoczesnego łatania podatności, przeglądu konfiguracji serwera oraz rozbudowy detekcji o zachowania frontendowe i nietypowy ruch sieciowy. Najważniejszy wniosek jest prosty: nowoczesne skimmery coraz częściej korzystają z legalnych mechanizmów przeglądarki, co znacząco utrudnia ich szybkie wykrycie i zatrzymanie.
Źródła
- The Hacker News — WebRTC Skimmer Bypasses CSP to Steal Payment Data from E-Commerce Sites — https://thehackernews.com/2026/03/webrtc-skimmer-bypasses-csp-to-steal.html
- Adobe Commerce 2.4.9-beta1 release notes — https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/adobe-commerce/2-4-9
- MDN Web Docs — Content Security Policy (CSP) — https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP
- WebRTC — Data channels — https://webrtc.org/getting-started/data-channels