Atak na łańcuch dostaw npm: malware IronWorm infekuje 36 pakietów i kradnie klucze AI

Nowa kampania złośliwego oprogramowania uderzyła w ekosystem JavaScript. Malware o nazwie IronWorm zainfekował 36 pakietów w repozytorium npm (Node Package Manager), kradnąc dane uwierzytelniające do platform AI, chmur obliczeniowych i portfeli kryptowalut. Atak jest szczególnie groźny, bo sam się rozprzestrzenia – wykorzystuje skradzione dane do publikowania kolejnych zainfekowanych pakietów. Problem dotyczy programistów, firm korzystających z otwartego oprogramowania oraz każdego, kto używa aplikacji opartych na Node.js.

Czym jest IronWorm i jak działa?

Jak wynika z analizy badaczy z firmy JFrog, IronWorm to infostealer napisany w języku Rust. Jego celem są 86 zmiennych środowiskowych oraz 20 plików z danymi uwierzytelniającymi. Wśród wykradanych informacji znajdują się klucze dostępu do OpenAI, AWS, Anthropic, a także pliki konfiguracyjne SSH, dane portfela kryptowalut Exodus oraz tokeny npm.

Malware ukrywa się za rootkitem eBPF (Extended Berkeley Packet Filter) – mechanizmem działającym na poziomie jądra systemu, który pozwala ukryć jego obecność przed standardowymi narzędziami bezpieczeństwa. Komunikacja z operatorem odbywa się przez sieć Tor, co dodatkowo utrudnia śledzenie.

IronWorm sam się replikuje. Po skompromitowaniu środowiska programisty lub systemu CI (Continuous Integration) wykorzystuje skradzione dane do publikowania trojanizowanych wersji pakietów należących do ofiary. W ten sposób infekuje kolejnych programistów i systemy CI. Badacze JFrog zauważają, że to zachowanie jest koncepcyjnie podobne do wcześniejszego malware Shai Hulud, którego kod został niedawno opublikowany na GitHubie. Choć bezpośredniego powiązania nie potwierdzono, w obu atakach zaobserwowano te same nazwy commitów.

Mechanizm ataku i unikanie wykrycia

Kampania rozpoczęła się od skompromitowanego konta o nazwie asteroiddao. Opublikowano z niego wersje pakietów zawierające binarny plik ELF w Rust, uruchamiany przez skrypt preinstall. Autor commitów widnieje jako „claude”, a znaczniki czasowe wskazują na kilka lat wstecz – w niektórych przypadkach nawet 13 lat – mimo że commity zostały wypchnięte w ciągu ostatnich dni. To celowe działanie, mające utrudnić śledztwo.

Szczególnie interesujący jest mechanizm dostarczania skradzionych danych. JFrog wyjaśnia, że malware serializuje sekrety w pojedynczą wartość, a następnie zapisuje ją do pliku o nieszkodliwie wyglądającej nazwie, jakby to był wynik formatowania kodu. Plik jest następnie przesyłany jako artefakt budowania (build artifact) na GitHub Actions, skąd może go pobrać każdy, kto ma dostęp. Dzięki temu atakujący unika potrzeby posiadania zewnętrznego serwera dowodzenia (C2). Badacze zaznaczają jednak, że ten mechanizm nie został jeszcze użyty w analizowanym ataku.

Kolejną osobliwością jest to, że operator zakodował na stałe frazę odzyskiwania własnego portfela kryptowalut. Zdaniem badaczy jedynym powodem jest to, że twórca malware nie chciał, by jego własne narzędzie wykradło te dane podczas testów.

Jak się chronić? Praktyczne zalecenia

Firma Ox Security, która specjalizuje się w bezpieczeństwie aplikacji, informuje, że atak został wykryty bardzo wcześnie i zatrzymany, zanim rozprzestrzenił się na popularniejsze pakiety. Mimo to programiści i administratorzy powinni podjąć konkretne kroki:

• Zaktualizuj pakiety – sprawdź, czy używasz którejś z 36 zainfekowanych wersji. Lista pakietów i ich poprawnych wersji znajduje się w raporcie JFrog i Ox Security.
• Rotuj klucze i tokeny – po aktualizacji zmień wszystkie dane uwierzytelniające, które mogły być przechowywane w zmiennych środowiskowych lub plikach konfiguracyjnych na skompromitowanych maszynach.
• Włącz uwierzytelnianie dwuskładnikowe (2FA) – dla wszystkich kont, szczególnie tych z dostępem do repozytoriów kodu i systemów CI/CD.
• Monitoruj artefakty budowania – sprawdzaj, czy w repozytoriach nie pojawiają się podejrzane pliki, które mogą być nośnikiem skradzionych danych.
• Ogranicz zaufanie do pakietów zewnętrznych – rozważ użycie narzędzi do skanowania zależności i audytu bezpieczeństwa, takich jak npm audit, Snyk czy GitHub Dependabot.

Warto też pamiętać, że w tym samym czasie firmy Endor Labs i StepSecurity wykryły podobny, ale odrębny atak z użyciem malware JavaScript o nazwie binding.gyp, który również infekował pakiety npm i GitHub Actions. To pokazuje, że ataki na łańcuch dostaw npm stają się coraz bardziej powszechne i wyrafinowane.

Dla polskich programistów i firm korzystających z Node.js oznacza to konieczność wzmożonej czujności. Nawet jeśli bezpośrednio nie używasz zainfekowanych pakietów, twoi podwykonawcy lub biblioteki, od których zależysz, mogą być narażone. Warto regularnie przeglądać swoje zależności i reagować na komunikaty o podatnościach.