Attacco alla supply chain npm: cosa è successo e come proteggersi

Attacco alla supply chain npm: cosa è successo e come proteggersi

Attacco alla supply chain npm: cosa è successo e come proteggersi

Introduzione per gli utenti comuni

Se sei uno sviluppatore o lavori nel settore tecnologico, potresti aver sentito parlare di un attacco recente ai pacchetti npm. La buona notizia è che OpenAI ha confermato che nessun dato utente è stato compromesso e i prodotti rimangono al sicuro. Tuttavia, questo incidente rappresenta una minaccia seria per l’intera comunità degli sviluppatori.

Cosa è successo in breve: Un gruppo di attaccanti ha utilizzato una tecnica sofisticata per inserire codice dannoso in 84 pacchetti npm diversi, scaricati milioni di volte ogni settimana. Invece di rubare le credenziali di accesso (come farebbe un hacker tradizionale), gli attaccanti hanno compromesso il sistema di compilazione automatico di TanStack, sfruttando vulnerabilità nei GitHub Actions.

L’azione immediata: Se sei uno sviluppatore, verifica che le tue dipendenze npm siano aggiornate e monitora gli avvisi di sicurezza dai tuoi fornitori. Gli utenti di ChatGPT desktop dovrebbero assicurarsi di avere installato gli ultimi aggiornamenti.

Cosa è realmente accaduto

L’11 maggio, tra le 19:20 e le 19:26 UTC, qualcosa di straordinario è accaduto nell’ecosistema npm. Un attacco coordinato ha pubblicato 84 artefatti dannosi in 42 pacchetti diversi, incluso @tanstack/react-router, che viene scaricato oltre 12,7 milioni di volte ogni settimana.

Ciò che rende questo attacco particolarmente preoccupante è il metodo utilizzato. Gli attaccanti non hanno rubato le credenziali di accesso npm di nessuno. Invece, hanno compromesso la pipeline di rilascio legittima di TanStack, utilizzando l’identità OIDC affidabile del servizio. Come è possibile? Un fork controllato dagli attaccanti ha dirottato il runner di GitHub Actions durante il flusso di lavoro, estraendo il token OIDC direttamente dalla memoria del processo.

L’impatto su OpenAI e oltre

OpenAI ha confermato che due computer aziendali nel suo ambiente aziendale sono stati colpiti. Materiale di credenziali limitato è stato esfiltrato dai repository di codice interno, ma le password e le chiavi API non sono state compromesse. Nessun dato utente è stato accessibile, nessun prodotto è stato compromesso e nessun software è stato alterato.

Tuttavia, l’impatto più ampio è significativamente più grave. La campagna, denominata Mini Shai-Hulud, è una versione autoreplicante di un worm che ha colpito il registro npm per la prima volta nel settembre 2025. Finora, ha compromesso più di 170 pacchetti su npm e PyPI, inclusi rilasci di Mistral AI, UiPath, OpenSearch e Guardrails AI.

Il numero complessivo di download dei pacchetti interessati supera i 518 milioni, secondo i dati di OX Security. Microsoft Security Research sta tracciando questa come la stessa campagna che è stata attiva a novembre e dicembre 2025 sotto il nome di Shai-Hulud 2.0.

Come gli attaccanti hanno aggirato la sicurezza

Questo attacco è stato descritto accuratamente dal manutentore di TanStack, Tanner Linsley, come il primo worm npm documentato nella storia che viene fornito con un certificato di autenticità valido e firmato.

La sofisticazione risiede nel modo in cui sono state sfruttate tre vulnerabilità di GitHub Actions:

  1. Il trigger pull_request_target: Questo permette ai flussi di lavoro di accedere a credenziali sensibili quando viene attivato da richieste di pull esterne.

  2. L’avvelenamento della cache: Gli attaccanti hanno compromesso i sistemi di cache utilizzati durante la compilazione, inserendo codice dannoso che viene eseguito come parte del processo di build legittimo.

  3. L’estrazione del token OIDC dalla memoria: Il componente più ingegnoso dell’attacco è stato l’estrazione diretta del token OIDC dalla memoria del processo del runner, bypassando i controlli di sicurezza tradizionali.

Questo ha permesso agli attaccanti di bypassare ogni livello di sicurezza nella pubblicazione npm contemporaneamente.

Il ruolo della pubblicazione affidabile

