Złośliwe pakiety AsyncAPI w npm wykorzystały legalny pipeline do dostarczenia malware botnetowego - Security Bez Tabu

Złośliwe pakiety AsyncAPI w npm wykorzystały legalny pipeline do dostarczenia malware botnetowego

Cybersecurity news

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla ekosystemu open source. Najnowszy incydent związany z pakietami AsyncAPI w rejestrze npm pokazuje, że nawet prawidłowo działający proces publikacji i poprawne atestacje pochodzenia nie gwarantują bezpieczeństwa artefaktów. W tym przypadku złośliwy kod został osadzony w legalnie wyglądających paczkach JavaScript i uruchamiał się dopiero podczas załadowania modułu przez środowisko Node.js.

To istotna zmiana względem bardziej typowych kampanii, które opierają się na skryptach wykonywanych w trakcie instalacji zależności. Dzięki temu atakujący mogli ograniczyć ryzyko szybkiego wykrycia i zwiększyć szansę na uruchomienie ładunku dopiero w realnym środowisku deweloperskim lub CI/CD.

W skrócie

Zidentyfikowano skompromitowane wersje kilku pakietów AsyncAPI publikowanych w npm, które dostarczały wieloetapowy loader prowadzący do uruchomienia malware określanego jako Miasma. Wśród wskazywanych wersji znalazły się między innymi @asyncapi/generator-helpers@1.1.1, @asyncapi/generator-components@0.7.1, @asyncapi/generator@3.3.1 oraz @asyncapi/specs w wersjach 6.11.2 i 6.11.2-alpha.1.

Według ustaleń badaczy napastnicy mieli uzyskać dostęp typu push do repozytoriów projektu i wykorzystać legalny pipeline GitHub Actions do opublikowania pakietów z poprawnymi atestacjami OIDC. Oznacza to, że problem nie wynikał wyłącznie z przejęcia tokenu publikacyjnego npm, lecz z kompromitacji procesu wytwórczego i uprawnień do repozytorium.

  • Złośliwy kod nie aktywował się podczas instalacji, lecz po załadowaniu modułu.
  • Ładunek był dostarczany etapowo, co utrudniało analizę.
  • Publikacja odbyła się z użyciem autoryzowanego workflow projektu.
  • Ryzykiem objęte były zarówno stacje deweloperskie, jak i środowiska CI/CD.

Kontekst / historia

Ataki na rejestry pakietów, takie jak npm, PyPI czy Cargo, od lat należą do najskuteczniejszych metod infekowania środowisk programistycznych i pipeline’ów budowania oprogramowania. W przeszłości dominowały prostsze kampanie wykorzystujące skrypty preinstall i postinstall, które wykonywały szkodliwe działania już podczas pobierania zależności.

W opisywanym przypadku zastosowano bardziej dyskretną technikę. Złośliwa logika została ukryta bezpośrednio w module i aktywowała się dopiero wtedy, gdy biblioteka była faktycznie używana. Taki model działania pozwala ominąć część podstawowych kontroli bezpieczeństwa i zmniejsza prawdopodobieństwo wykrycia podczas prostego audytu instalowanych paczek.

Incydent wpisuje się w szerszy trend, w którym atakujący coraz częściej koncentrują się nie tylko na samym rejestrze pakietów, ale na całym łańcuchu zaufania obejmującym repozytorium źródłowe, workflow CI/CD, mechanizmy podpisywania oraz automaty publikacyjne.

Analiza techniczna

Z dostępnych analiz wynika, że złośliwe pakiety zawierały implant JavaScript inicjujący pierwszy etap infekcji po załadowaniu modułu przez Node.js. Następnie uruchamiany był odseparowany proces działający w tle, którego zadaniem było pobranie kolejnego etapu z infrastruktury opartej o IPFS.

Drugi etap miał postać zaszyfrowanego loadera JavaScript o nazwie sync.js, zapisywanego lokalnie w ścieżkach zależnych od systemu operacyjnego i następnie wykonywanego na hoście. Loader zawierał zarówno zaszyfrowany właściwy payload, jak i dodatkowy duży blob danych używany do inicjowania kolejnych komponentów malware.

Końcowy framework, określany jako Miasma, miał składać się z setek modułów i wspierać wiele kanałów komunikacji C2. W analizach wskazywano między innymi na HTTP, Nostr, IPFS, BitTorrent DHT, libp2p GossipSub oraz mechanizm związany ze smart kontraktami w sieci Ethereum. Taka architektura zwiększa odporność operacji na blokowanie pojedynczych serwerów, domen czy adresów IP.

Możliwości szkodliwego oprogramowania wykraczały poza prosty downloader. Opisywane funkcje obejmowały kradzież poświadczeń, ruch boczny w sieci lokalnej, utrzymywanie trwałości oraz potencjalną propagację przypominającą robaka w ekosystemach npm, PyPI i Cargo. Mechanizmy persistence miały wykorzystywać różne techniki zależnie od platformy, w tym systemd, crontab, launchd oraz klucze autostartu w systemie Windows.

