Decine di pacchetti pubblicati sul canale ufficiale Red Hat del registry NPM sono risultati compromessi da backdoor che esfiltrano credenziali, token cloud e chiavi di firma. La scoperta, riportata da Ars Technica, riguarda librerie usate quotidianamente da pipeline CI/CD e build aziendali in produzione, e segna un punto di rottura: a essere violato non è un repository minore, ma un canale che decine di migliaia di team trattano come fonte di fiducia per default.
L’attacco mira al cuore del modello di distribuzione del software open source. Per anni la security community ha spinto il messaggio “fidati del codice firmato, fidati del canale ufficiale, fidati del maintainer riconosciuto”. Quel messaggio adesso vale meno. Quando un canale ufficiale diventa un vettore di compromissione, la catena di custodia salta a monte e tutte le verifiche a valle restano inefficaci.
La firma del distributore non basta più, serve verificare ogni anello della catena.
Il pattern non è isolato. Solo negli ultimi mesi Tom’s Hardware ha raccontato la campagna Shai-Hulud che ha contaminato oltre seicento pacchetti NPM, i pacchetti SAP ufficiali compromessi con credenziali sviluppatore a rischio e LiteLLM bucato con milioni di aziende esposte. I gruppi criminali hanno individuato in NPM un canale di propagazione più efficiente del phishing classico: infetti un pacchetto e aspetti che migliaia di sviluppatori lo installino spontaneamente.
Il canale di distribuzione è il nuovo perimetro
I pacchetti Red Hat coinvolti includono librerie di logging, utility per la gestione delle dipendenze e strumenti di build comunemente usati negli stack JavaScript enterprise. Il payload installa una backdoor persistente che cerca file .npmrc, .docker/config.json, chiavi SSH, variabili d’ambiente con credenziali AWS o GCP, e li spedisce verso server di comando e controllo. Una singola installazione contaminata può svuotare un intero ambiente di sviluppo.
Quello che cambia rispetto al passato è la natura del vettore. Non si tratta di un typosquatting (pacchetto con nome simile a uno legittimo), né di un account maintainer compromesso su un progetto marginale. Il canale ufficiale di un vendor enterprise di riferimento è stato bucato a monte, e i pacchetti firmati hanno superato i controlli automatici fino al momento dell’installazione. Il modello “trust the publisher” mostra la corda.
Senza SBOM aggiornato e audit periodico, la backdoor entra in produzione invisibile.
La risposta tecnica esiste e si chiama Software Bill of Materials. Un SBOM è la lista completa dei componenti software inclusi in un’applicazione, con versioni, hash, provenienza e licenze. Permette di sapere, davanti a una vulnerabilità nota, quali sistemi sono esposti e dove. Tom’s Hardware ha già descritto perché lo SBOM è fondamentale ma ancora poco diffuso tra le imprese, soprattutto fuori dai settori regolati. La pubblicazione di un SBOM accurato per ogni release dovrebbe essere prassi standard, e invece resta esercizio raro.
Cosa fare adesso, prima del prossimo incidente
La compromissione si combatte con misure stratificate. Le aziende che usano pacchetti Red Hat in produzione dovrebbero, in ordine: verificare le versioni installate contro il registro delle release compromesse pubblicato da Red Hat e dai security researcher; ruotare le credenziali presenti negli ambienti CI/CD dove i pacchetti sospetti sono stati eseguiti; abilitare strumenti di provenance verification come Sigstore o in-toto per validare la catena di firma a monte; rivedere la policy di pinning delle versioni nelle pipeline, perché il caricamento di “ultima minore” è un’autostrada per chi spinge una release malevola.
I framework di riferimento ci sono. Il SLSA framework di Google definisce livelli progressivi di integrità della build, dal codice sorgente al binario distribuito. L’attestation OpenSSF documenta la genealogia di un artefatto. Sigstore offre firma e verifica trasparenti basate su certificati ephemeral. Sono strumenti maturi e gratuiti, ma adottarli richiede di rivedere la pipeline di build, e quasi nessuna azienda lo fa fino a quando non ne paga il costo evitando un incidente.
La supply chain del software è il nuovo perimetro, va difesa con serietà.
Il problema strutturale è di incentivi. Chi mantiene un pacchetto open source quasi sempre non riceve compenso, ed è esposto a pressioni di ogni tipo: richieste di feature, segnalazioni di bug, occasionalmente offerte di acquisto del progetto da soggetti opachi. I vendor che integrano quel codice nei propri prodotti pagano il personale che lo modifica, ma raramente investono sull’infrastruttura di sicurezza a monte del proprio repository. Il risultato è un sistema dove il rischio è socializzato e il profitto privatizzato.
Il prezzo della velocità senza rete
Le aziende clienti hanno qualche margine di manovra che spesso non sfruttano. Nei contratti enterprise con i vendor di software open source è possibile inserire clausole esplicite su SBOM consegnato a ogni release, certificazioni SLSA livello tre o superiore, audit di sicurezza periodici della build chain. Senza queste clausole, il vendor risponde solo per il software che ha scritto, non per quello che ha integrato. E il software che ha integrato è quasi sempre la quota più grande.
Il fatto Red Hat segnala un cambiamento di scala. Quando l’attaccante riesce a infilarsi nel canale ufficiale di un vendor del calibro di Red Hat, i meccanismi standard di difesa difficilmente reggono. Le aziende che hanno costruito stack tecnologici sopra pacchetti di terzi dovrebbero smettere di considerare il publisher come garante e iniziare a trattare ogni dipendenza come potenzialmente ostile, fino a prova contraria. Il vetting si sposta dal fornitore al pezzo di codice.
Da questo punto di vista è una storia vecchia come il mondo: se si vuole spingere il software in produzione il più in fretta possibile, fidandosi delle firme automatiche, finisce che si fanno le cose male. E ogni tanto qualcuno finirà per sbatterci la faccia, pagando incidenti che bastava un audit periodico a evitare.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Davide Greco
Source link
