Luka w Magento PolyShell umożliwia niezautoryzowane przesyłanie plików, RCE i przejęcie konta

Luka w Magento REST API znana jako PolyShell stanowi jedno z najpoważniejszych zagrożeń dla e-commerce'owych platform, jakie pojawiły się w ostatnich miesiącach. Sansec, specjalizująca się w bezpieczeństwie platform handlu elektronicznego, ujawniła krytyczną podatność, która pozwala atakującym na przesyłanie dowolnych plików wykonywalnych bez uwierzytelnienia, osiągnięcie zdalne wykonania kodu (RCE) oraz przejęcie kont użytkowników. To nie jest zwykła luka — to systematyczne obejście mechanizmów bezpieczeństwa, które powinny chronić miliony sklepów online na całym świecie. Fakt, że atak opiera się na zamaskowanym złośliwym kodzie jako obrazie, ukazuje zaawansowanie współczesnych technik obejścia zabezpieczeń.

Magento, będące jedną z najpopularniejszych platform e-commerce'owych, zasilające tysiące sklepów internetowych od małych startupów po duże sieci handlowe, stało się celem zaawansowanego ataku. Podatność PolyShell dotyka REST API platformy, czyli interfejsu programistycznego, którym komunikują się różne komponenty systemu i aplikacje zewnętrzne. Brak wymagania autentykacji oznacza, że każdy, posiadający dostęp do sieci, może potencjalnie uruchomić atak bez potrzeby posiadania jakichkolwiek uprawnień czy haseł.

Anatomia ataku PolyShell — jak działa zagrożenie

Genialność podatności PolyShell leży w jej prostocie i skuteczności jednocześnie. Atakujący wykorzystuje REST API Magento do przesłania pliku, który system interpretuje jako obraz, ale faktycznie zawiera kod wykonywalny. Technika polega na polyglotowych plikach — dokumentach, które jednocześnie spełniają specyfikację formatu obrazu i zawierają kod PHP lub inny język skryptowy. Serwer Magento, sprawdzając jedynie nagłówek lub rozszerzenie pliku, zamiast przeprowadzać pogłębioną analizę zawartości, akceptuje plik jako bezpieczny obraz.

Po przesłaniu takiego pliku atakujący może następnie wyzwolić jego wykonanie poprzez dostęp do niego za pośrednictwem przeglądarki internetowej lub bezpośredniego żądania HTTP. Serwer, zamiast renderować obraz, wykonuje zawarte w nim instrukcje PHP. Od tego momentu atakujący ma pełną kontrolę nad serwerem — może czytać bazy danych zawierające dane klientów, modyfikować zawartość sklepu, instalować backdoory do przyszłych ataków, a przede wszystkim przejąć konta administratorów i użytkowników.

Szczególnie niebezpiecznym aspektem tej podatności jest jej uniwersalność. Nie wymaga ona specjalistycznej wiedzy o danym sklepie czy zaawansowanego social engineeringu. Atakujący może automatycznie skanować Internet w poszukiwaniu instancji Magento i przeprowadzić atak na masową skalę. Taka metodologia, znana jako "indiscriminate scanning", jest szczególnie efektywna wobec podatności, które dotyczą publicznych interfejsów API bez wymagania autentykacji.

REST API Magento — wąskie gardło bezpieczeństwa

REST API w Magento pełni kluczową rolę w architekturze systemu, umożliwiając integrację z zewnętrznymi aplikacjami, mobilnymi klientami oraz systemami zarządzania zasobami. Jednak w przypadku PolyShell, właśnie ta elastyczność i otwartość interfejsu stała się źródłem zagrożenia. Endpoint odpowiedzialny za przesyłanie plików, zamiast być chroniony wielowarstwowymi mechanizmami walidacji, opierał się na podstawowych sprawdzeniach.

Typowy stos bezpieczeństwa dla przesyłania plików powinien obejmować:

