Il paradosso di Mini Shai-Hulud: quando la provenance SLSA certifica il malware

L'attacco supply chain Mini Shai-Hulud ha compromesso oltre 170 pacchetti npm e PyPI tramite OIDC federation e orphaned commit, colpendo anche OpenAI.

Contenuto

Il paradosso di Mini Shai-Hulud: quando la provenance SLSA certifica il malware
Il paradosso di Mini Shai-Hulud: quando la provenance SLSA certifica il malware

L’attacco supply chain denominato Mini Shai-Hulud ha trasformato lo standard d'oro della sicurezza moderna — la provenance validata — in un sofisticato vettore d'attacco per l'ecosistema npm e PyPI. Sfruttando una vulnerabilità strutturale nella fiducia "zero-touch", il worm ha compromesso oltre 170 pacchetti open source. Tra le vittime figurano namespace critici come TanStack, Mistral AI e OpenSearch. Il problema non risiede in una falla del codice sorgente, ma nel dirottamento dell'infrastruttura CI/CD stessa.

La campagna, attribuita al gruppo TeamPCP, ha dimostrato che una provenance SLSA Build Level 3 non garantisce necessariamente la benignità di un software, ma solo la legittimità del processo di build. In questo scenario, l'attaccante ha preso il controllo del "diritto di parlare a nome del codice" direttamente alla fonte. L'impatto si è esteso rapidamente alle infrastrutture corporate, portando OpenAI a confermare la compromissione di due dispositivi interni e ad avviare una massiccia rotazione dei certificati.

Punti chiave
  • Il worm Mini Shai-Hulud ha infettato oltre 170 pacchetti npm e PyPI, inclusi TanStack e OpenSearch, con 518 milioni di download totali.
  • L'infezione è scaturita da orphaned commit in GitHub Actions con trust federation OIDC, permettendo la pubblicazione di malware con firme Sigstore valide.
  • OpenAI ha confermato il breach di due dispositivi aziendali e l'esfiltrazione di credenziali limitate da repository interni a causa dell'attacco.
  • Il malware include un payload distruttivo "dead-man's switch" che cancella la home directory se il token dell'attaccante viene revocato.
"This is the first documented npm worm that produces validly attested malicious packages." - Ashish Kurmi, StepSecurity (via The Hacker News)

La provenance come arma: il paradosso di SLSA Level 3

Storicamente, la provenance Sigstore e lo standard SLSA (Supply-chain Levels for Software Artifacts) sono stati promossi come la soluzione definitiva contro gli attacchi supply chain. L'idea fondamentale era che, dimostrando la costruzione di un pacchetto da un sorgente dichiarato in un ambiente protetto, l'integrità fosse garantita. Mini Shai-Hulud ha ribaltato questa logica: se l'ambiente di build viene compromesso alla base, la provenance diventa una certificazione di legittimità per il codice malevolo.

I pacchetti compromessi dal worm, come quelli dell'ecosistema TanStack, sono stati pubblicati con attestazioni SLSA Level 3 autentiche. Molti strumenti di scansione aziendali, configurati per fidarsi delle build certificate, hanno permesso l'installazione di queste versioni trojanizzate. Questo paradosso evidenzia che la firma digitale non rappresenta più necessariamente l'integrità dell'autore umano, ma può riflettere semplicemente il successo di un'automazione dirottata da attori malevoli esperti.

L'attacco non ha richiesto il furto di segreti statici o violazioni di password dei maintainer. Ha invece dirottato il flusso di fiducia che lega GitHub a npm tramite OIDC (OpenID Connect). Una volta che il sistema ha riconosciuto il runner come "autorizzato", ha emesso un'attestazione valida per il malware. Questo ha permesso al codice malevolo di diffondersi senza attivare i tradizionali allarmi basati sulla reputazione o sulla mancanza di firme crittografiche.

Meccanica di un worm OIDC: il ruolo degli orphaned commit

Secondo le analisi tecniche di Phoenix Security e StepSecurity, l'infezione ha avuto inizio tramite un "orphaned commit" in un workflow GitHub Actions di TanStack. Un orphaned commit è un frammento di codice inviato al repository ma non collegato a branch attivi. In questo specifico incidente, il workflow era configurato per rispondere a tali commit, esponendo una superficie di attacco critica nell'infrastruttura di integrazione continua.

Il workflow compromesso utilizzava una trust federation OIDC verso il registry npm. Gli attori della minaccia hanno inviato un commit malevolo che, una volta eseguito dal runner di GitHub, ha estratto un token OIDC temporaneo dalla memoria del processo. Con questo token, il gruppo TeamPCP ha potuto impersonare il maintainer legittimo. Il risultato è stato la pubblicazione di versioni alterate dei pacchetti, dando il via alla propagazione automatica del worm.

Una volta installato, il worm ha iniziato a esfiltrare credenziali CI/CD e token di accesso dai sistemi degli sviluppatori. Questi segreti sono stati utilizzati per colpire altri namespace di alto profilo, inclusi quelli di Mistral AI, Guardrails AI e OpenSearch. Solo nell'ecosistema TanStack sono state identificate 84 versioni compromesse. Il pacchetto OpenSearch, con 1,3 milioni di download settimanali, è diventato un moltiplicatore di infezione su scala globale.