La “pubblicazione affidabile” è un sistema progettato per sostituire i token npm rubabili con token OIDC di breve durata. Tuttavia, questo attacco ha dimostrato che il sistema assume che il runner sia affidabile. Gli attaccanti hanno semplicemente reso il runner non affidabile.

Questa è una lezione importante per l’intera industria: nessun sistema di sicurezza è impermeabile se un attaccante può compromettere i componenti fondamentali dell’infrastruttura.

Cosa significa per gli sviluppatori

Per OpenAI, il takeaway è relativamente limitato: due laptop, materiale di credenziali, un aggiornamento forzato dell’app, nessun dato del cliente, nessuna compromissione del prodotto.

Per tutti gli altri che pubblicano o consumano pacchetti npm, il takeaway è molto più lungo. La campagna TeamPCP attribuita a Mini Shai-Hulud è stata collegata anche alla compromissione dello scanner Trivy di Aqua Security a marzo e del pacchetto npm della CLI di Bitwarden ad aprile. Non c’è indicazione che abbia esaurito i suoi obiettivi.

Misure di mitigazione in corso

OpenAI ha adottato diverse misure per affrontare l’incidente:

  • I computer interessati sono stati isolati
  • La rotazione delle credenziali è in corso
  • I flussi di lavoro di distribuzione del codice sono stati temporaneamente limitati
  • I certificati di firma del codice vengono ruotati
  • Gli utenti macOS dell’app desktop ChatGPT stanno ricevendo aggiornamenti forzati dell’applicazione

Technical Deep Dive

Per i professionisti della sicurezza e gli ingegneri DevOps, questo attacco merita un’analisi più approfondita.

Analisi delle vulnerabilità di GitHub Actions

Il vettore di attacco primario sfruttava il trigger pull_request_target in GitHub Actions. Questo trigger è noto per essere pericoloso perché esegue il codice del flusso di lavoro dal repository di base con accesso ai segreti, anche quando il codice del flusso di lavoro stesso proviene da una richiesta di pull non verificata.

Gli attaccanti hanno creato una richiesta di pull che, quando elaborata dal flusso di lavoro, ha eseguito codice dannoso con accesso completo ai token OIDC del runner.

Estrazione del token OIDC

Il componente più sofisticato dell’attacco è stato l’estrazione del token OIDC dalla memoria del processo. I token OIDC sono progettati per essere di breve durata e specifici del contesto, ma una volta in memoria del processo, possono essere letti dal codice in esecuzione con lo stesso livello di privilegio.

Gli attaccanti hanno utilizzato tecniche di memoria forensics per localizzare e estrarre il token, che è stato quindi utilizzato per autenticarsi presso npm e pubblicare pacchetti dannosi.

Implicazioni per la fiducia nella supply chain

Questo attacco evidenzia un problema fondamentale nella sicurezza della supply chain del software: la fiducia è transitiva. Se un componente della pipeline di compilazione viene compromesso, l’intera catena di fiducia crolla.

I sistemi di firma del codice e i certificati di autenticità, sebbene utili, non sono sufficienti se l’entità che firma il codice è stata compromessa. In questo caso, i pacchetti sono stati firmati con certificati validi perché erano stati pubblicati attraverso la pipeline legittima di TanStack.

Raccomandazioni per i team DevOps

  1. Implementare il principio del minimo privilegio: I runner di GitHub Actions dovrebbero avere accesso solo ai segreti assolutamente necessari.

  2. Monitorare l’accesso ai token OIDC: Implementare logging e monitoraggio per tracciare l’estrazione e l’utilizzo dei token OIDC.

  3. Utilizzare runner auto-hosted con isolamento: Considerare l’utilizzo di runner auto-hosted in ambienti isolati con capacità di audit avanzate.

  4. Implementare la verifica della firma del codice: Anche se non impermeabile, la verifica della firma del codice aggiunge un ulteriore livello di controllo.

  5. Auditing della supply chain: Implementare strumenti di auditing della supply chain che possono tracciare le dipendenze e rilevare anomalie nel comportamento dei pacchetti.

Questo incidente serve come promemoria critico che la sicurezza della supply chain richiede vigilanza costante e un approccio a difesa in profondità.

Fonte: https://thenextweb.com/news/openai-tanstack-npm-supply-chain-mini-shai-hulud

Torna in alto