Attacco supply chain Ruby e Go: scopri il rischio sleeper

Un nuovo attacco supply chain colpisce Ruby e Go sfruttando pacchetti sleeper e wrapper falsi. Scopri come proteggere le pipeline CI/CD e i segreti aziendali.

Contenuto

Attacco supply chain Ruby e Go: scopri il rischio sleeper
Attacco supply chain Ruby e Go: scopri il rischio sleeper

Le pipeline di integrazione continua si trasformano in vettori di compromissione silenziosa. Il 1 maggio 2026, una nuova campagna di attacco alla supply chain software ha sfruttato pacchetti sleeper e wrapper falsi nei moduli Go per rubare credenziali e manomettere GitHub Actions. L'attività, attribuita all'account GitHub 'BufferZoneCorp', ha colpito gli ecosistemi Ruby e Go, compromettendo i build environment attraverso tecniche elusive progettate per superare i controlli CI/CD.

L'evoluzione dell'attacco supply chain tra Ruby gems e Go modules

Un attacco alla supply chain prende di mira i fornitori, i partner o le dipendenze software di un'azienda per infiltrarsi o interrompere i sistemi aziendali. Gli aggressori avvelenano i flussi di lavoro legittimi, come repository di codice o gestori di pacchetti, con conseguente distribuzione occulta di malware. In questo contesto si inserisce la campagna rilevata il 1 maggio 2026, che ha dimostrato un'evoluzione significativa nelle metodologie di compromissione rispetto alle tecniche di massa osservate in precedenza. Gia nel 2025, campagne di ampia portata come Shai-Hulud 2.0 su npm e PyPI avevano sfruttato un worm autoreplicante colpendo decine di milioni di download, mentre altre iniziative avevano inondato i registri con decine di migliaia di pacchetti inutili. L'attacco odierno rappresenta un cambiamento significativo verso la sofisticazione mirata: l'uso di moduli sleeper e wrapper falsi evade il rumore di massa, preferendo l'invisibilità all'interno delle specifiche pipeline CI/CD.

L'account GitHub 'BufferZoneCorp' ha pubblicato repository associati a Ruby gems e Go modules malevoli. Come evidenziato da Kirill Boychenko, ricercatore di sicurezza di Socket, "The account is part of a software supply chain campaign targeting developers, CI runners, and build environments across two ecosystems". La campagna ha riguardato complessivamente 9 Go modules, di cui 2 definiti "sleeper module", capaci di rimanere inattivi fino all'innesco in ambienti specifici. È probabile che l'uso di moduli sleeper rappresenti uno scudo per eludere le analisi statiche automatizzate nei registri dei pacchetti, attivandosi solo quando il contesto di esecuzione risulta proficuo.

Furto di credenziali e iniezione di codice nelle Ruby gems

Il vettore di attacco tramite Ruby ha sfruttato pacchetti che imitavano librerie fidate, utilizzando prefissi come 'knot-' (ad esempio knot-activesupport-logger) e il profilo RubyGems 'knot-theory'. Questa tecnica di typosquatting permette di ingannare gli sviluppatori durante la ricerca di dipendenze legittime. Una volta installati, questi pacchetti automatizzano il furto di credenziali sfruttando il processo di build delle estensioni native. In Ruby, le estensioni native richiedono l'esecuzione di comandi di compilazione durante l'installazione; questa dinamica legittima viene dirottata per eseguire codice malevolo con i privilegi dell'utente o del sistema CI.

Il payload ruba variabili d'ambiente, chiavi SSH, segreti AWS, file .npmrc, .netrc, la configurazione della GitHub CLI e le credenziali RubyGems. I dati rubati vengono esfiltrati in formato JSON a un endpoint Webhook.site controllato dagli attaccanti, sopprimendo gli errori per evitare sospetti durante il processo di build. Riguardo allo stato di rimozione di questi pacchetti, le fonti forniscono informazioni contrastanti: mentre una fonte indica che i pacchetti RubyGems sono stati rimossi al momento della pubblicazione, un'altra afferma che le Ruby gems rimanevano attive durante le indagini iniziali. Questo suggerisce che la finestra di esposizione potrebbe essere stata più ampia del previsto prima del blocco completo da parte dei maintainer del registro.

Moduli sleeper e wrapper falsi eludono i controlli CI/CD