• Walidację typu MIME na poziomie serwera
• Analizę magicznych bajtów (magic bytes) w celu potwierdzenia rzeczywistego formatu pliku
• Przechowywanie przesłanych plików poza katalogiem dostępnym dla serwera webowego
• Wymuszenie niewykonywania plików w katalogu przesyłanych danych (ustawienia .htaccess lub nginx)
• Skanowanie antywirusowe przesyłanych plików
• Wymóg autentykacji dla operacji przesyłania

W przypadku PolyShell, co najmniej kilka z tych warstw ochrony zostało pominięte. Brak wymagania autentykacji jest szczególnie alarmujący, ponieważ oznacza, że każdy publiczny endpoint API jest potencjalnym punktem wejścia dla atakującego. Tego rodzaju błędy projektowe często wynikają z pośpiechu w rozwoju, braku dedykowanego security review'u lub założenia, że "nikt nie będzie atakować tego interfejsu".

Przejęcie kont — eskalacja uprawnień i lateralne ruchy

Po osiągnięciu zdalne wykonania kodu, atakujący ma dostęp do bazy danych Magento. Hasła administratorów przechowywane są zwykle w formie zahaszowanej, ale Magento używa algorytmu SHA-256 z solą, co jest podatne na ataki słownikowe przy wystarczającej mocy obliczeniowej. Jednak zamiast atakować hasła, atakujący może bezpośrednio modyfikować bazę danych, resetując hasła administratorów lub tworząc nowe konta z pełnymi uprawnieniami.

Przejęcie konta administratora otwiera całkowicie nowy wymiar ataku. Atakujący może:

• Modyfikować ceny produktów i przekierowywać płatności na swoje konta
• Przeglądać dane osobowe i finansowe wszystkich klientów
• Instalować skimmery płatności do zbierania danych kart kredytowych
• Modyfikować szablony e-mail w celu phishingu użytkowników
• Ustawiać permanentne backdoory, aby zachować dostęp nawet po naprawie podatności

Lateral movement — przemieszczanie się atakującego w obrębie sieci — jest kluczowym krokiem w zaawansowanych atakach. Jeśli Magento jest zintegrowany z innymi systemami poprzez REST API, atakujący może wykorzystać przejęty serwer jako punkt wejścia do ataku na systemy ERP, CRM czy bazy danych. To jest dokładnie scenariusz, przed którym ostrzegają dostawcy rozwiązań Zero Trust Network Access (ZTNA) — konieczność segmentacji sieci i ograniczenia dostępu do aplikacji na poziomie użytkownika i urządzenia.

Polyglot files — technika maskowania kodu w obrazach

Polyglot files, czyli pliki polyglotowe, to dokumenty, które jednocześnie spełniają specyfikację kilku formatów plików. Najprostszym przykładem jest plik, który jest zarówno prawidłowym plikiem JPEG, jak i prawidłowym plikiem ZIP. Technika ta wykorzystywana jest zarówno w bezpieczeństwie (na przykład do testowania systemów), jak i przez atakujących do obejścia filtrów.

W przypadku PolyShell, atakujący tworzy plik, który jest jednocześnie prawidłowym obrazem PNG lub JPEG i zawiera kod PHP. Możliwe jest to poprzez dodanie kodu PHP na koniec pliku obrazu — przeglądarki i narzędzia do przeglądania obrazów będą ignorować dodatkowe dane na końcu pliku, ale serwer webowy skonfigurowany do wykonywania PHP może interpretować cały plik jako PHP.

Alternatywnie, atakujący może wykorzystać podatności w bibliotekach do przetwarzania obrazów (takie jak ImageMagick), które mogą być wymuszane do interpretacji pliku jako skryptu. Tego rodzaju ataki są szczególnie trudne do wykrycia, ponieważ sygnatury antywirusowe szukają złośliwego kodu, ale polyglot file może przejść przez skanowanie jako bezpieczny obraz.

Skala zagrożenia — miliony sklepów e-commerce w niebezpieczeństwie

