Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
PolyShell to krytyczna podatność dotycząca Magento Open Source 2 oraz Adobe Commerce, powiązana z mechanizmem REST API obsługującym przesyłanie plików dla niestandardowych opcji produktów w koszyku. Luka może prowadzić do zdalnego wykonania kodu, przejęcia kont użytkowników lub administratorów, a także do osadzenia złośliwego skryptu po stronie sklepu.
Z perspektywy operatorów e-commerce problem jest szczególnie groźny, ponieważ dotyczy platform przetwarzających dane klientów i obsługujących płatności. Oznacza to, że skutki udanego ataku mogą wykraczać poza samą kompromitację aplikacji i obejmować również wyciek danych, nadużycia finansowe oraz naruszenia zgodności.
W skrócie
- PolyShell jest aktywnie wykorzystywana przeciwko podatnym instancjom Magento i Adobe Commerce.
- Ataki rozpoczęły się bardzo szybko po publicznym ujawnieniu problemu.
- Luka dotyczy REST API odpowiedzialnego za upload plików w ramach niestandardowych opcji w koszyku.
- Możliwe skutki obejmują RCE, stored XSS i wdrożenie web skimmerów kradnących dane kart płatniczych.
- W kampaniach obserwowano nowoczesne mechanizmy eksfiltracji danych, w tym użycie WebRTC.
Kontekst / historia
Magento i Adobe Commerce od lat pozostają atrakcyjnym celem dla cyberprzestępców. Powodem jest ich bezpośredni związek z procesem sprzedaży, danymi klientów oraz środowiskiem płatności. Przejęcie sklepu internetowego daje atakującym możliwość monetyzacji incydentu na wiele sposobów: od osadzenia skimmera płatniczego po kradzież kont i dalszą penetrację infrastruktury.
W przypadku PolyShell kluczowe znaczenie ma tempo eskalacji. Jak pokazuje ten przypadek, czas między ujawnieniem podatności a rozpoczęciem masowych prób wykorzystania był bardzo krótki. To typowy wzorzec dla sektora e-commerce, gdzie opóźnienia we wdrażaniu aktualizacji i złożoność utrzymania środowisk produkcyjnych zwiększają skuteczność kampanii prowadzonych na szeroką skalę.
Analiza techniczna
Źródłem problemu jest sposób obsługi przesyłania plików przez REST API Magento w kontekście niestandardowych opcji produktów dodawanych do koszyka. W praktyce atakujący może próbować dostarczyć plik o cechach poliglotycznych, czyli taki, który może być różnie interpretowany przez kolejne warstwy aplikacji, serwera i mechanizmów walidacji.
Jeżeli środowisko nie weryfikuje poprawnie typu, zawartości i sposobu przetwarzania pliku, możliwe staje się osiągnięcie zdalnego wykonania kodu. W innych scenariuszach podatność może prowadzić do stored XSS, co otwiera drogę do przejęcia sesji, modyfikacji interfejsu sklepu i uruchamiania złośliwego kodu po stronie klienta.
Szczególnie niepokojącym elementem kampanii jest użycie skimmerów płatniczych bazujących na WebRTC. Zamiast klasycznego przesyłania danych przez żądania HTTP, złośliwy kod może wykorzystywać szyfrowane kanały komunikacji, co utrudnia wykrycie przez tradycyjne mechanizmy monitorowania ruchu. W praktyce oznacza to, że standardowe kontrole bezpieczeństwa mogą nie wystarczyć do ujawnienia pełnego zakresu kompromitacji.
Atakujący stosują również techniki opóźniania wykonania oraz dynamicznego ładowania payloadów, aby zmniejszyć szansę wykrycia podczas prostych testów i rutynowych kontroli. To dodatkowo komplikuje analizę incydentu i zwiększa ryzyko długotrwałej, niezauważonej obecności złośliwego kodu w środowisku sklepu.
Konsekwencje / ryzyko
Ryzyko związane z PolyShell należy ocenić jako wysokie lub krytyczne. Skuteczny atak może mieć bezpośredni wpływ na ciągłość działania sklepu, bezpieczeństwo danych klientów oraz rozliczenia płatnicze.
- zdalne wykonanie kodu na serwerze aplikacyjnym,
- przejęcie kont użytkowników lub administratorów przez stored XSS,
- instalacja web skimmera wykradającego dane kart płatniczych,
- naruszenie zgodności z wymaganiami bezpieczeństwa i ochrony danych,
- straty finansowe, operacyjne i reputacyjne,
- ryzyko dalszej kompromitacji infrastruktury poprzez pivoting z systemu sklepowego.
Dodatkowym problemem jest fakt, że kompromitacja może pozostać niewidoczna przez dłuższy czas. Jeżeli złośliwy kod działa wyłącznie po stronie przeglądarki klienta, operator sklepu może nie zauważyć anomalii, dopóki nie pojawią się reklamacje, alerty od partnerów płatniczych lub wyniki zewnętrznego dochodzenia.
Rekomendacje
Organizacje korzystające z Magento Open Source lub Adobe Commerce powinny potraktować PolyShell priorytetowo i połączyć działania naprawcze z aktywną detekcją śladów kompromitacji.
- zweryfikować używaną wersję platformy oraz status podatności na wszystkich węzłach środowiska,
- niezwłocznie wdrożyć oficjalne poprawki producenta lub dostępne środki ograniczające ryzyko,
- czasowo ograniczyć funkcje uploadu przez REST API, jeśli nie są niezbędne biznesowo,
- wdrożyć ścisłą walidację typów MIME, rozszerzeń, sygnatur plików i zasad ich zapisu po stronie serwera,
- przeprowadzić threat hunting pod kątem webshelli, podejrzanych skryptów i nieautoryzowanych zmian w checkout,
- monitorować ruch wychodzący, w tym nietypowe połączenia UDP i komunikację mogącą wskazywać na użycie WebRTC,
- zaostrzyć polityki CSP oraz objąć monitoringiem integralność skryptów JavaScript,
- przygotować plan reakcji incydentowej obejmujący izolację systemu, analizę forensic, rotację poświadczeń i ocenę wpływu na dane płatnicze.
Podsumowanie
PolyShell pokazuje, jak szybko krytyczna luka w popularnej platformie e-commerce może zostać przekształcona w zautomatyzowaną kampanię ataków na dużą skalę. Połączenie potencjalnego RCE, stored XSS oraz możliwości wdrożenia nowoczesnych skimmerów płatniczych sprawia, że podatność stanowi poważne zagrożenie dla sklepów internetowych.
Dla operatorów Magento i Adobe Commerce najważniejsze są dziś trzy działania: szybka weryfikacja ekspozycji, natychmiastowe wdrożenie poprawek oraz aktywne poszukiwanie śladów kompromitacji. Zwłoka może przełożyć się nie tylko na incydent bezpieczeństwa, ale również na wymierne straty finansowe i długotrwałe szkody reputacyjne.