L'attacco verso l'ecosistema Go ha mostrato un livello di sofisticazione ancora superiore, puntando direttamente alla compromissione delle pipeline di integrazione e distribuzione continua. I Go modules eseguono payload avanzati tramite la funzione init(), che viene richiamata automaticamente quando il modulo viene importato. Il codice malevolo rileva la presenza delle variabili GITHUB_ENV e GITHUB_PATH, confermando di trovarsi all'interno di un runner di GitHub Actions. In questo ambiente, il modulo imposta HTTP_PROXY e HTTPS_PROXY, permettendo potenzialmente di intercettare il traffico di rete in uscita dal sistema di build.

Inoltre, l'attacco scrive un finto eseguibile go in una cache directory e lo aggiunge al percorso del workflow alterando GITHUB_PATH. Questo wrapper falso intercetta le esecuzioni go successive. Come spiegato da Kirill Boychenko, "That wrapper can then intercept or influence later go executions while still passing control to the legitimate binary to avoid breaking the job". Passando il controllo al binario legittimo, il malware evita che il job CI/CD fallisca, garantendo che l'intervento rimanga invisibile agli sviluppatori. Alcuni Go modules disabilitano inoltre la verifica del checksum o rimuovono voci di dipendenza dai file di progetto; è probabile che questa mossa serva a intercettare e dirottare pacchetti legittimi in fasi successive della risoluzione delle dipendenze.

Persistenza SSH e impatto sui build environment

Oltre al furto di dati e all'intercettazione del traffico, la campagna mirava a garantire un accesso persistente ai server compromessi. Se l'esfiltrazione iniziale delle credenziali ha successo, il payload aggiunge una chiave pubblica SSH hardcoded al file authorized_keys dell'utente. Questa azione concede agli attaccanti un accesso remoto persistente al build environment, indipendentemente dalla vulnerabilità iniziale della supply chain. I build environment e i CI runner sono target di alto valore perché detengono segreti di produzione, chiavi di firma e accesso ai sistemi di deployment. Una volta ottenuto l'accesso SSH, gli attaccanti possono muoversi lateralmente, iniettare codice direttamente nei rilasci di produzione o esfiltrare ulteriori dati sensibili.

Poiché le fonti non indicano la disponibilità di patch specifiche per questa campagna, la segmentazione di rete, la limitazione dell'esposizione Internet dei dispositivi e l'isolamento dei runner CI/CD rappresentano le misure difensive prioritarie per mitigare simili compromissioni. Verificare sempre l'integrità del codice utilizzando hash crittografici per confermare l'autenticità dei pacchetti software, senza fare affidamento esclusivamente sui tag, e adottare una gestione sicura delle credenziali, evitando di memorizzare segreti in chiaro nel codice o nei log, risulta essenziale per ridurre la superficie di attacco. L'adozione di sistemi di monitoraggio costante per rilevare tempestivamente comportamenti anomali o tentativi di accesso non autorizzato completa il quadro delle contromisure necessarie.

Domande frequenti

Come agiscono i pacchetti sleeper negli attacchi alla supply chain?
I pacchetti sleeper rimangono inattivi o presentano un comportamento apparentemente innocuo fino a quando non si trovano in un ambiente specifico, come una pipeline CI/CD. Questo permette loro di superare i controlli di sicurezza automatizzati e attivare il payload malevolo solo quando le condizioni, come le variabili d'ambiente di un runner, sono verificate.
In che modo le Ruby gems rubano le credenziali durante l'installazione?
Le Ruby gems malevole sfruttano il processo di build delle estensioni native, che esegue automaticamente script durante l'installazione. Questo meccanismo viene usato per copiare variabili d'ambiente, chiavi SSH e segreti AWS, inviandoli a un endpoint remoto e sopprimendo gli errori per non destare sospetti.
Perché il wrapper falso nei moduli Go è pericoloso per le pipeline CI/CD?
Il wrapper falso sostituisce l'eseguibile legittimo intercettando i comandi go successivi, ma passa il controllo al binario originale per non interrompere il job. Questo garantisce che il processo di build non fallisca, consentendo al malware di operare in background senza che gli sviluppatori notino anomalie nella pipeline.

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

Fonti

Link utili

Apri l'articolo su DeafNews