Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw systemu należą dziś do najpoważniejszych zagrożeń dla środowisk developerskich opartych na Node.js i JavaScript. Najnowszy incydent pokazuje, iż publiczne rejestry pakietów mogą zostać wykorzystane do dystrybucji komponentów podszywających się pod legalne rozszerzenia, a ich instalacja otwiera drogę do uruchomienia złośliwego kodu, kradzieży poświadczeń i przejęcia infrastruktury.
W opisanej kampanii cyberprzestępcy opublikowali fałszywe pakiety NPM imitujące wtyczki do Strapi, czyli popularnego headless CMS. Celem operacji było nie tylko zainfekowanie środowisk użytkowników, ale także uzyskanie dostępu do zasobów powiązanych z platformą Guardarian.
W skrócie
Badacze zidentyfikowali 36 złośliwych pakietów NPM opublikowanych z czterech kont w ramach jednej kampanii wymierzonej w użytkowników Strapi. Ładunki zawarte w tych pakietach umożliwiały między innymi wykonanie kodu przez Redis, instalację reverse shelli, próbę ucieczki z kontenerów Docker, eksfiltrację konfiguracji oraz kradzież poświadczeń.
- 36 złośliwych pakietów opublikowanych w NPM
- Kampania ukierunkowana na ekosystem Strapi
- Ataki obejmowały Redis, Docker, PostgreSQL i Elasticsearch
- Celem była również infrastruktura powiązana z Guardarian
- Taktyka napastników ewoluowała od agresywnego przejęcia do rozpoznania i utrwalania dostępu
Kontekst / historia
Strapi to otwartoźródłowy system headless CMS zbudowany na Node.js, szeroko wykorzystywany do tworzenia aplikacji webowych, mobilnych i API. Popularność platformy oraz oparcie o zewnętrzne zależności sprawiają, iż jej ekosystem jest naturalnym celem dla ataków supply chain.
W tej kampanii napastnicy wykorzystali zaufanie deweloperów do rejestru NPM i opublikowali pakiety imitujące rozszerzenia Strapi. Analiza wskazuje, iż operacja była skoordynowana, a wzorce nazewnictwa, ścieżki konfiguracji i dobór technik sugerują przygotowanie pod konkretne wdrożenia działające na Linuksie i w środowiskach kontenerowych.
Analiza techniczna
Mechanizm ataku był stosunkowo prosty, ale bardzo skuteczny. Po zainstalowaniu fałszywej wtyczki złośliwy kod uruchamiał jeden z kilku payloadów, których zadaniem było pozyskanie dostępu do środowiska, danych aplikacyjnych i sekretów infrastrukturalnych.
Jeden z wariantów wykorzystywał Redis do modyfikowania zadań crontab, wdrażania webshelli PHP, uruchamiania reverse shelli w Node.js, dodawania kluczy SSH oraz eksfiltracji wybranych komponentów API. Taki zestaw działań wskazuje na próbę przejścia od jednorazowego wykonania kodu do trwałego utrzymania obecności w systemie.
Inny payload został zaprojektowany z myślą o środowiskach Docker. Obejmował wykrywanie warstw overlay, zapisywanie powłok w katalogach hosta, uruchamianie reverse shella oraz odczyt poświadczeń i danych powiązanych z backendem. To pokazuje, iż atakujący zakładał obecność kontenerów i próbował wyjść poza granice pojedynczej instancji aplikacji.
Pozostałe ładunki skupiały się na zbieraniu poświadczeń, analizie konfiguracji Strapi, poszukiwaniu plików portfeli i kluczy, atakach na PostgreSQL oraz budowaniu mechanizmów trwałości. Istotne jest to, iż kampania nie była ograniczona do jednego scenariusza kompromitacji, ale obejmowała kilka ścieżek działania zależnie od architektury ofiary.
Konsekwencje / ryzyko
Skala ryzyka jest wysoka, ponieważ zagrożenie dotyczy pakietów instalowanych bezpośrednio w procesie wytwarzania i utrzymania aplikacji. W praktyce instalacja złośliwego komponentu może prowadzić do przejęcia hosta, wycieku danych aplikacyjnych, kompromitacji baz danych, utraty sekretów oraz naruszenia bezpieczeństwa środowisk kontenerowych.
W organizacjach obsługujących płatności, portfele kryptowalutowe lub wrażliwe dane skutki mogą być jeszcze poważniejsze. Poszukiwanie plików portfeli, kluczy i poświadczeń sugeruje wyraźną motywację finansową i wysoki poziom ukierunkowania ataku.
Dodatkowym problemem jest możliwość utrzymania dostępu choćby po usunięciu samego pakietu. jeżeli wcześniej doszło do dodania kluczy SSH, wpisów cron lub zapisania powłok na hoście, kompromitacja może przetrwać znacznie dłużej i umożliwić dalszy ruch boczny w infrastrukturze.
Rekomendacje
Organizacje korzystające ze Strapi i NPM powinny niezwłocznie przeanalizować historię instalowanych pakietów, zależności w projektach oraz aktywność w pipeline’ach CI/CD. Każde podejrzenie instalacji pakietu podszywającego się pod legalną wtyczkę należy traktować jako potencjalną pełną kompromitację systemu.
- zweryfikować ostatnio instalowane pakiety i źródła ich publikacji,
- przeprowadzić rotację haseł do baz danych i usług backendowych,
- wymienić klucze API, sekrety JWT oraz klucze SSH,
- sprawdzić wpisy cron, autostart i inne mechanizmy trwałości,
- przeanalizować logi Redis, PostgreSQL, Elasticsearch i środowisk kontenerowych,
- skontrolować połączenia wychodzące oraz oznaki aktywności reverse shelli,
- zbadać integralność plików aplikacyjnych i konfiguracji,
- zweryfikować mapowania wolumenów i uprawnienia kontenerów Docker.
Na poziomie strategicznym warto wdrożyć polityki dopuszczania zależności, korzystać z prywatnych repozytoriów lub proxy dla pakietów, rozwijać analizę SBOM i stosować narzędzia wykrywające podejrzane zachowania jeszcze przed instalacją komponentów w środowisku produkcyjnym.
Podsumowanie
Incydent z fałszywymi pakietami NPM podszywającymi się pod wtyczki Strapi potwierdza, iż ataki supply chain pozostają jednym z najskuteczniejszych sposobów infiltracji nowoczesnych środowisk aplikacyjnych. Kampania łączyła techniki wykonania kodu, ucieczki z kontenerów, kradzieży poświadczeń, eksfiltracji konfiguracji i utrwalania dostępu.
Szczególnie niepokojące jest ukierunkowanie na infrastrukturę powiązaną z Guardarian oraz dopasowanie payloadów do realiów wdrożeń Strapi. Dla zespołów bezpieczeństwa to kolejny sygnał, iż ochrona aplikacji musi obejmować nie tylko własny kod, ale cały ekosystem zależności, proces publikacji pakietów i bezpieczeństwo łańcucha dostaw oprogramowania.
