Shai-Hulud-ormen i npm: Slik spredte angrepet seg til over 1 280 pakker

Slik startet angrepet

Rundt klokken 09.00 UTC 4. august fikk en angriper kontroll over GitHub-kontoen jaredwray . Tilgangen ble brukt til å legge inn ondsinnet kode direkte i main-grenen til keyv-prosjektet og publisere nye versjoner av pakker i keyv- og cacheable-familiene .

Den første bølgen omfattet 11 pakker på tvers av de to navnerommene. Blant dem var keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache og file-entry-cache . Sikkerhetsmiljøer som Aikido Security, StepSecurity, Socket og Chainguard bekreftet kompromitteringen i løpet av de første timene .

De ondsinnede filene som ble lagt inn

De infiserte pakkene fulgte i hovedsak samme mønster. Angriperne la til to filer:

• setup.mjs
• Math_Symbol.js

I tillegg ble package.json endret med et automatisk preinstall-skript:

"preinstall": "node setup.mjs"

Det betyr at setup.mjs ble kjørt automatisk når en utvikler eller en CI/CD-jobb installerte pakken med npm install, før installasjonen var fullført .

setup.mjs fungerte som en såkalt dropper. Skriptet lastet ned en legitim binærfil for JavaScript-kjøremiljøet Bun fra GitHub Releases, og brukte den til å starte den obfuskerte nyttelasten Math_Symbol.js, som var rundt 710–728 kilobyte stor . Microsoft Threat Intelligence bekreftet at nyttelasten var en Mini Shai-Hulud-variant .

Hvilke hemmeligheter skadevaren jaktet på

Nyttelasten var laget for å hente ut et bredt spekter av tilgangsopplysninger fra utviklermaskiner og byggemiljøer . Den målrettet blant annet:

• npm-autentiseringstokener
• GitHub personal access tokens (PAT-er)
• AWS-nøkler
• Kubernetes-hemmeligheter
• HashiCorp Vault-tokener
• Stripe-nøkler
• Slack-tokener
• SSH-nøkler
• Terraform state-filer
• Docker-legitimasjon
• VPN-konfigurasjoner

Det er særlig alvorlig i CI/CD-miljøer, der miljøvariabler og tjenestekontoer ofte gir tilgang til kildekode, pakkeutgivelser, skytjenester og produksjonsinfrastruktur.

Ormen spredte seg ved å bruke stjålne nøkler

Angrepet var mer enn en vanlig kompromittering av noen få npm-pakker. Etter å ha stjålet npm-publiseringstokener og GitHub-token fra et infisert miljø, brukte ormen tilgangen til å publisere nye, ondsinnede versjoner av pakker som tilhørte andre vedlikeholdere .

Omfanget økte raskt:

• Etter omtrent to timer hadde StepSecurity registrert 435 pakker og 1 557 versjoner med skadevare .
• Tidlig på ettermiddagen talte Aikido Security 868 kompromitterte pakker fordelt på 1 381 versjoner .
• Ved slutten av dagen var tallet steget til over 1 280 pakker og mer enn 1 680 versjoner, ifølge BleepingComputer og andre sikkerhetskilder .

Ormen holdt seg ikke til keyv- og cacheable-navnerommene. Den hoppet videre til pakker som tilhørte andre, uavhengige vedlikeholdere og organisasjoner, blant annet Deliveroo, Ornikar, OneReach, Picsart, Qlik og ServiceTitan .

Hvor ble de stjålne dataene sendt?

De innsamlede tilgangsopplysningene ble sendt til et GitHub-repositorium kontrollert av angriperen. Ormen kunne enten opprette et nytt repositorium eller bruke et dedikert repositorium for uthenting av data .

Nyttelasten hadde dessuten flere parallelle kanaler for datauthenting, slik at angrepet kunne fortsette selv om én kanal ble stengt .

Hva bør berørte virksomheter gjøre?

Sikkerhetsforskere anbefalte at alle miljøer som hadde installert en berørt pakke, ble behandlet som potensielt kompromitterte. Det er ikke tilstrekkelig å slette de ondsinnede filene manuelt.

1. Lås eller rull tilbake pakker

Stans installasjon av berørte versjoner umiddelbart. Bruk kjente, rene versjoner og lås avhengigheter så de ikke oppdateres automatisk.

I package.json kan team bruke overrides for npm, eller tilsvarende mekanismer i Yarn og pnpm, for å hindre at kompromitterte versjoner installeres på nytt . Kontroller også lockfiler som:

• package-lock.json
• yarn.lock
• pnpm-lock.yaml

Sjekken må omfatte både direkte og transitive avhengigheter .

2. Behandle berørte maskiner som kompromitterte

En maskin eller CI/CD-runner som har kjørt npm install med en berørt versjon, bør ikke anses som ren bare fordi pakken er fjernet . Alle hemmeligheter som var tilgjengelige på systemet, må vurderes som eksponert.

3. Deaktiver overvåkere før du roterer tokenene

Forskerne advarte om at skadevaren i noen tilfeller opprettet GitHub-workflower eller overvåkere som kunne fange opp nye tokenverdier idet de ble opprettet . Slå derfor av eller fjern slike mekanismer før du genererer nye nøkler .

4. Tilbakekall og opprett alle relevante nøkler på nytt

Tilgangene må tilbakekalles og erstattes, ikke bare endres lokalt. Dette gjelder blant annet :

• npm-tokener, både klassiske og granulære
• GitHub PAT-er og finmaskede token
• AWS IAM-nøkler og andre skynøkler
• Kubernetes service account-tokener
• HashiCorp Vault-tokener
• Stripe- og Slack-tokener
• SSH-nøkler
• Docker-legitimasjon
• VPN-tokener

Prioriter først nøkler som kan brukes til å publisere pakker, endre kildekode eller få tilgang til produksjonsmiljøer.

5. Tøm hurtigbuffere og bygg alt på nytt

Tøm npm-, pnpm- og Yarn-buffere på utviklermaskiner og CI/CD-runnere. Docker build-cacher og andre byggartefakter bør også fjernes .

Bygg deretter artefaktene på nytt fra et rent utgangspunkt. Ellers kan en kompromittert avhengighet bli liggende i en cache eller et Docker-lag og bli trukket inn igjen .

6. Undersøk GitHub og CI/CD-miljøene

Se etter nye repositorier, ukjente workflows, uautoriserte commits og andre tegn på utholdenhet . Forskere har blant annet anbefalt å undersøke filer som .claude/settings.json og .vscode/tasks.json, som skadevaren kan ha opprettet .

Hva angrepet viser

Shai-Hulud-angrepet viser hvor raskt et kompromittert vedlikeholdermiljø kan utvikle seg til et problem for hele programvareleverandørkjeden. Ett kapret GitHub-konto kunne brukes til å publisere skadevare i en sentral pakke, stjele publiseringstilganger og deretter infisere pakker som tilhørte andre.

Bruken av en legitim Bun-binærfil for å starte nyttelasten, automatisk kjøring gjennom preinstall, selvspredning via stjålne token og flere kanaler for datauthenting gjorde kampanjen særlig motstandsdyktig .

For utviklings- og sikkerhetsteam er lærdommen tydelig: lås avhengigheter, vurder å deaktivere pre- og postinstall-skript der det er mulig, overvåk uvanlig aktivitet i GitHub og ha en klar beredskapsplan for kompromitterte pakker.