Mini Shai-Hulud, nuova ondata: 639 versioni npm compromesse in un'ora

Ieri notte, attorno alle 01:56 UTC, una nuova ondata della campagna Mini Shai-Hulud ha colpito il registro npm pubblicando 639 versioni malevole su 323 pacchetti unici in meno di un'ora. Il dato circolato come "600 pacchetti compromessi" si riferisce in realtà alle versioni pubblicate: i pacchetti distinti effettivamente coinvolti sono sotto i 350.

Il vettore iniziale è l'account maintainer atool, che gestisce l'intero stack @antv di Alibaba (libreria di data visualization e charting) e pacchetti popolari come timeago.js, echarts-for-react, size-sensor e jest-canvas-mock. Quest'ultimo conta oltre 2 milioni di download settimanali, echarts-for-react circa 1,1 milioni, timeago.js circa 1,5 milioni. Una credenziale compromessa su un solo account ha aperto la propagazione su qualcosa come decine di milioni di download settimanali.

Provenance valida su codice malevolo

L'elemento di novità identificato da Endor Labs e Socket riguarda il sistema con cui i pacchetti open source vengono firmati per garantirne l'origine. Si chiama Sigstore ed è stato adottato negli ultimi due anni come elemento minimo contro la manomissione del software: quando un maintainer pubblica una nuova versione di un pacchetto, la macchina automatica che ne esegue la build (il "runner" della pipeline di integrazione continua) ottiene dal proprio provider, di norma GitHub, un tagliando di identità temporaneo. Quel tagliando, tecnicamente un token OIDC, viene presentato a Fulcio, l'autorità certificatrice di Sigstore, che in cambio rilascia un certificato di firma valido pochi minuti e vincolato a quella specifica identità. La firma viene poi registrata in un registro pubblico e auditabile chiamato Rekor. Chi installa il pacchetto può verificare in automatico che la firma sia autentica e che provenga da una pipeline riconosciuta, comprese le attestazioni di livello SLSA Build Level 3.

Il worm Mini Shai-Hulud sfrutta questo meccanismo: il payload viene eseguito durante l'installazione di una dipendenza compromessa, quindi quasi sempre dentro il runner di un altro maintainer che sta pubblicando un proprio pacchetto. Da lì il malware legge il token OIDC che il runner ha appena ricevuto e lo usa per chiedere a Fulcio un certificato a suo nome. Fulcio ne emette uno, correttamente poiché il token è autentico e il workflow è quello dichiarato. Il worm firma il pacchetto malevolo con quel certificato, registra l'attestazione su Rekor e lo pubblica su npm con il badge di provenance verde. La crittografia ha funzionato come previsto, ma quello che è stato compromesso è l'assunto sottostante: che una pipeline legittima firmi solo codice legittimo. Se la pipeline ospita il malware come dipendenza al momento della firma, l'identità certificata resta vera ma il contenuto firmato è ostile. Quanto accaduto rischia di essere uno spartiacque dove la provenance signing, presentata da circa diciotto mesi come baseline contro gli attacchi alla supply chain, smette di funzionare come garanzia sull'integrità del codice pubblicato.

Il payload raccoglie più di venti tipologie di credenziali: chiavi AWS, GCP e Azure, service account Kubernetes, token HashiCorp Vault, credenziali npm e GitHub, stringhe di connessione database, oltre ai vault locali di 1Password e Bitwarden. L'esfiltrazione avviene attraverso la rete P2P Session, che maschera il traffico come comunicazione cifrata di messaggistica, con GitHub usato come canale di backup: in presenza di un token GitHub utilizzabile, il malware crea un repository pubblico sotto l'account della vittima e committa il bottino in formato JSON. La descrizione dei repository riporta la stringa invertita niagA oG eW ereH :duluH-iahS, che letta nel verso giusto restituisce "Shai-Hulud: Here We Go Again". I repository censiti oscillano fra i 1.900 di Socket e i 2.700 di Aikido, divergenza compatibile con il fatto che la campagna è ancora in corso.

Persistenza oltre la rimozione del pacchetto

Rimuovere il pacchetto malevolo non risolve il problema: il payload scrive backdoor in .vscode/tasks.json e .claude/settings.json, le configurazioni di task autorun di VS Code e degli hook di Claude Code, e installa servizi a livello di sistema operativo, quali un systemd user service su Linux e un LaunchAgent su macOS. Un processo denominato kitty-monitor interroga GitHub ogni ora cercando commit firmati che fungano da canale di comando, mentre gh-token-monitor verifica ogni sessanta secondi se il token rubato è ancora valido. La vittima che revoca le credenziali notifica l'attaccante in tempo reale.

Il meccanismo di autopropagazione è invariato rispetto alle ondate precedenti. Una volta acquisito un token npm valido, il worm enumera i pacchetti su cui il proprietario ha permessi di pubblicazione, scarica i tarball, inietta il payload e ripubblica con versione incrementata. Ogni account compromesso diventa il punto di ingresso per il successivo.

L'attribuzione a TeamPCP, il gruppo dietro le ondate Mini Shai-Hulud precedenti (TanStack, Mistral AI, UiPath, Bitwarden CLI, pacchetti SAP), è probabile ma non confermata: il codice sorgente del worm è stato rilasciato dallo stesso gruppo su BreachForums nei giorni scorsi nell'ambito di un "contest" di supply-chain attack, rendendo il framework disponibile a copycat. Datadog ha già osservato versioni clonate del worm con infrastruttura C2 indipendente. Secondo Socket, l'intera campagna Mini Shai-Hulud totalizza adesso 1.055 versioni malevole su 502 pacchetti unici fra npm, PyPI e Composer.

Chi ha installato uno dei pacchetti coinvolti deve trattare la macchina come compromessa: ruotare tutte le credenziali raggiungibili dal runner, eseguire npm ci --ignore-scripts nelle build CI per sopprimere i lifecycle hook, e ispezionare .vscode/tasks.json e .claude/settings.json per gli artefatti di persistenza. Il badge di provenance Sigstore, in questo contesto, non è un indicatore di sicurezza attendibile.