Un pacchetto open source scaricato più di un milione di volte al mese è stato compromesso dopo che un attaccante ha sfruttato una vulnerabilità nel flusso di lavoro degli sviluppatori, ottenendo accesso alle chiavi di firma e ad altre informazioni sensibili. La notizia riguarda element-data, uno strumento a riga di comando utilizzato per monitorare prestazioni e anomalie nei sistemi di machine learning, e rappresenta un caso emblematico di quanto i cosiddetti attacchi alla supply chain stiano diventando un problema serio nel mondo del software.
Venerdì scorso, attaccanti ancora non identificati hanno sfruttato la falla per pubblicare una nuova versione di element-data, la 0.23.3, sia sull’indice dei pacchetti Python (PyPI) sia sull’account Docker degli sviluppatori. Una volta eseguito, il pacchetto malevolo andava a caccia di dati sensibili nel sistema: profili utente, credenziali di accesso ai data warehouse, chiavi di provider cloud, token API e chiavi SSH. La versione infetta è rimasta disponibile per circa 12 ore prima di essere rimossa, il sabato successivo. Gli sviluppatori hanno precisato che Elementary Cloud, il pacchetto Elementary dbt e tutte le altre versioni della CLI non sono state coinvolte.
Come è avvenuto l’attacco e cosa fare adesso
Il meccanismo usato dagli attaccanti è tanto ingegnoso quanto preoccupante. L’accesso all’account degli sviluppatori è stato ottenuto sfruttando una vulnerabilità in una GitHub Action da loro creata. Pubblicando codice malevolo all’interno di una pull request, gli attaccanti sono riusciti a eseguire uno script bash nell’ambiente dell’account sviluppatore, recuperando token e chiavi di firma. Con queste informazioni in mano, hanno potuto pubblicare una versione di element-data praticamente indistinguibile da quella legittima.
Gli sviluppatori sono stati avvisati della compromissione tramite una segnalazione esterna. Nel giro di tre ore il pacchetto è stato rimosso. Tutte le credenziali a cui il codice malevolo aveva avuto accesso sono state ruotate, la vulnerabilità è stata corretta e tutte le altre GitHub Action del progetto sono state sottoposte ad audit per verificare che non contenessero lo stesso difetto.
Chi ha installato la versione 0.23.3 o ha eseguito l’immagine Docker compromessa dovrebbe considerare esposti tutti i credenziali accessibili dall’ambiente in cui il pacchetto è stato utilizzato. Le azioni consigliate dagli sviluppatori sono chiare: verificare la versione installata, disinstallarla e passare alla 0.23.4, eliminare i file di cache e controllare la presenza del file marker del malware (su macOS e Linux si trova in /tmp/.trinny-security-update, su Windows in %TEMP%.trinny-security-update). Se quel file è presente, il payload è stato eseguito sulla macchina.
Un problema strutturale per l’open source
Particolarmente a rischio risultano i runner CI/CD, che tipicamente hanno accesso a un ampio set di segreti montati durante l’esecuzione. Per questo motivo è fondamentale ruotare tutte le credenziali potenzialmente esposte: profili dbt, credenziali di warehouse, chiavi cloud, token API, chiavi SSH e il contenuto di qualsiasi file .env presente nell’ambiente compromesso. Gli sviluppatori invitano anche a contattare il proprio team di sicurezza per cercare eventuali utilizzi non autorizzati delle credenziali sottratte.
Nell’ultimo decennio, gli attacchi alla supply chain sui repository open source sono diventati sempre più frequenti, generando in alcuni casi una catena di compromissioni che si propaga dagli utenti diretti fino agli ambienti da loro gestiti. HD Moore, hacker con oltre quarant’anni di esperienza e fondatore e CEO di runZero, ha sottolineato come i workflow personalizzati nei repository, come le GitHub Action, siano notoriamente esposti a questo tipo di vulnerabilità. “È davvero difficile non creare accidentalmente workflow pericolosi che possano essere sfruttati tramite una pull request di un attaccante,” ha dichiarato, definendo la questione un problema strutturale per i progetti open source con repository pubblici.