Co opublikowano między 09:35 a 11:44 UTC

Pierwszym zatrutym wydaniem był keyv w wersji 6.0.0, opublikowany 4 sierpnia o 09:35 UTC. Semgrep, który nadał kampanii nazwę ChainDrop, policzył 1557 złośliwych wersji w 435 pakietach w fali, która nastąpiła później, między 09:40 a 11:44 UTC. Wiz śledził to samo zdarzenie, doszedł do ponad 400 różnych pakietów i powiązał je z kontem opiekuna, którego poświadczenia zostały ukradzione. Nie były to podróbki o zbliżonych nazwach ani nowe pakiety. Były to prawdziwe biblioteki, wydane ponownie pod nazwiskiem prawdziwego opiekuna, z dołączonym dodatkowym plikiem.

W ciągu pół godziny rozprzestrzenianie przekroczyło granice między organizacjami. Wśród dotkniętych przestrzeni nazw znalazły się @deliveroo, @ornikar, @qlik, @servicetitan, @onereach, @or-sdk, @arv-bedrock i @adminide-stack, obok samych rodzin keyv i cacheable. Te organizacje nie dzielą ani kodu, ani własności. Dzieliły ukradziony żeton publikacji: każde zakażenie zbierało poświadczenia npm z komputera, który instalował pakiet, a następnie używało ich do ponownego opublikowania wszystkiego innego, do czego ten żeton mógł dotrzeć. To właśnie czyni z tego robaka, a nie pojedyncze zatrute wydanie.

Nośnikami są pakiety, których nikt nie wybrał

Pobraliśmy liczby pobrań z rejestru npm za 30 dni zakończonych 3 sierpnia, dzień przed naruszeniem. keyv zebrał 619,7 miliona pobrań. flat-cache 579,8 miliona. file-entry-cache 571,2 miliona. cacheable-request 137,0 miliona, cacheable 30,1 miliona, a cache-manager 16,3 miliona. Te sześć bibliotek razem daje około 1,95 miliarda pobrań w miesiącu poprzedzającym zatrucie.

Prawie nikt nie instaluje flat-cache ani file-entry-cache świadomie. To pomocnicze biblioteki pamięci pośredniej, które przychodzą pod narzędziami analizy kodu i budowania, kilka poziomów niżej w drzewie zależności, w projektach, których odpowiedzialni nigdy nie wpisali żadnej z tych nazw. Tu leży niewygodna część rachunku. Pakiety o największym promieniu rażenia to właśnie te, których brakuje na liście zależności, którą przejrzałeś i zatwierdziłeś, więc audyt własnych decyzji mówi bardzo niewiele o tym zdarzeniu. Liczbą, która przewiduje twoją ekspozycję, jest to, ile razy twoje budowanie zostało uruchomione 4 sierpnia.

Złośliwy kod szukał asystenta sztucznej inteligencji

Mechanizmem był zaczep preinstall, a to istotne, bo działa on w czasie rozwiązywania zależności i nie czeka, aż twój kod cokolwiek zaimportuje. Pliki wczytujące, setup.mjs i math_init.js, pobierały samodzielne środowisko wykonawcze Bun i uruchamiały zaciemniony drugi etap. Wiz rozpoznał ruch po jego agencie użytkownika, Bun/1.3.13. Program zbierający sięgał po żetony npm, poświadczenia chmurowe, klucze SSH, sekrety CI, portfele kryptowalut oraz pliki konfiguracyjne narzędzi sztucznej inteligencji.

Zapisał także swoją trwałość w katalogach .claude i .vscode, co jest świadomym wyborem dotyczącym tego, gdzie programiści lokują dziś swoje zaufanie. Edytor i asystent sztucznej inteligencji mają dostęp do repozytorium, uprawnienia w wierszu poleceń i coraz częściej upoważnienie do wykonywania polecen. Kanał sterowania ukryto w inteligentnej umowie na Ethereum, czytanej wywołaniem eth_call i zwracającej domenę npm-cache[.]com, więc operatorzy mogą przenieść swoją infrastrukturę bez wysyłania nowego złośliwego kodu. Wyprowadzone dane trafiały do repozytoriów GitHub tworzonych pod przejętymi tożsamościami i zatytułowanych Shai-Hulud: Here We Go Again, od nazwy rodziny złośliwego kodu, z której ten pochodzi.

Dwie godziny wystarczą na ustalenie w ramach NIS2

Dla przedsiębiorstwa w Unii Europejskiej lub Wielkiej Brytanii pytanie o zgodność nie brzmi tylko, czy zostaliście dotknięci, ale czy potraficie opisać, co się stało. Dwie z dotkniętych przestrzeni nazw należą do Deliveroo i Ornikar, brytyjskiej platformy dostaw i francuskiej firmy prowadzącej szkoły nauki jazdy. Żadna z nich nie jest nieznanym sklepem i żadna nie wybrała udziału w tym zdarzeniu. NIS2 umieszcza bezpieczeństwo łańcucha dostaw po stronie zarządu, a nie zespołu bezpieczeństwa, a DORA wymaga od podmiotów finansowych tych samych dowodów w sprawie ryzyka technologii podmiotów trzecich.

Zapis waży więc tyle samo co usuwanie skutków. Ustalcie, czy jakieś budowanie działało 4 sierpnia między 09:35 a około 15:00 UTC, w chwili gdy udokumentowano kanał sterowania na Ethereum, a analiza jeszcze trwała. Wymieńcie każdy dostęp, do którego mógł dotrzeć wykonawca, nie tylko żeton npm: klucze chmurowe, żetony GitHub, klucze SSH oraz dostępy do Kubernetes i Terraform. Odbudujcie wykonawców, zamiast ich czyścić. Następnie zapiszcie, co wymieniliście i kiedy, bo właśnie tego dokumentu zażąda nadzór, audytor albo ubezpieczyciel. W Polsce zgłoszenie obowiązkowego incydentu trafia do zespołu CSIRT NASK.

Czytaj dalej: 16.000 firm łączy ryzyko dostawców. Ty nie  |  Poprawka podpisuje nowe pliki, a nie wasze archiwum