Magento zasilająca platformę e-commerce dla szacunkowych 240 000 sklepów internetowych na całym świecie, podatność PolyShell potencjalnie dotyka znaczną część infrastruktury handlu elektronicznego. Wiele z tych sklepów obsługuje transakcje finansowe, przechowuje dane osobowe klientów oraz zawiera wrażliwe informacje biznesowe. Szacuje się, że średni czas między wykryciem podatności a jej exploitacją przez cyberprzestępców wynosi zaledwie kilka dni.

Dodatkowo, wiele sklepów Magento działa na starszych wersjach oprogramowania, które nie otrzymują już regularnych aktualizacji bezpieczeństwa. Administratorzy często opóźniają aktualizacje ze względu na obawę przed kompatybilnością rozszerzeń (extensions) lub czasochłonności procesu migracji. To tworzy idealne warunki dla atakujących — podatna, nieaktualna instancja, którą nikt nie monitoruje aktywnie.

Odpowiedź branży i łatki bezpieczeństwa

Adobe, będące właścicielem Magento, wydało łatki bezpieczeństwa dla wszystkich wspieranych wersji platformy. Jednak wdrażanie łatek jest procesem, który wymaga czasu i planowania. Dla sklepów e-commerce, każdy moment nieplanowanej przerwy może oznaczać straty finansowe, dlatego wiele organizacji wdrażające łatki w zaplanowanych oknach serwisowych.

Sansec, odkrywca podatności, zaleca natychmiastowe działania dla wszystkich operatorów Magento:

• Natychmiastowe zastosowanie dostępnych łatek bezpieczeństwa
• Przegląd logów dostępu do REST API w poszukiwaniu podejrzanych przesyłań plików
• Skanowanie katalogów przesyłanych plików w poszukiwaniu polyglot files lub plików PHP
• Zmiana haseł wszystkich kont administratorów
• Wdrażanie Web Application Firewall (WAF) z regułami dla REST API
• Włączenie dwuetapowego uwierzytelniania (2FA) dla wszystkich kont administracyjnych

Zero Trust Architecture — przyszłość bezpieczeństwa e-commerce

Podatność PolyShell ukazuje fundamentalną słabość w tradycyjnym podejściu do bezpieczeństwa, gdzie zakłada się, że wszystko wewnątrz sieci jest zaufane. Architektura Zero Trust Network Access (ZTNA) eliminuje to założenie poprzez wymuszenie uwierzytelnienia i autoryzacji dla każdej operacji, niezależnie od lokalizacji użytkownika lub urządzenia.

W kontekście e-commerce, ZTNA oznacza, że każdy dostęp do REST API musi być poprzedzony silnym uwierzytelnieniem, a każdy użytkownik lub aplikacja ma dostęp tylko do konkretnych endpointów niezbędnych do wykonania ich funkcji. To podejście znacznie utrudnia atakującemu przeprowadzenie ataku — nawet jeśli uda mu się przesłać plik, nie będzie mógł go wykonać bez odpowiednich uprawnień.

Implementacja ZTNA w platformach e-commerce wymaga jednak zmiany mentalności — od otwartych, wygodnych interfejsów API do ściśle kontrolowanych, segmentowanych systemów. To oznacza dodatkową złożoność dla developerów, ale znacznie zwiększa bezpieczeństwo. Dla organizacji, które obsługują miliony transakcji i przechowują wrażliwe dane klientów, ten kompromis jest nie do uniknięcia.

Podatność PolyShell jest przypomnieniem, że bezpieczeństwo e-commerce nie może być afterthought'em — musi być wbudowane w architekturę od samego początku. Każdy endpoint API powinien być traktowany jako potencjalny wektor ataku, a każde przesyłanie pliku powinno być traktowane z ostrożnością. Dla branży e-commerce, która generuje biliony dolarów przychodów rocznie, koszt zaniedbania bezpieczeństwa jest po prostu zbyt wysoki.