Sådan spredte Shai-Hulud-ormen sig gennem npm

Angrebet begyndte med én kompromitteret vedligeholderkonto

Omkring klokken 09.00 UTC den 4. august overtog en angriber Jared Wrays GitHub-konto . Med adgangen kunne angriberen skubbe skadelig kode direkte til main-grenen i keyv-projektet og straks udgive nye versioner af pakker i hele keyv- og cacheable-familien .

Den første bølge omfattede 11 pakker på tværs af de to namespaces. Blandt dem var keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache og file-entry-cache . Sikkerhedsteams fra blandt andre Aikido Security, StepSecurity, Socket og Chainguard bekræftede kompromitteringen i løbet af de første timer .

Den skjulte kode: setup.mjs og Math_Symbol.js

De forgiftede pakker havde samme grundstruktur: To nye filer – setup.mjs og Math_Symbol.js – samt en ændring i package.json, hvor der blev tilføjet en automatisk preinstall-kommando:

"preinstall": "node setup.mjs"

Når en udvikler eller en CI/CD-runner kørte npm install, blev setup.mjs automatisk udført, før installationen var færdig . Filen fungerede som en såkaldt dropper: Den hentede en legitim binær udgave af JavaScript-runtime-miljøet Bun fra GitHub Releases og brugte den til at starte den obfuskerede andentrinskode Math_Symbol.js, der fyldte cirka 710–728 KB .

Microsoft Threat Intelligence har identificeret koden som en variant af Mini Shai-Hulud . Payloaden forsøgte blandt andet at indsamle:

• npm-autentificeringstokens
• GitHub Personal Access Tokens (PATs)
• AWS-nøgler
• Kubernetes-hemmeligheder
• HashiCorp Vault-tokens
• Stripe-nøgler
• Slack-tokens
• SSH-nøgler
• Terraform-statefiler
• Docker-legitimationsoplysninger
• VPN-konfigurationer

Ormen spredte sig ved hjælp af stjålne tokens

Det, der gjorde angrebet særligt farligt, var ormens evne til at sprede sig selv. Efter at have stjålet npm-publiceringstokens og GitHub-PATs fra et inficeret miljø brugte den disse rettigheder til at udgive nye, skadelige versioner af pakker, der tilhørte andre og uafhængige vedligeholdere .

Omfanget voksede hurtigt:

• Efter cirka to timer registrerede StepSecurity 435 pakker og 1.557 versioner som forgiftede .
• Tidligt på eftermiddagen, centraleuropæisk sommertid, talte Aikido Security 868 kompromitterede pakker fordelt på 1.381 versioner .
• Ved dagens slutning var tallet steget til over 1.280 pakker og over 1.680 versioner, ifølge BleepingComputer og andre sikkerhedsmedier .

Ormen blev ikke inden for den oprindelige keyv- og cacheable-familie. Den krydsede namespace-grænser og nåede pakker forbundet med blandt andre Deliveroo, Ornikar, OneReach, Picsart, Qlik og ServiceTitan .

De stjålne oplysninger blev sendt til GitHub

De indsamlede legitimationsoplysninger blev eksfiltreret til et GitHub-repository, som angriberen kontrollerede. Ormen kunne enten oprette et nyt repository eller bruge et dedikeret repository til at samle de stjålne data . Payloaden indeholdt desuden flere redundante eksfiltrationskanaler, så indsamlingen kunne fortsætte, selv hvis én kanal blev lukket .

Hvad skal berørte teams gøre?

Sikkerhedsforskere anbefalede, at alle maskiner, der havde installeret en berørt version, blev behandlet som fuldt kompromitterede. Det er altså ikke tilstrækkeligt blot at slette de skadelige filer.

1. Fastlås eller rul pakker tilbage

Fastlås straks afhængigheder til kendte, rene versioner, eller rul tilbage til versioner fra før kompromitteringen. Brug om nødvendigt overrides i npm, yarn eller pnpm – for eksempel "overrides" i package.json – så forgiftede versioner ikke installeres igen ved en fejl .

Gennemgå også lockfiler som package-lock.json, yarn.lock og pnpm-lock.yaml. Husk at kontrollere både direkte og transitive afhængigheder .

2. Behandl berørte værter som kompromitterede

En computer eller CI/CD-runner, der har kørt npm install med en berørt version, bør ikke anses for ren, blot fordi de skadelige filer er fjernet . Antag, at alle hemmeligheder, der var tilgængelige på værten, kan være blevet lækket.

3. Tilbagekald og udskift alle potentielt eksponerede nøgler

Tilbagekald og genskab alle legitimationsoplysninger, der kan have været tilgængelige:

• npm-tokens, både klassiske og granulære
• GitHub-PATs og fine-grained tokens
• AWS IAM- og access keys
• Kubernetes service account-tokens
• HashiCorp Vault-tokens
• Stripe- og Slack-nøgler
• SSH-nøgler
• Docker-legitimationsoplysninger
• VPN-tokens

4. Fjern overvågning, der kan lække nye tokens

Et vigtigt detaljepunkt er, at malwaren i nogle tilfælde oprettede GitHub-workflow-watchere, som kunne opsnappe eller eksponere et nyt token, så snart det blev oprettet . De berørte teams blev derfor anbefalet at deaktivere eller fjerne en sådan overvågning, før legitimationsoplysningerne blev roteret .

5. Ryd caches, og byg alt igen

Ryd npm-, pnpm- og yarn-caches samt Docker-buildcaches på både udviklermaskiner og CI/CD-runners . Genskab derefter artifacts fra bunden, så forgiftede afhængigheder ikke overlever i buildcaches eller Docker-lag .

6. Gennemgå GitHub og CI/CD-miljøer

Søg efter repositories, workflows og commits, som ikke er autoriseret . Gennemgå også miljøerne for tegn på vedvarende adgang, herunder filer som .claude/settings.json og .vscode/tasks.json, som ormen kan have oprettet .

Hvad angrebet viser

Shai-Hulud-angrebet viser, hvor hurtigt et kompromitteret vedligeholder-login kan udvikle sig til en bred forsyningskædekrise. Angriberne behøvede ikke direkte adgang til hvert enkelt projekt: Stjålne tokens gav ormen mulighed for at udgive nye forgiftede versioner og bevæge sig fra ét namespace til det næste.

Brugen af en legitim Bun-binær til at starte payloaden, den automatiske preinstall-krog, den selvspredende mekanisme og de redundante eksfiltrationskanaler gjorde kampagnen mere modstandsdygtig end mange tidligere npm-angreb .

For udviklings- og sikkerhedsteams er konklusionen klar: Fastlås afhængigheder, gennemgå transitive pakker, begræns installation scripts hvor det er muligt, overvåg usædvanlig GitHub-aktivitet, og hav en klar beredskabsplan for kompromitterede softwareafhængigheder.