Attacco in rapida successione: campagne malevole su GitHub contro 61 repository pubblici
Negli ultimi giorni, i ricercatori di Radware hanno segnalato almeno 83 attacchi coordinati che hanno colpito 61 repository pubblici su GitHub, inclusi progetti open source di notevole importanza come Google LangExtract, Trivy, Brave browser e MLflow. L’obiettivo di questa campagna sembrerebbe essere l’esecuzione di comandi in ambienti CI/CD (Continuous Integration/Continuous Deployment) per rubare credenziali e token di accesso.
Gli attacchi sono avvenuti rapidamente, con 77 elementi malevoli pubblicati in un arco di tempo di soli 43 minuti il 1° settembre e i restanti sei in pochi minuti. Gabi Nakibly, vicepresidente e ricercatore di Radware, ha dichiarato che l’intento finale apparente era quello di portare a termine un attacco alla catena di approvvigionamento, permettendo all’attaccante di ottenere accesso e autorizzazioni per modificare i contenuti del repository.
Una catena di attacco innovativa
I ricercatori hanno scoperto questa campagna mentre indagavano sulla possibilità di iniezioni di comandi su GitHub. Hanno messo in evidenza che la catena di attacco si distingue per la sua novità e per la sua stealthiness. L’attaccante pubblica un problema, una pull request o un commento contenente comandi malevoli nascosti in commenti HTML, che non sono visibili nella pagina renderizzata. Inoltre, un evento di GitHub può automaticamente attivare un workflow se il repository è impostato per rispondere a tale evento.
“Il workflow viene attivato automaticamente nel giro di un secondo, e se è vulnerabile, l’attacco viene eseguito con successo,” ha aggiunto Nakibly. Questo workflow integra contenuti controllati dall’attaccante direttamente nel codice sorgente di shell, il quale esegue il comando malevolo, tentando di esfiltrare variabili ambientali verso un server controllato dall’attaccante.
Nonostante i ricercatori abbiano esaminato i log delle esecuzioni, hanno trovato solo due casi in cui il comando malevolo è stato eseguito nell’ambiente di automazione, ed è quindi difficile confermare se l’attaccante sia riuscito a ottenere permessi di scrittura nel repository o a compromettere il software downstream. Tuttavia, i ricercatori continuano le indagini per scoprire eventuali ulteriori accessi.
“In sostanza, gli attaccanti stanno cercando ogni modo possibile per infiltrarsi nei repository e ottenere credenziali,” ha detto Nakibly, mentre Zvika Babo, ricercatore di Radware, ha sottolineato che l’attaccante non ha bisogno di compromettere il repository o avere accesso al codice per realizzare l’attacco. “Praticamente ogni utente con un account GitHub può provare a lanciare questo attacco, è molto semplice da avviare.”
Repository colpiti
Fino al 13 ottobre, i ricercatori hanno identificato 83 elementi GitHub con un payload verificato in 61 repository diversi, che includono framework di AI, strumenti di sicurezza, infrastrutture di sviluppo, database e altri progetti software open source ampiamente utilizzati. Tra i progetti più noti colpiti vi sono agno-agi/agno (42.7K stelle), ToolJet/ToolJet (41.1K), google/langextract (38.9K), aquasecurity/trivy (38.4K) e copilotkit/copilotkit (38K).
Altri obiettivi significativi includono QwenLM/qwen-code (28.5K), mlflow/mlflow (28.4K), discordjs/discord.js (26.8K) e brave/brave-browser (23.9K), con la maggior parte dei progetti utilizzati da migliaia di organizzazioni.
I ricercatori hanno comunicato le loro scoperte ai manutentori di tutti i progetti colpiti; molti repository sono stati successivamente chiusi o sistemati, anche se non è possibile confermare che tutti siano stati completamente ripristinati. Questa campagna fa seguito a diversi precedenti attacchi alla catena di approvvigionamento contro strumenti di sicurezza e sviluppo open source, in cui gli attaccanti cercano continuamente nuove modalità per rubare credenziali e altri segreti.
“Non esiste un modo per fermare gli attaccanti dal tentare,” ha concluso Nakibly. “L’unico rimedio è garantire che il codice del workflow sia resiliente e non vulnerabile a tali attacchi.” I ricercatori consigliano di limitare l’accesso ai workflow CI/CD e di separare, quando possibile, i workflow attivati da eventi esterni da quelli con autorizzazioni elevate, sottolineando anche l’importanza di trattare il contenuto esterno come non affidabile e limitare i segreti e le variabili ambientali accessibili al workflow.
