Zautomatyzowana kampania kradzieży poświadczeń wykorzystuje lukę React2Shell w aplikacjach Next.js

securitybeztabu.pl 1 dzień temu

Wprowadzenie do problemu / definicja

Nowa kampania ofensywna pokazuje, jak niebezpieczne może być połączenie podatności typu pre-auth RCE z automatyzacją działań po stronie napastników. Atakujący wykorzystują lukę React2Shell, oznaczoną jako CVE-2025-55182, aby uzyskać zdalne wykonanie kodu bez uwierzytelnienia w środowiskach opartych o React Server Components i framework Next.js.

Po skutecznym przełamaniu pierwszej warstwy zabezpieczeń wdrażany jest zautomatyzowany zestaw do zbierania poświadczeń, sekretów środowiskowych oraz informacji o infrastrukturze. Taki model działania sprawia, iż pojedyncza podatność aplikacyjna może bardzo gwałtownie przełożyć się na znacznie szerszą kompromitację środowiska.

W skrócie

Kampania została powiązana z klastrem zagrożeń oznaczonym jako UAT-10608. Napastnicy kompromitują podatne aplikacje Next.js dostępne z Internetu, a następnie uruchamiają framework służący do masowego pozyskiwania danych uwierzytelniających i sekretów.

  • wykorzystywana jest luka pre-auth RCE w aplikacjach opartych o React Server Components,
  • atak ma charakter zautomatyzowany i masowy,
  • celem są hasła, klucze SSH, tokeny chmurowe, sekrety aplikacyjne i dane środowiskowe,
  • skutkiem może być ruch boczny, przejęcie zasobów chmurowych i dalsza eskalacja incydentu.

Kontekst / historia

React2Shell zyskał znaczenie jako podatność umożliwiająca zdalne wykonanie kodu przed uwierzytelnieniem w aplikacjach korzystających z mechanizmów React Server Components. Problem wynika z nieprawidłowego przetwarzania zserializowanych danych dostarczanych do endpointów funkcji serwerowych.

W praktyce aplikacja może przyjąć specjalnie przygotowany ładunek HTTP i wykonać kod po stronie procesu Node.js bez wcześniejszego logowania. W analizowanej kampanii atakujący nie ograniczali się do manualnego wykorzystywania pojedynczych instancji, ale prowadzili szeroko zakrojone skanowanie Internetu w poszukiwaniu podatnych wdrożeń.

Tego typu podejście znacząco zwiększa tempo kompromitacji i obniża koszt operacyjny ataku. Dla organizacji oznacza to większą presję na działania wyprzedzające, ponieważ reakcja dopiero po wykryciu incydentu może okazać się spóźniona.

Analiza techniczna

Łańcuch ataku rozpoczyna się od identyfikacji publicznie dostępnej aplikacji wykorzystującej podatne komponenty React Server Components lub framework Next.js. Następnie napastnik przesyła złośliwy zserializowany payload do odpowiedniego endpointu funkcji serwerowej. Brak adekwatnej walidacji lub sanityzacji danych wejściowych prowadzi do wykonania arbitralnego kodu w procesie Node.js.

Po uzyskaniu dostępu uruchamiany jest drugi etap, czyli pobranie i wykonanie skryptów harvestingowych. Zaobserwowane artefakty obejmowały procesy uruchamiane przez nohup, często z katalogu /tmp, z losowymi nazwami ukrytymi przy pomocy prefiksu z kropką. Wskazuje to na etapowy model działania, w którym dropper pobiera pełny zestaw narzędzi po udanej eksploatacji.

Framework do zbierania danych działa wielofazowo i koncentruje się na możliwie szerokim pozyskaniu informacji z hosta oraz środowiska wykonawczego.

  • zmienne środowiskowe procesów,
  • sekrety z runtime aplikacji JavaScript,
  • klucze prywatne SSH i pliki authorized_keys,
  • tokeny i poświadczenia zapisane w plikach lub pamięci środowiska,
  • historia poleceń powłoki,
  • dane z usług metadanych chmurowych AWS, GCP i Azure,
  • tokeny kont serwisowych Kubernetes,
  • konfiguracje oraz informacje o kontenerach Docker,
  • parametry uruchomieniowe procesów.

Zebrane dane są następnie przesyłane do infrastruktury command-and-control, gdzie trafiają do aplikacji operatorskiej określanej jako NEXUS Listener. Platforma ta nie pełni jedynie roli prostego odbiornika danych, ale działa również jako panel analityczny umożliwiający przeszukiwanie przejętych informacji i szybkie identyfikowanie najcenniejszych sekretów.

