SessionReaper — luka, która rozszarpała sklepy internetowe. Jak działa i jak się bronić?

Opis luki (CVE‑2025‑54236)

Luka o identyfikatorze CVE‑2025‑54236 dotyczy platformy Adobe Commerce (oraz Magento Open Source) i została opisana jako „Improper Input Validation” (CWE‑20) w komponencie Web API (moduł ServiceInputProcessor) systemu. Z powodzeniem
wykorzystana może umożliwić atakującemu przejęcie sesji użytkownika (session takeover) lub — w niektórych warunkach — nawet zdalne wykonanie kodu (RCE).

Warto zwrócić uwagę, że atak nie wymaga interakcji ze strony użytkownika (UI:N) i może być wykonany
zdalnie (AV:N/AC:L).

Luka została oceniona jako bardzo krytyczna — CVSS v3.1 9.1/10.

Adobe wydało „out‑of‑band” łatkę 9 września 2025 r., ze względu na wyjątkową wagę problemu.

Badacze bezpieczeństwa określają ją jako jedną z najpoważniejszych w historii
Magento/Adobe Commerce – porównywalną z wcześniejszymi „Shoplift” (2015) czy „CosmicSting” (2024).

Zakres wpływu

Dotknięte są następujące wersje:

• Adobe Commerce wszystkie wersje do 2.4.9‑alpha2, 2.4.8‑p2, 2.4.7‑p7, 2.4.6‑p12, 2.4.5‑p14, 2.4.4‑p15 i wcześniejsze.
• Adobe Commerce B2B wersje 1.5.3‑alpha2 i wcześniejsze itd.
• Magento Open Source w analogicznych wersjach (2.4.9‑alpha2 i wcześniejszych) również jest podatne.
  Środowiska w chmurze Adobe Commerce mają zapewnione reguły Web
  Application Firewall (WAF), ale wiele instalacji on‑premises lub niestandardowych może być nadal podatnych.
  Wykryto już masową aktywność skanowania i prób ataków – źródła mówią
  o setkach prób w ciągu godzin po ujawnieniu luki.

Warunki konieczne do udanego ataku (prerequisites)

Wymagania środowiskowe i operacyjne, które zwykle występują w raportowanych exploitach:

• instalacja Adobe Commerce / Magento w wersjach podatnych (wymienione w advisori), bez zastosowanego
  hotfixa;
• publicznie dostępne REST API (Commerce REST API) — atak nie wymaga interakcji użytkownika;
• możliwość przesyłania/zarządzania danymi przez określone punkty końcowe API (np.
  uploady lub endpointy akceptujące złożone payloady).
  Te założenia są potwierdzone w advisori producenta i analizach forensics.

Ogólny łańcuch ataku — etapy (high level)

1. Rozpoznanie i identyfikacja endpointów — skanowanie instancji w celu potwierdzenia wersji Magento/Adobe i istnienia
   podatnych endpointów Web API.
2. Wstrzyknięcie spreparowanego payloadu do Web API — wykorzystanie nieprawidłowej walidacji wejścia w ServiceInputProcessor do przesłania danych, które
   następnie zostaną zaakceptowane/błędnie przetworzone.
3. Zatrucie (poisoning) sesji / upload pliku‑sesji — atakujący tworzy lub modyfikuje zasób, który można wykorzystać jako nośnik
   sesji (np. upload pliku, wpis w storage sesji). W niektórych analizach użyto endpointu typu /customer/address_file/upload albo podobnych
   mechanizmów do zapisania pliku, który później zostaje użyty jako plik sesji lub webshell.
4. Deserializacja / PHP Object Injection (POI) — Magento (lub jego biblioteki) odtwarza/przetwarza dane sesji lub inne struktury, co prowadzi do
   wykonania deserializacji PHP na kontrolowanych przez atakującego danych. Jeśli w środowisku istnieją klasy („gadgets”), których magiczne metody
   (__wakeup, __destruct itp.) wykonują niebezpieczne akcje, atakujący może wywołać łańcuch (gadget chain) prowadzący do eskalacji: od przejęcia sesji
   do uruchomienia kodu RCE. Publiczne analizy opisują dokładnie takie „nested deserialization” jako kluczowy element.
5. Utrwalenie dostępu / eskalacja — po kontroli sesji lub uruchomieniu kodu atakujący może zapisać webshell, wykradać ciasteczka/sesje, tworzyć
   adminów lub wyprowadzać dane klientów. Sansec i inne zespoły obserwowały opisane zachowania (webshelle w katalogach upload, podejrzany ruch REST
   API).

Techniczne szczegóły mechanizmów exploita (deep dive)

Nature of the validation bug (ServiceInputProcessor)