Istotnym elementem był również zestaw mechanizmów utrudniających analizę. Badacze wskazywali na unikanie środowisk sandbox i maszyn wirtualnych, omijanie wybranych narzędzi ochronnych oraz obecność logiki przypominającej „dead man’s switch”, która w określonych warunkach mogła inicjować czyszczenie artefaktów lub katalogów roboczych.

Najważniejszy technicznie wniosek dotyczy jednak wektora publikacji. Prawidłowe atestacje pochodzenia potwierdzały jedynie, że artefakt został zbudowany przez autoryzowany pipeline, a nie że sam commit inicjujący publikację był legalny i niezmodyfikowany przez napastnika. To pokazuje ograniczenia samego zaufania do mechanizmów provenance bez równoległej ochrony repozytorium źródłowego.

Konsekwencje / ryzyko

Skutki tego incydentu należy analizować szerzej niż tylko jako problem pojedynczej złośliwej paczki npm. Jeżeli podatna wersja została nie tylko pobrana, ale również zaimportowana i wykonana, zagrożone mogły być stacje deweloperskie, runnery CI, systemy buildowe oraz inne elementy infrastruktury mające dostęp do sekretów i poświadczeń.

  • możliwość wykonania złośliwego kodu na stacji roboczej lub serwerze CI,
  • kradzież tokenów, kluczy API i innych sekretów dostępnych w środowisku,
  • uzyskanie trwałości na hostach końcowych,
  • ruch boczny w sieci lokalnej i dalsza eskalacja dostępu,
  • wykorzystanie zainfekowanego środowiska do dalszego zatruwania zależności.

Szczególnie wysokie ryzyko dotyczy organizacji, w których zainfekowane pakiety działały w pipeline’ach z dostępem do poświadczeń chmurowych, tokenów repozytoriów, kluczy publikacyjnych lub systemów produkcyjnych. W takich przypadkach incydent może bardzo szybko przekształcić się w pełnoskalowe naruszenie bezpieczeństwa środowiska wytwórczego.

Rekomendacje

Organizacje korzystające z AsyncAPI lub powiązanych pakietów powinny niezwłocznie ustalić, czy wskazane wersje były pobierane, importowane lub wykonywane w środowiskach deweloperskich oraz CI/CD. Sama obecność paczki w lokalnym cache nie musi oznaczać kompromitacji, jednak jej rzeczywiste uruchomienie znacząco podnosi poziom ryzyka.

  • przeprowadzić pełny przegląd logów buildów, runnerów CI i stacji deweloperskich,
  • zidentyfikować użycie konkretnych skompromitowanych wersji pakietów,
  • rotować wszystkie sekrety dostępne z potencjalnie zainfekowanych hostów,
  • przeanalizować połączenia wychodzące do nietypowych usług i kanałów P2P,
  • zweryfikować obecność mechanizmów persistence na Windows, Linux i macOS,
  • izolować oraz poddać analizie forensic systemy, które mogły wykonać złośliwy moduł.

Z perspektywy strategicznej warto rozszerzyć ochronę łańcucha dostaw o analizę zachowania zależności w runtime, a nie tylko skanowanie skryptów instalacyjnych. Kluczowe znaczenie ma także wzmocnienie bezpieczeństwa repozytoriów źródłowych poprzez silne MFA, ochronę branchy, wymagane przeglądy zmian oraz monitorowanie nietypowych pushy i publikacji.

  • ograniczyć uprawnienia runnerów CI/CD do niezbędnego minimum,
  • stosować krótko żyjące sekrety i tymczasowe poświadczenia,
  • blokować nieautoryzowane połączenia wychodzące z runnerów,
  • segmentować stacje deweloperskie od zasobów produkcyjnych,
  • wdrożyć allowlisty dla rejestrów i artefaktów,
  • regularnie utrzymywać SBOM oraz audytować zależności pośrednie,
  • wykrywać nietypowe procesy potomne uruchamiane przez Node.js.

Podsumowanie

Incydent z pakietami AsyncAPI pokazuje, że współczesne ataki supply chain stają się coraz bardziej subtelne, wieloetapowe i trudniejsze do wykrycia. Złośliwy kod nie wykorzystywał klasycznych hooków instalacyjnych, lecz aktywował się dopiero podczas realnego użycia modułu, a publikacja została przeprowadzona przez legalny pipeline projektu.

Najważniejszy wniosek dla zespołów bezpieczeństwa jest jednoznaczny: skuteczna ochrona łańcucha dostaw musi obejmować nie tylko rejestr pakietów i podpisy artefaktów, ale również bezpieczeństwo repozytoriów, workflow CI/CD, analizę zachowania kodu w runtime oraz ścisłą kontrolę sekretów. Każde środowisko, które zaimportowało i wykonało wskazane wersje pakietów, powinno być traktowane jako potencjalnie skompromitowane do czasu zakończenia pełnej analizy.

Źródła