Firmato, spedito e avvelenato: la pipeline dei pacchetti trasformata in una trappola per credenziali
Una nuova ondata di Shai-Hulud mostra come un flusso di rilascio compromesso possa far apparire affidabili pacchetti npm e PyPI malevoli, mentre raccoglie in silenzio i segreti degli sviluppatori.
Le moderne supply chain del software sono costruite per ridurre la fiducia nelle persone e aumentarla nell’automazione. Funziona finché non è la stessa automazione a essere alterata. In questa campagna, pacchetti malevoli sono stati pubblicati attraverso percorsi di rilascio dall’aspetto legittimo, portando segnali di provenienza validi ma consegnando comunque payload capaci di sottrarre credenziali, mirati a sviluppatori e ambienti CI/CD.
Fatti rapidi
- Pacchetti malevoli sono stati immessi negli ecosistemi npm e PyPI sotto l’etichetta Shai-Hulud.
- Gli attaccanti avrebbero abusato del publishing basato su OIDC e dell’accesso CI/CD per distribuire versioni con provenienza valida.
- Il payload cercava segreti degli sviluppatori, inclusi token di pubblicazione, credenziali cloud e materiale CI/CD.
- La persistenza è stata descritta negli strumenti per sviluppatori, inclusi i hook di Claude Code e le attività di esecuzione automatica di VS Code.
- Session P2P è stato usato per l’esfiltrazione, rendendo il traffico di rete più difficile da distinguere dalla messaggistica cifrata.
Come si è rotto il trust
Il dettaglio più importante non è solo che i pacchetti fossero malevoli. È che potevano comunque apparire legittimi dal punto di vista procedurale. I flussi di trusted publishing si basano su token di identità a breve durata e attestazioni di build, molto più sicuri delle password statiche. Ma se un attaccante raggiunge il workflow, ruba il token o abusa di un percorso privilegiato di GitHub Actions, il pacchetto risultante può ereditare gli stessi segnali di fiducia di una release pulita.
Ecco perché questo caso è importante per i difensori: la provenienza è una registrazione di come qualcosa è stato costruito, non una garanzia che gli input della build fossero sicuri. In pratica, un workflow avvelenato può produrre un pacchetto che sembra firmato, tracciabile e conforme alle policy, pur contenendo codice ostile. Per gli sviluppatori, questo significa che l’esecuzione al momento dell’installazione resta un rischio reale, soprattutto quando i package manager eseguono codice come parte della normale installazione.
La persistenza è altrettanto importante. Se il codice malevolo si inserisce in hook dell’editor o in task di avvio automatico, rimuovere il pacchetto potrebbe non bastare. La bonifica allora passa dalla semplice rimozione delle dipendenze all’analisi forense delle workstation, alla rotazione dei token e alla revisione dell’automazione degli sviluppatori. Una lettura prudente dell’evento è che la compromissione possa persistere in luoghi che i team spesso dimenticano di ispezionare.
La lezione più ampia è semplice: la sicurezza della supply chain non può fermarsi a firme e attestazioni. I team hanno bisogno anche di hardening dei workflow, condizioni OIDC ristrette, monitoraggio all’installazione e dell’abitudine di considerare i laptop degli sviluppatori e i runner CI come obiettivi di alto valore. Le informazioni disponibili supportano un’analisi del rischio, non l’affermazione completa che ogni sistema a valle sia stato compromesso.
Conclusione
Ecco come appare il crimine moderno contro i pacchetti: non una falsa release grossolana, ma un percorso di rilascio trasformato in arma. La prossima linea di difesa non è semplicemente “fidati della firma”, ma “fidati della firma, verifica il workflow e considera che la fase di installazione possa ancora mordere”.
TECHCROOK
Chiave di sicurezza hardware: Per sviluppatori e amministratori, una chiave di sicurezza hardware aggiunge una protezione a due fattori resistente al phishing per GitHub, console cloud e registry dei pacchetti. È un piccolo dispositivo USB/NFC adatto agli account di alto valore, soprattutto quando i workflow di rilascio e i token CI/CD richiedono un’attenzione extra.
WIKICROOK
- OIDC: Un protocollo di identità che consente ai sistemi CI di ottenere credenziali di pubblicazione a breve durata senza password statiche.
- Provenienza: Metadati che descrivono come è stato costruito un artefatto software e quali input sono stati usati.
- SLSA: Un framework per la supply chain del software che rafforza l’integrità delle build e la fiducia negli artefatti.
- Script di ciclo di vita: comandi npm che possono essere eseguiti automaticamente durante l’installazione di un pacchetto e diventare un percorso di esecuzione.
- Persistenza: Una tecnica malware per sopravvivere alla rimozione incorporandosi in strumenti, impostazioni o logiche di avvio.
