Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą dziś do najpoważniejszych zagrożeń dla ekosystemu open source. W przypadku npm ryzyko jest wyjątkowo duże, ponieważ pojedynczy zainfekowany pakiet może zostać automatycznie pobrany jako zależność bezpośrednia lub pośrednia przez tysiące projektów, środowisk deweloperskich i pipeline’ów CI/CD.
Kampania nazwana ChainDrop pokazuje, że nowoczesne zagrożenia supply chain nie ograniczają się już do jednorazowego przejęcia biblioteki. Mamy do czynienia z modelem bardziej agresywnym: malware kradnie poświadczenia, przejmuje kolejne procesy publikacji i próbuje samodzielnie rozprzestrzeniać się w ekosystemie pakietów.
W skrócie
ChainDrop to szeroko zakrojony atak na łańcuch dostaw npm, w ramach którego przejęto ponad 1300 pakietów o łącznej skali około 2 miliardów miesięcznych pobrań. Według dostępnych analiz kampania rozpoczęła się od kompromitacji konta GitHub maintenera związanego z projektem Keyv, a następnie rozprzestrzeniła się na kolejne pakiety i organizacje.
Złośliwe wydania zawierały skrypt uruchamiany automatycznie podczas instalacji przez mechanizm preinstall. Payload pobierał środowisko wykonawcze Bun, uruchamiał złośliwy kod JavaScript, wykradał tokeny i sekrety z maszyn deweloperskich oraz runnerów CI/CD, a następnie próbował infekować kolejne pakiety przy użyciu uzyskanych poświadczeń.
Kontekst / historia
Ekosystem npm od lat pozostaje atrakcyjnym celem dla cyberprzestępców ze względu na ogromny poziom zaufania do bibliotek open source i powszechne stosowanie automatycznych instalacji zależności. W wielu organizacjach skrypty instalacyjne są wykonywane bez dodatkowej walidacji, co tworzy wygodny wektor wejścia dla złośliwego kodu.
W przypadku ChainDrop kluczowa była kompromitacja procesu publikacji, a nie wyłącznie samego kodu źródłowego. Z dostępnych opisów wynika, że napastnik wprowadzał złośliwe pliki bezpośrednio do głównych gałęzi projektów, po czym publikował nowe wersje pakietów. Ponieważ publikacja odbywała się z użyciem legalnych workflow GitHub Actions, złośliwe wydania mogły wyglądać wiarygodnie także z perspektywy standardowych mechanizmów weryfikacji.
Skala tej kampanii wyróżnia incydent na tle wcześniejszych przypadków kompromitacji npm. Atak objął nie tylko popularne biblioteki, ale również pakiety powiązane z wieloma organizacjami, co wskazuje na aktywną propagację między maintenerami, repozytoriami i namespace’ami.
Analiza techniczna
Najważniejszym mechanizmem infekcji był wpis preinstall w pliku package.json. Oznacza to, że samo wykonanie npm install mogło uruchomić złośliwy kod jeszcze przed zakończeniem instalacji zależności i przed faktycznym użyciem pakietu przez aplikację. Z punktu widzenia obrony to scenariusz szczególnie niebezpieczny, ponieważ wykonanie następuje bardzo wcześnie, często z szerokimi uprawnieniami i dostępem do sekretów środowiskowych.
Złośliwe pakiety zawierały co najmniej dwa istotne komponenty: dropper setup.mjs oraz właściwy skrypt kradnący dane, opisywany jako Math_Symbol.js lub w niektórych wariantach math_init.js. Dropper pobierał runtime Bun z publicznych wydań, uruchamiał złośliwy skrypt, a następnie usuwał tymczasowe artefakty, utrudniając analizę powłamaniową.
Payload był silnie zaciemniony i przystosowany zarówno do pracy na stacjach deweloperskich, jak i w środowiskach automatyzacji. Z analiz wynika, że malware koncentrował się na pozyskiwaniu danych uwierzytelniających, sekretów chmurowych i informacji mogących umożliwić dalszą propagację.
- Zbierał zmienne środowiskowe procesów.
- Przeszukiwał lokalne pliki konfiguracyjne i pliki z poświadczeniami.
- Wyszukiwał tokeny GitHub, npm i GitHub Actions.
- Próbował pozyskiwać sekrety z AWS, w tym wartości z SSM Parameter Store i Secrets Manager.
- Odczytywał sekrety z Kubernetes i tokeny HashiCorp Vault.
- Zbierał poświadczenia do baz danych oraz dane dostępowe do usług chmurowych i komunikacyjnych.
Szczególnie groźny był moduł samorozprzestrzeniania. Jeśli malware zdobył tokeny lub dostęp do repozytoriów i procesów wydawniczych kolejnych maintenerów, mógł wstrzykiwać złośliwe pliki do następnych projektów i publikować nowe zainfekowane wersje. Taki model przypomina robaka działającego wewnątrz software supply chain, gdzie ruchem bocznym nie jest sieć lokalna, lecz relacje zaufania między repozytoriami, maintenerami i pipeline’ami publikacji.
Dodatkowym wskaźnikiem kompromitacji był domenowy kanał eksfiltracji używany do wynoszenia danych. Część analiz wskazywała również na przesyłanie zaszyfrowanych danych do publicznych repozytoriów, co pokazuje elastyczne podejście operatorów kampanii do infrastruktury C2 i metod eksfiltracji.
Konsekwencje / ryzyko
Największe ryzyko dotyczy organizacji, które instalowały podatne wersje pakietów w środowiskach mających dostęp do sekretów produkcyjnych, kont chmurowych lub tokenów publikacyjnych. W praktyce nawet jednorazowe wykonanie npm install mogło doprowadzić do pełnej kompromitacji stanowiska deweloperskiego albo runnera CI/CD.
Ryzyko ma charakter wielowarstwowy i wykracza daleko poza samą obecność złośliwego pakietu w zależnościach.
- Kradzież tokenów dostępowych może prowadzić do przejęcia kolejnych repozytoriów.
- Przejęcie CI/CD może skutkować publikacją dalszych złośliwych artefaktów.
- Ujawnienie sekretów chmurowych może otworzyć drogę do ruchu bocznego w infrastrukturze.
- Kompromitacja zależności pośrednich utrudnia szybkie ustalenie pełnej ekspozycji.
Ważne jest także to, że usunięcie zainfekowanego pakietu po incydencie nie eliminuje skutków naruszenia. Jeżeli złośliwy kod uruchomił się podczas instalacji, wszystkie dostępne w tym momencie sekrety należy traktować jako potencjalnie ujawnione. Z perspektywy reagowania oznacza to konieczność przyjęcia założenia o kompromitacji, a nie jedynie o błędzie w zależnościach.
Rekomendacje
Organizacje korzystające z Node.js i npm powinny potraktować incydent ChainDrop jako sygnał do przeglądu całego modelu bezpieczeństwa zależności oraz procesu publikacji i automatyzacji.
Najważniejsze działania operacyjne obejmują:
- Zidentyfikowanie, czy w środowisku instalowano podatne wersje wskazanych pakietów.
- Uznanie maszyn deweloperskich i runnerów CI/CD za skompromitowane, jeśli doszło do instalacji złośliwych wersji.
- Rotację wszystkich tokenów dostępnych w zainfekowanych środowiskach, w tym GitHub, npm, chmurowych i wewnętrznych.
- Analizę logów repozytoriów, workflow oraz systemów IAM pod kątem nieautoryzowanych działań.
- Sprawdzenie historii commitów i wydań pakietów pod kątem nieoczekiwanych zmian.
- Odbudowę zaufanych środowisk z czystych obrazów lub bezpiecznych kopii zapasowych.
Długoterminowo warto wdrożyć również dodatkowe zabezpieczenia architektoniczne i proceduralne:
- Allowlisting zależności i wersji.
- Blokowanie lub ograniczanie wykonywania skryptów install i preinstall tam, gdzie to możliwe.
- Izolację runnerów CI/CD oraz minimalizację uprawnień sekretów.
- Podpisywanie artefaktów i dodatkową walidację procesu publikacji.
- Skanowanie pakietów pod kątem złośliwych hooków i anomalii w pipeline’ach release.
- Separację sekretów deweloperskich od produkcyjnych.
- Monitoring wskaźników kompromitacji związanych z kampanią.
Dobrą praktyką pozostaje również regularny przegląd zależności, które rzeczywiście wymagają skryptów instalacyjnych. W wielu przypadkach ograniczenie tego mechanizmu znacząco zmniejsza powierzchnię ataku bez wpływu na funkcjonalność aplikacji.
Podsumowanie
ChainDrop jest przykładem nowej generacji ataków na łańcuch dostaw npm, w których złośliwe oprogramowanie nie tylko kradnie sekrety, ale aktywnie wykorzystuje je do dalszej propagacji. Skala kampanii, użycie legalnych workflow publikacji i koncentracja na środowiskach deweloperskich oraz CI/CD pokazują, że tradycyjne zaufanie do popularnych pakietów nie jest już wystarczającą strategią bezpieczeństwa.
Dla zespołów bezpieczeństwa i DevSecOps najważniejszy wniosek jest prosty: ochrona łańcucha dostaw musi obejmować nie tylko skanowanie kodu, lecz także kontrolę procesu publikacji, egzekwowanie minimalnych uprawnień, ochronę sekretów oraz monitorowanie zachowań instalacyjnych zależności. W przeciwnym razie pojedyncza kompromitacja maintenera może szybko przekształcić się w incydent obejmujący tysiące projektów.
Źródła
- Massive ChainDrop npm supply-chain attack infects hundreds of packages — https://www.bleepingcomputer.com/news/security/massive-chaindrop-npm-supply-chain-attack-infects-hundreds-of-packages/
- Aikido researchers warn (cytowane w raporcie o incydencie) — https://www.bleepingcomputer.com/news/security/massive-chaindrop-npm-supply-chain-attack-infects-hundreds-of-packages/
- Wiz – analiza i lista wskaźników kompromitacji dla ChainDrop — https://www.wiz.io/
- StepSecurity – materiały dotyczące złośliwych pakietów npm — https://www.stepsecurity.io/
- Socket – analiza zagrożeń w ekosystemie npm — https://socket.dev/