Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ekosystem npm ponownie znalazł się w centrum uwagi badaczy bezpieczeństwa po wykryciu kampanii łączącej dwa niebezpieczne scenariusze ataku na łańcuch dostaw oprogramowania: malware IronWorm oraz nowy wariant robaka Miasma. Oba zagrożenia pokazują, że współczesne incydenty supply chain wykraczają daleko poza prostą kompromitację pojedynczej biblioteki i coraz częściej obejmują kradzież sekretów, modyfikowanie repozytoriów oraz automatyczną propagację do kolejnych projektów.
To szczególnie istotne dla organizacji rozwijających aplikacje w oparciu o JavaScript, TypeScript i Node.js, gdzie automatyczne instalowanie zależności jest standardowym elementem procesu wytwórczego. W takim modelu nawet krótkotrwała kompromitacja konta maintainera lub publikacja zatrutej wersji pakietu może przełożyć się na szeroki zasięg infekcji.
W skrócie
W opisywanej kampanii napastnicy wykorzystali złośliwe lub skażone pakiety npm do dystrybucji dwóch rodzin malware. IronWorm, napisany w Rust, działał jako infostealer ukierunkowany na sekrety deweloperskie, chmurowe i CI/CD, a przy tym próbował samodzielnie rozprzestrzeniać się dalej przez przejęte konta i repozytoria.
Równolegle zaobserwowano nową wersję robaka Miasma, która infekowała dziesiątki pakietów i wykorzystywała technikę uruchamiania kodu podczas instalacji za pomocą pliku binding.gyp. Takie podejście mogło utrudniać wykrycie przez narzędzia skupione głównie na klasycznych skryptach lifecycle, takich jak preinstall czy postinstall.
- IronWorm koncentrował się na kradzieży sekretów i samopropagacji.
- Miasma wykorzystywał mechanizm Phantom Gyp do uruchamiania złośliwego kodu.
- Obie kampanie były wymierzone w środowiska deweloperskie, repozytoria kodu i pipeline’y CI/CD.
Kontekst / historia
Ataki na npm od lat należą do najpoważniejszych zagrożeń dla bezpieczeństwa nowoczesnego oprogramowania. Skala zależności, szybkość publikacji nowych wersji i szerokie wykorzystanie automatyzacji sprawiają, że pojedyncze skażenie może szybko przejść z poziomu lokalnej infekcji do problemu obejmującego wiele organizacji.
W tym przypadku badacze wskazali, że IronWorm był powiązany ze skompromitowanym kontem npm, z którego publikowano wersje pakietów zawierające binarny ładunek ELF napisany w Rust. Malware był uruchamiany przy instalacji pakietu, co znacząco zwiększało jego skuteczność, ponieważ etap ten często przebiega automatycznie zarówno na stacjach roboczych programistów, jak i w środowiskach buildowych.
Nowy wariant Miasma pojawił się po wcześniejszych incydentach związanych z infekcjami pakietów npm i wskazuje na szybkie rozwijanie technik atakujących. Rozszerzenie skali działania oraz dopracowanie metod ukrywania pokazują, że cyberprzestępcy aktywnie adaptują swoje narzędzia do sposobów detekcji opisywanych publicznie przez branżę bezpieczeństwa.
Analiza techniczna
IronWorm rozpoczynał działanie na etapie instalacji pakietu. Po uruchomieniu przeszukiwał środowisko ofiary w poszukiwaniu danych uwierzytelniających i sekretów zapisanych w zmiennych środowiskowych oraz plikach konfiguracyjnych. Zakres zainteresowania obejmował między innymi poświadczenia do usług chmurowych, narzędzi kontenerowych, Kubernetes, npm, systemów CI/CD, narzędzi programistycznych wspieranych przez AI, a nawet portfeli kryptowalutowych.
Jednym z najbardziej niepokojących elementów była zdolność malware do wykorzystania skradzionych danych w celu dalszej propagacji. Złośliwe oprogramowanie mogło modyfikować repozytoria, dodawać złośliwe commity i infekować kolejne pakiety. Według opisu kampanii możliwa była także podmiana workflow GitHub Actions na wariant służący do przechwytywania sekretów i zapisywania ich w artefaktach builda, co utrudnia wykrywanie incydentu wyłącznie na podstawie ruchu sieciowego.
Dodatkowym elementem eskalacji technicznej był ładunek eBPF pełniący funkcję rootkita na poziomie jądra systemu. Taki komponent mógł służyć do ukrywania procesów i utrudniania analizy, co stanowi rzadziej spotykany, ale bardzo groźny kierunek rozwoju ataków supply chain.
Nowy wariant Miasma korzystał z odmiennego mechanizmu wykonania kodu. Zamiast standardowych skryptów instalacyjnych wykorzystywał niewielki plik binding.gyp do wywołania złośliwego kodu podczas npm install. Technika określana jako Phantom Gyp pozwalała ominąć część standardowych mechanizmów monitorujących typowe skrypty lifecycle. Po uruchomieniu malware pobierał środowisko Bun i ładował moduł odpowiedzialny za szerokie zbieranie poświadczeń z usług chmurowych, menedżerów sekretów, systemów CI/CD, repozytoriów kodu i narzędzi developerskich.
Wariant Miasma miał również osadzać trwałe backdoory w repozytoriach projektów. Ich aktywacja przy otwieraniu projektu w środowisku IDE z funkcjami AI oznacza jakościową zmianę: zagrożenie przestaje dotyczyć wyłącznie pojedynczego pakietu, a zaczyna obejmować długotrwałe skażenie całego cyklu wytwórczego.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją takich kampanii jest połączenie kilku rodzajów ryzyka w jednym incydencie. Z jednej strony dochodzi do kradzieży sekretów deweloperskich, chmurowych i publikacyjnych, z drugiej zaś do samoreplikacji, która przyspiesza rozprzestrzenianie się zagrożenia między projektami i organizacjami.
Atak na CI/CD może doprowadzić do publikowania kolejnych skażonych artefaktów z pozornie prawidłowym pochodzeniem. To bezpośrednio podważa zaufanie do pipeline’ów, procesów budowania i mechanizmów automatyzacji. Dodatkowo wykorzystanie repozytoriów kodu, platform developerskich i artefaktów builda jako kanałów eksfiltracji ogranicza skuteczność tradycyjnych metod wykrywania opartych wyłącznie na analizie ruchu sieciowego.
- Ryzyko przejęcia kont maintainerów i repozytoriów.
- Możliwość wycieku kluczy chmurowych, tokenów CI/CD i sekretów npm.
- Infekowanie kolejnych projektów przez zmodyfikowane workflow i commity.
- Trudniejsza detekcja z uwagi na użycie zaufanych usług i niestandardowych technik uruchamiania kodu.
Rekomendacje
Organizacje powinny traktować bezpieczeństwo npm jako pełnoprawny element ochrony łańcucha dostaw. W pierwszym kroku należy ustalić, czy w środowisku użyto wskazanych wersji pakietów lub innych artefaktów opublikowanych z przejętych kont. Jeżeli istnieje choćby podejrzenie kompromitacji, konieczna jest rotacja wszystkich potencjalnie narażonych poświadczeń, w tym tokenów npm, kluczy SSH, sekretów chmurowych, tokenów GitHub Actions oraz danych wykorzystywanych przez narzędzia AI.
Dobrym kierunkiem jest również ograniczenie wykonywania skryptów instalacyjnych i natywnych przebudów pakietów tam, gdzie nie są one niezbędne. Warto stosować lockfile, pinowanie zależności z użyciem hashy integralności oraz dodatkową weryfikację pochodzenia pakietów.
Po stronie CI/CD należy audytować workflow, monitorować nieautoryzowane zmiany w pipeline’ach i analizować artefakty buildów pod kątem obecności danych, które nie powinny się tam znaleźć. W środowiskach deweloperskich wskazane jest monitorowanie plików binding.gyp w pakietach, które normalnie nie korzystają z komponentów natywnych, oraz ograniczenie zaufania do nowych lub nagle zmienionych maintainerów.
- Przeprowadzić natychmiastowy przegląd używanych pakietów npm i historii publikacji.
- Zrotować sekrety po każdej podejrzanej instalacji lub kompromitacji runnera.
- Audytować GitHub Actions i inne workflow automatyzacji.
- Wzmacniać ochronę stacji roboczych i runnerów Linuksa, także pod kątem nadużyć eBPF.
Podsumowanie
Przypadki IronWorm i nowego wariantu Miasma potwierdzają, że ataki na supply chain npm stają się coraz bardziej złożone, zautomatyzowane i trwałe. Napastnicy nie ograniczają się już do jednorazowego osadzenia złośliwego kodu w pakiecie, lecz próbują uzyskać trwałą obecność w repozytoriach, pipeline’ach i środowiskach pracy programistów.
Dla zespołów bezpieczeństwa oznacza to konieczność rozszerzenia modelu obrony poza klasyczne IOC i objęcia monitoringiem całego cyklu życia oprogramowania. W praktyce kluczowe stają się nie tylko skanowanie zależności, ale również kontrola procesów publikacji, integralności workflow i ochrony sekretów wykorzystywanych przez nowoczesne narzędzia developerskie.