Wśród eksfiltrowanych danych znalazły się poświadczenia bazodanowe, tokeny GitHub i GitLab, klucze API dostawców usług, klucze Stripe, dane dostępowe do chmury oraz pełne ciągi połączeniowe do baz danych zawierające hasła zapisane jawnym tekstem. W wielu przypadkach pozyskano również klucze SSH, które mogą umożliwić utrzymanie dostępu choćby po częściowej rotacji poświadczeń aplikacyjnych.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią jest wysokie, ponieważ obejmuje zarówno etap wejścia, jak i natychmiastowe wykorzystanie uzyskanego dostępu. o ile atakujący pozyskają sekrety środowiskowe i tokeny chmurowe, mogą przejść od kompromitacji pojedynczej aplikacji do przejęcia całych zasobów infrastrukturalnych.

  • przejęcie kont i usług na podstawie wykradzionych tokenów,
  • ruch boczny oparty na kluczach SSH,
  • eksfiltracja danych z baz danych i magazynów obiektowych,
  • eskalacja uprawnień przez błędnie skonfigurowane role IAM lub RBAC,
  • przejęcie tokenów rejestrów pakietów i ryzyko ataków na łańcuch dostaw,
  • utrzymanie dostępu mimo częściowej remediacji, jeżeli organizacja nie wykona pełnej rotacji sekretów i przeglądu zaufanych kluczy.

Dodatkowym problemem jest skala operacyjna kampanii. Automatyzacja pozwala jednocześnie atakować wiele ofiar, a panel analityczny po stronie przeciwnika zwiększa wartość wykradzionych danych i przyspiesza planowanie kolejnych etapów operacji.

Rekomendacje

Najważniejszym krokiem obronnym jest niezwłoczne usunięcie podatności React2Shell poprzez aktualizację podatnych wdrożeń Next.js i komponentów React Server Components. Samo załatanie luki nie wystarczy jednak w sytuacji, gdy istnieje podejrzenie wcześniejszej kompromitacji.

  • przeprowadzić pilny przegląd wszystkich publicznie wystawionych aplikacji Next.js,
  • sprawdzić, czy na hostach występowały nietypowe procesy uruchamiane z katalogu /tmp,
  • przeanalizować logi pod kątem nietypowych żądań HTTP kierowanych do endpointów funkcji serwerowych,
  • wykonać pełną rotację poświadczeń aplikacyjnych, kluczy API, tokenów chmurowych i danych dostępowych do baz,
  • wycofać i ponownie wygenerować klucze SSH oraz zweryfikować, czy nie były współdzielone między systemami,
  • ograniczyć dostęp do usług metadanych chmurowych i wdrożyć mechanizmy ochrony przed ich nadużyciem,
  • włączyć skanowanie sekretów w repozytoriach, obrazach kontenerów i środowiskach runtime,
  • ograniczyć uprawnienia zgodnie z zasadą najmniejszych uprawnień dla IAM, Kubernetes i kont aplikacyjnych,
  • monitorować nietypowy ruch wychodzący HTTP i HTTPS z hostów oraz kontenerów,
  • przeprowadzić threat hunting pod kątem artefaktów takich jak nohup, ukryte skrypty powłoki i podejrzane połączenia zwrotne do zewnętrznych endpointów.

W środowiskach chmurowych i kontenerowych szczególnie ważne jest ograniczenie ekspozycji sekretów w zmiennych środowiskowych oraz stosowanie krótkotrwałych poświadczeń. Dobrą praktyką pozostaje również wdrożenie ścisłych polityk RBAC i blokowanie niepotrzebnego dostępu do metadanych instancji.

Podsumowanie

Kampania UAT-10608 pokazuje, iż połączenie podatności pre-auth RCE z automatycznym harvestingiem sekretów radykalnie zwiększa skuteczność działań przeciwnika. React2Shell pełni rolę punktu wejścia, ale realna wartość operacji wynika z masowego zbierania poświadczeń, kluczy SSH, tokenów chmurowych i informacji o środowisku.

Dla zespołów bezpieczeństwa oznacza to konieczność patrzenia na problem szerzej niż tylko przez pryzmat pojedynczej luki. Skuteczna reakcja wymaga nie tylko patchowania, ale także polowania na ślady kompromitacji, pełnej rotacji sekretów, przeglądu uprawnień oraz ograniczenia ekspozycji danych uwierzytelniających w runtime aplikacji.

Źródła

  • https://www.darkreading.com/cyberattacks-data-breaches/automated-credential-harvesting-campaign-react2shell
  • https://blog.talosintelligence.com/uat-10608-inside-a-large-scale-automated-credential-harvesting-operation-targeting-web-applications/
  • https://www.darkreading.com/
Idź do oryginalnego materiału