ServiceInputProcessor przyjmuje dane z żądań REST (JSON/form), a następnie mapuje je na wewnętrzne
obiekty i struktury. W tej ścieżce Adobe nieprawidłowo waliduje pewne pola — co umożliwia przesłanie wartości, które powinny być odrzucone lub „oczyszczone”. W
praktyce oznacza to, że atakujący może przesłać złożone, zagnieżdżone struktury (np. serializowane łańcuchy, pola wskazujące na zasoby plikowe), które są
później traktowane przez system jako bezpieczne. To „otwiera drzwi” do podania danych, które zostaną potraktowane jako sesja lub obiekt do deserializacji.

File‑based session poisoning i alternatywne handlery

W wielu wdrożeniach Magento sesje PHP są trzymane jako pliki w var/session lub podobnych
lokalizacjach. Jeśli aplikacja pozwala na upload plików do katalogów dostępnych dla PHP i te pliki zostaną następnie użyte/odczytane jako sesje lub w inny
sposób poddane unserialize(), atakujący może zapisać specjalnie przygotowany payload (np. serialized PHP object) i doprowadzić do jego wykonania. Analizy
exploitów pokazują wykorzystanie mechanizmu uploadu adresów/plików klientów jako wektora zapisu payloadu. Jednak badacze ostrzegają, że nawet jeśli sesje
są przechowywane w Redis/DB, podobne ataki można skonstruować przez manipulację danymi sesji czy innymi zasobami — zależnie od zabudowy aplikacji.

Nested deserialization i gadget chains

„Nested deserialization” oznacza, że payload zawiera serializowany obiekt lub strukturę
ukrytą wewnątrz JSON/parametru, która pośrednio trafia do unserialize(). W dalszym kroku PHP tworzy instancje konkretnych klas dostępnych w kodzie
Magento/rozszerzeniach. Jeżeli którakolwiek z tych klas posiada metody magiczne wykonujące funkcje (np. zapis pliku, wywołanie eval, wykonanie systemowych
komend poprzez biblioteki), można złożyć łańcuch wywołań (gadget chain) dający RCE. Publiczne PoC i analizy (Pentest‑Tools, SLCyber/Assetnote) rekonstruują konkretne łańcuchy dla typowych bibliotek Magento.

Session takeover vs RCE — jak dochodzi do przejęcia sesji

Prostszy, ale często występujący wariant ataku to sesja takeover: atakujący tworzy sesję, uzyskuje
jej ID (lub zmusza system, by użył pliku sesji z jego treścią) i następnie używa tego ID jako cookie, co daje dostęp do kont klienta (shopping cart,
profile). To nie wymaga pełnego RCE i jest znacznie łatwiejsze do zautomatyzowania. Jednakże w analizowanych przypadkach deserializacja dawała
też możliwość zapisu plików (webshell) i osiągnięcia RCE.

Wskaźniki kompromitacji (IoC) i co sprawdzać natychmiast

• nietypowe żądania do API (zwłaszcza z anomalnymi, zagnieżdżonymi payloadami) — przeszukaj logi REST
  API;
• nowe pliki.php lub niespodziewane pliki w katalogach upload/var/session; sprawdź timestampe i
  właściciela pliku;
• zmiany w sesjach: pojawienie się sesji o dziwnych rozmiarach lub zawartości (np. serialized object
  strings) w storage sesji;
• nagły wzrost zapytań ze skanującymi charakterystykami (powtarzalne, krótkie interwały, różne IP) —
  behaviour wskazujący na masowe skanowanie/exploitację;
• wykrycie webshelli lub nietypowych kont użytkowników/adminów utworzonych w krótkim czasie po
  publikacji CVE.

Techniczne rekomendacje łagodzące

1. Natychmiastowy patch/hotfix — zainstaluj oficjalny patch Adobe dla CVE‑2025‑54236. To priorytet.
2. WAF + reguły blokujące — włączyć/zaostrzyć reguły WAF (blokowanie podejrzanych payloadów JSON/parametrów, restrykcja uploadów, rate‑limiting). WAF może zniwelować próby exploitów do czasu patcha.
3. Skanowanie i poszukiwanie artefaktów — przeszukaj var/ (var/session, var/tmp, katalogi uploadów) pod kątem nieznanych plików PHP i podejrzanych
   serialized payloadów; przeszukaj repozytoria kodu i filesystem pod webshellami.
4. Tymczasowe hardeningi — jeśli możliwe, zmień handler sesji na bezpieczniejszy backend (np. Redis/DB z ograniczeniami), zablokuj upload plików do
   katalogów wykonywalnych, ogranicz prawa zapisu na katalogi webowe oraz stosuj surowe filtry typów MIME.
5. Unieważnienie sesji i rotacja kluczy — rozważ wymuszenie logoutu sesji (invalidate all sessions) i rotację sekretów aplikacji, jeśli istnieje podejrzenie
   kompromitacji.
6. Analiza forensics i IR — jeśli są oznaki kompromitacji (webshell, nieautoryzowane zmiany), przeprowadź pełne badanie śladów, zrzuty pamięci
   i logów, zachowując artefakty do dalszej analizy i raportu.