NotizieCryptoAttacco alla supply chain di Rust colpisce crate ampiamente utilizzati, con potenziale esposizione dell'ecosistema Solana

Attacco alla supply chain di Rust colpisce crate ampiamente utilizzati, con potenziale esposizione dell'ecosistema Solana

Autore: Hokanews·

Punti chiave

  • I ricercatori di sicurezza hanno segnalato release dannose di arrayref@0.3.10, internment@0.8.7 e append-only-vec@0.1.9 nell'ecosistema Rust.
  • I pacchetti compromessi utilizzavano una dipendenza simile a proc-macro1, il cui script di build poteva scaricare ed eseguire un payload remoto durante la compilazione.
  • Poiché Cargo esegue automaticamente gli script di build, gli sviluppatori e gli ambienti CI potrebbero essere stati esposti semplicemente compilando le versioni interessate.
  • Il team di sicurezza di Rust ha rimosso le release dannose e bloccato l'account del maintainer associato ai pacchetti.
  • I crate interessati compaiono in alcune catene di dipendenze legate a Solana, ma la segnalazione non mostra che Solana o i progetti a valle siano stati compromessi.
Attacco alla supply chain di Rust colpisce crate ampiamente utilizzati, con potenziale esposizione dell'ecosistema Solana

Un attacco coordinato alla supply chain ha colpito diversi pacchetti Rust ampiamente utilizzati, suscitando preoccupazione tra gli sviluppatori e i progetti le cui catene di dipendenze includono componenti associati all'ecosistema Solana. Ricercatori di sicurezza di SlowMist, Socket e StepSecurity hanno riferito che release dannose hanno interessato arrayref@0.3.10, internment@0.8.7 e append-only-vec@0.1.9.

Le release compromesse introducevano una dipendenza typosquatting simile al pacchetto legittimo proc-macro1, il cui script di build scaricava ed eseguiva un payload remoto durante le build di Cargo. Di conseguenza, gli sviluppatori e i sistemi di integrazione continua (CI) potevano potenzialmente essere esposti semplicemente compilando un progetto che dipendeva da una delle versioni interessate. Secondo le informazioni condivise da @WuBlockchain su X, il team di sicurezza di Rust ha rimosso le release dannose e bloccato l'account del maintainer interessato.

Pacchetti dannosi distribuiti attraverso la catena di dipendenze

L'incidente riguarda l'ecosistema dei pacchetti di Rust, in cui gli sviluppatori si affidano comunemente a crate di terze parti per fornire funzionalità all'interno di applicazioni e progetti software. In questo caso, i ricercatori hanno identificato versioni dannose di tre crate: arrayref@0.3.10, internment@0.8.7 e append-only-vec@0.1.9.

Le release dannose contenevano una dipendenza progettata per assomigliare al pacchetto legittimo proc-macro1. Questa tecnica, nota come typosquatting, cerca di far apparire un pacchetto dannoso simile a una dipendenza legittima. Si tratta di una tattica ricorrente nei registry open source, tra cui npm e PyPI di Python, dove nomi simili a quelli originali sono stati ripetutamente utilizzati per far passare codice dannoso attraverso normali aggiornamenti delle dipendenze.

L'attacco ha assunto una particolare rilevanza perché la dipendenza dannosa includeva uno script di build in grado di scaricare ed eseguire un payload remoto al momento della compilazione del pacchetto interessato. Il rischio per la sicurezza non era quindi necessariamente limitato agli utenti che installavano o eseguivano manualmente un programma palesemente sospetto: una workstation di sviluppo o un ambiente CI poteva potenzialmente essere colpito nell'ambito del normale processo di compilazione del software.

Il processo di build ha creato un potenziale rischio per la sicurezza

Cargo è il gestore di pacchetti e il sistema di build di Rust, e gli sviluppatori lo utilizzano abitualmente per recuperare le dipendenze e compilare i progetti. L'attacco segnalato ha sfruttato proprio questo flusso di lavoro. Poiché Cargo esegue automaticamente lo script di build di un crate come parte della compilazione, tale script viene eseguito con i permessi dell'utente o dell'account CI che effettua la build.

Quando una dipendenza interessata veniva compilata, lo script di build dannoso poteva scaricare ed eseguire un payload remoto. Questo creava una potenziale via d'accesso per un attaccante per eseguire codice sulla macchina di uno sviluppatore o su un host CI.

I sistemi CI sono particolarmente importanti nello sviluppo moderno del software perché compilano, testano e distribuiscono automaticamente il codice. Un ambiente di build compromesso può quindi presentare rischi che vanno oltre la singola workstation dello sviluppatore, poiché le macchine di build e le workstation degli sviluppatori contengono spesso credenziali come token API, chiavi di deploy e materiale di firma. Per questo motivo, i team di sicurezza trattano abitualmente l'esecuzione di codice in fase di build come motivo per la rotazione di tutti i segreti presenti sui sistemi interessati.

L'incidente evidenzia la più ampia sfida di sicurezza associata alle supply chain del software, dove codice dannoso può entrare in un progetto indirettamente attraverso dipendenze che gli sviluppatori potrebbero non aver scritto o revisionato personalmente.

Le catene di dipendenze legate a Solana attirano l'attenzione

Il crate arrayref è ampiamente utilizzato in tutto l'ecosistema Rust e compare in catene di dipendenze che coinvolgono componenti associati a Solana. Il software di validazione di Solana e gran parte degli strumenti che lo circondano sono scritti in Rust, motivo per cui crate di uso generale come arrayref possono comparire all'interno di alberi di dipendenze legati a Solana, anche se i crate stessi non sono specifici per la blockchain. Tuttavia, la presenza di un crate interessato all'interno di una catena di dipendenze non significa che i progetti a valle legati a Solana siano stati compromessi.

Questa distinzione è importante perché il software open source si affida frequentemente a più livelli di dipendenze. Un pacchetto vulnerabile o compromesso può comparire in qualche punto dell'albero delle dipendenze di un progetto senza che ciò comporti necessariamente la compromissione dell'applicazione o della rete finale.

I ricercatori di sicurezza distinguono quindi tra l'esposizione a una dipendenza dannosa e le prove che il codice dannoso sia stato effettivamente eseguito all'interno di un particolare progetto o ambiente a valle. L'incidente segnalato accerta che le release interessate contenevano codice dannoso, ma non accerta che ogni progetto che utilizzava dipendenze correlate sia stato compromesso.

Il team di sicurezza di Rust rimuove le release dannose

Il team di sicurezza di Rust ha risposto rimuovendo le release dannose e bloccando l'account del maintainer associato ai pacchetti. Secondo le informazioni riportate, la macchina del maintainer o le sue credenziali di pubblicazione sono probabilmente state compromesse.

Un account di pubblicazione compromesso può rappresentare un rischio significativo negli ecosistemi open source perché gli attaccanti potrebbero distribuire software dannoso sotto l'identità di un maintainer legittimo. La rimozione delle versioni interessate limita l'ulteriore distribuzione attraverso l'ecosistema dei pacchetti, mentre il blocco dell'account impedisce la pubblicazione di nuove release tramite le credenziali compromesse. Gli avvisi di sicurezza per i crate Rust compromessi vengono tracciati attraverso il database di avvisi RustSec, gestito dalla community, uno dei canali che gli sviluppatori possono monitorare insieme al registry crates.io.

L'incidente dimostra inoltre l'importanza di monitorare le dipendenze e di esaminare aggiornamenti di pacchetti inattesi, in particolare quando i progetti si affidano ad alberi di dipendenze ampi e complessi.

Implicazioni più ampie per gli sviluppatori Rust

Gli attacchi alla supply chain sono diventati una preoccupazione significativa per la sicurezza in tutto lo sviluppo del software perché prendono di mira l'infrastruttura e le dipendenze utilizzate per costruire le applicazioni, anziché attaccare direttamente l'applicazione finale. In questo caso, il codice dannoso era incorporato nelle release dei pacchetti e veniva attivato durante il processo di build. Questo schema ha precedenti ben documentati, tra cui la backdoor in XZ Utils divulgata a marzo 2024, in cui un attaccante ha sfruttato la posizione di maintainer in una libreria open source di compressione fondamentale, e la compromissione del pacchetto @solana/web3.js su npm a dicembre 2024, che ha interessato una libreria JavaScript ampiamente utilizzata dagli sviluppatori Solana. Entrambi gli episodi, come questo, mostrano come la fiducia in un account di maintainer o nell'identità di un pacchetto possa trasformarsi in una superficie di attacco.

Gli sviluppatori che utilizzano progetti Rust possono ridurre l'esposizione a incidenti simili monitorando le versioni delle dipendenze, esaminando le modifiche inattese e utilizzando strumenti di sicurezza in grado di identificare pacchetti sospetti o comportamenti anomali delle dipendenze. Per questo specifico incidente, ciò si traduce nel cercare le tre versioni interessate nei lockfile come Cargo.lock, nel verificare la presenza di attività di rete in uscita inattese nei log CI e di build e nel ruotare le credenziali su qualsiasi macchina su cui le release interessate sono state compilate. Anche le organizzazioni che si affidano ad ambienti CI automatizzati devono considerare la sicurezza della propria infrastruttura di build, perché le dipendenze dannose possono potenzialmente eseguire codice prima che un'applicazione venga distribuita.

La risposta dell'ecosistema Rust dimostra l'importanza di un monitoraggio della sicurezza coordinato e della rapida rimozione dei pacchetti compromessi. Sebbene i crate interessati abbiano legami con catene di dipendenze che coinvolgono componenti legati a Solana, le informazioni disponibili non accertano che Solana stessa o progetti specifici a valle siano stati compromessi. L'incidente serve invece da monito sul fatto che le dipendenze open source ampiamente utilizzate possono trasformarsi in un potenziale vettore di attacco quando le credenziali di pubblicazione o gli ambienti dei maintainer vengono compromessi.

Fonte: Hokanews