Diverse librerie pubbliche e popolari, abbandonate ma ancora utilizzate in applicazioni Java e Android, sono risultate vulnerabili a un nuovo metodo di attacco alla catena di approvvigionamento (o supply-chain) software chiamato MavenGate.
Cosa sappiamo del metodo MavenGate
“È possibile dirottare l’accesso ai progetti attraverso l’acquisto di nomi di dominio e poiché la maggior parte delle configurazioni di compilazione predefinite è vulnerabile, sarebbe difficile o addirittura impossibile sapere se un attacco è in corso“, ha affermato Oversecured in un’analisi pubblicata la scorsa settimana che riguarda il metodo MavenGate.
Lo sfruttamento con successo di queste lacune potrebbe consentire a vari malintenzionati di dirottare gli artefatti nelle dipendenze e iniettare codice maligno nell’applicazione e, cosa peggiore, compromettere persino il processo di compilazione attraverso un plugin malevolo.
La società di sicurezza mobile ha aggiunto che tutte le tecnologie basate su Maven, inclusa Gradle, sono vulnerabili all’attacco, e che ha inviato segnalazioni a oltre 200 aziende, tra cui Google, Facebook, Signal, Amazon e tante altre ancora.
Apache Maven (da qui il nome MavenGate) è principalmente utilizzato per la costruzione e la gestione di progetti basati su Java, consentendo agli utenti di scaricare e gestire le dipendenze (che sono identificate in modo univoco dai loro groupIds), creare documentazione e gestire le release.
Mentre i repository che ospitano tali dipendenze possono essere privati o pubblici, un attaccante che usa il metodo MavenGate potrebbe mirare a quest’ultimo per condurre attacchi per sabotare la catena di approvvigionamento (supply chain) sfruttando librerie abbandonate aggiunte a repository noti.
In particolare, ciò comporta l’acquisto del dominio inverso scaduto controllato dal proprietario della dipendenza e l’ottenimento dell’accesso al groupId.
“Un attaccante può ottenere accesso a un groupId vulnerabile affermando i propri diritti tramite un record DNS TXT in un repository in cui non esiste un account che gestisce il groupId vulnerabile“, ha dichiarato l’azienda, aggiungendo: “Se un groupId è già registrato nel repository, un attaccante può tentare di ottenere accesso a quel groupId contattando il team di supporto del repository”.
Per testare lo scenario di attacco, Oversecured ha caricato la propria libreria di test Android (groupId: “com.oversecured”), che visualizza il messaggio toast “Hello World!”, su Maven Central (versione 1.0), caricando anche due versioni su JitPack, dove la versione 1.0 è una replica della stessa libreria pubblicata su Maven Central.
Ma la versione 1.1 è una copia “non attendibile” modificata che ha lo stesso groupId, ma che punta a un repository GitHub sotto il loro controllo e viene reclamata aggiungendo un record DNS TXT per fare riferimento al nome utente GitHub al fine di stabilire la prova di proprietà.
L’attacco funziona quindi aggiungendo sia Maven Central che JitPack all’elenco dei repository di dipendenze nello script di compilazione Gradle: è pertanto importante notare in questa fase che l’ordine di dichiarazione determina come Gradle verificherà le dipendenze durante l’esecuzione.
“Quando abbiamo spostato il repository JitPack sopra mavenCentral, la versione 1.0 è stata scaricata da JitPack“, hanno detto i ricercatori, per poi aggiungere che “cambiare la versione della libreria in 1.1 ha comportato l’utilizzo della versione di JitPack indipendentemente dalla posizione di JitPack nell’elenco dei repository“.
Di conseguenza, un avversario che cerca di corrompere la catena di approvvigionamento dei programmi tramite il metodo MavenGate può prendere di mira sia le versioni esistenti di una libreria pubblicando una versione superiore o alle nuove versioni spingendo una versione inferiore rispetto a quella del legittimo controparte.
Questo è un altro tipo di “attacco di confusione” delle dipendenze in cui un attaccante pubblica un pacchetto fasullo in un repository di pacchetti pubblico con lo stesso nome di un pacchetto all’interno del repository privato previsto, sostanzialmente un metodo molto simile al phishing o al ransomware con file o link fasulli.
“La maggior parte delle applicazioni non verifica la firma digitale delle dipendenze, e molte librerie non la pubblicano nemmeno“, hanno aggiunto i ricercatori. “Se l’attaccante vuole rimanere indetetctato il più a lungo possibile, ha senso rilasciare una nuova versione della libreria con il codice maligno incorporato e attendere che lo sviluppatore lo aggiorni“.
Dei 33.938 domini totali analizzati, 6.170 (18,18%) di essi sono risultati vulnerabili a MavenGate, consentendo ai criminali informatici di dirottare le dipendenze e iniettare il proprio codice.
Sonatype, proprietaria di Maven Central, ha dichiarato che la strategia di attacco delineata “non è fattibile a causa dell’automazione in atto“, ma ha poi reso noto che ha “disabilitato tutti gli account associati ai domini scaduti e ai progetti GitHub” come misura di sicurezza.
Ha inoltre affermato di aver affrontato una “regressione nella convalida della chiave pubblica” che rendeva possibile caricare artefatti nel repository con una chiave non condivisa pubblicamente ed ha anche annunciato piani per collaborare con SigStore per firmare digitalmente i componenti.
“Il front-end developer è responsabile della sicurezza non solo delle dipendenze dirette, ma anche delle dipendenze trasitive“, ha detto Oversecured, aggiungendo “gli sviluppatori delle librerie dovrebbero essere responsabili delle dipendenze che dichiarano e dovrebbero anche scrivere gli hash delle chiavi pubbliche per le loro dipendenze, mentre il front-end developer dovrebbe essere responsabile solo delle sue dipendenze dirette“.