OpenAI e l'impatto sulla corporate environment

L'impatto di Mini Shai-Hulud ha raggiunto anche le infrastrutture aziendali di OpenAI. L'azienda ha confermato ufficialmente che due dispositivi di dipendenti nella propria corporate environment sono stati compromessi. OpenAI ha rilevato attività coerenti con il comportamento del malware, osservando l'esfiltrazione mirata di credenziali da un sottoinsieme limitato di repository sorgente interni a cui i due dipendenti avevano accesso legittimo.

Questo evento chiarisce che OpenAI non è stata colpita come "pacchetto compromesso" nei registry, ma come vittima corporate del worm. OpenAI ha reagito avviando la rotazione preventiva di tutti i certificati di firma per le proprie applicazioni su macOS, Windows, iOS e Android. In particolare, gli utenti macOS devono aggiornare le loro applicazioni entro il 12 giugno 2026, data oltre la quale i vecchi certificati verranno revocati da Apple.

Sebbene OpenAI abbia implementato queste misure di remediation, non è confermato se i certificati di firma siano stati effettivamente abusati per firmare software malevolo. L'azione è stata descritta come precauzionale a seguito dell'esfiltrazione delle credenziali. L'incidente dimostra quanto sia sottile la separazione tra l'ambiente di sviluppo open source e i repository aziendali privati, dove una singola dipendenza compromessa può fungere da ponte verso il cuore dell'organizzazione.

Analisi del payload: persistenza e ritorsione distruttiva

Il payload tecnico, un file JavaScript di circa 2,3 MB denominato router_init.js, include funzioni avanzate di persistenza e difesa. Il malware si insedia nelle directory .claude/ e nel file .vscode/tasks.json, garantendo l'esecuzione ogni volta che lo sviluppatore utilizza i propri strumenti di lavoro. Questa tecnica permette alla minaccia di sopravvivere anche dopo la semplice rimozione del pacchetto npm infetto tramite i comandi standard.

La caratteristica più aggressiva di Mini Shai-Hulud è il suo "dead-man's switch". Il malware esegue un polling ogni 60 secondi verso le API di GitHub per monitorare lo stato di un token npm creato dagli attaccanti. Se il token viene revocato dai difensori, il payload reagisce attivando il comando distruttivo rm -rf ~/. Questa misura punitiva è progettata per distruggere le prove forensi e scoraggiare i tentativi di bonifica del sistema.

Il token monitorato includeva la descrizione esplicita: "IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner". Questo dettaglio conferma la natura dolosa di TeamPCP, che utilizza il sabotaggio informatico come deterrente contro la risposta agli incidenti. L'esfiltrazione non mirava solo a dati statici, ma cercava attivamente nuovi token CI/CD per alimentare il ciclo di compromissione, rendendo l'eradicazione del worm un compito estremamente complesso per i team di sicurezza.

Cosa fare adesso

  • Audit dei lockfile: Ispezionare gli hash di integrità in package-lock.json o yarn.lock, identificando versioni pubblicate tra il 10 e il 12 maggio 2026, anche se dotate di provenance valida.
  • Bonifica locale: Verificare la presenza di script sospetti nelle directory ~/.claude/ e nel file .vscode/tasks.json sulle postazioni di sviluppo per eliminare la persistenza del malware.
  • Restrizione OIDC: Configurare le policy di GitHub Actions per limitare la federazione OIDC esclusivamente a branch protetti, mitigando il rischio derivante da workflow attivati da orphaned commit.
  • Aggiornamento software OpenAI: Gli utenti e le organizzazioni che utilizzano client OpenAI su macOS devono completare l'aggiornamento entro il 12 giugno 2026 per evitare blocchi dovuti alla rotazione dei certificati.
  • Sandbox CI/CD: Implementare runner effimeri e isolati, disabilitando l'esecuzione automatica di script preinstall e postinstall per prevenire l'attivazione di payload JavaScript durante il fetch delle dipendenze.

L'attacco Mini Shai-Hulud evidenzia la vulnerabilità intrinseca della fiducia automatizzata. Quando la verifica dell'identità viene delegata interamente a pipeline "zero-touch", il diritto di pubblicare codice diventa un asset vulnerabile. La sicurezza delle moderne supply chain richiede ora di guardare oltre la semplice origine certificata, analizzando l'integrità dell'intero processo di automazione che genera il software.

Perché la revoca del token npm attiva il dead-man’s switch?
Il malware è programmato per monitorare costantemente la validità del token dell'attaccante. Se la verifica fallisce, il payload interpreta l'evento come un intervento di sicurezza e avvia la cancellazione della home directory per eliminare tracce e punire l'utente.

Quali versioni di TanStack sono state colpite?
Nell'ecosistema TanStack sono state rilevate 84 versioni compromesse. Gli sviluppatori devono controllare i propri file di lock per qualsiasi pacchetto di questo namespace pubblicato durante la finestra temporale dell'attacco (10-12 maggio 2026).

I certificati di OpenAI sono stati usati per firmare malware?
Non ci sono conferme ufficiali in merito. OpenAI ha dichiarato che la rotazione dei certificati è una misura preventiva adottata dopo aver rilevato l'esfiltrazione di credenziali limitate dai propri repository interni.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews