Rivelati i dettagli dell'attacco all'infrastruttura utilizzata nello sviluppo del framework di machine learning PyTorch, che ha permesso di estrarre chiavi di accesso sufficienti per caricare dati arbitrari nel repository delle versioni del progetto su GitHub e AWS, nonché per iniettare codice nel ramo principale del repository e aggiungere un backdoor tramite le dipendenze. La sostituzione delle versioni di PyTorch potrebbe essere stata utilizzata per attaccare grandi aziende come Google, Meta, Boeing e Lockheed Martin, che utilizzano PyTorch nei loro progetti. Nell'ambito del programma Bug Bounty, Meta ha pagato agli investigatori $16.250 per informazioni sul problema.
Il nocciolo dell'attacco riguarda l'esecuzione del proprio codice su server integrazione continua, che compie ricompilazioni ed esegue compiti per testare nuove modifiche inviate al repository. Il problema colpisce i progetti che utilizzano gestori esterni "Self-Hosted Runner" con GitHub Actions. A differenza delle tradizionali GitHub Actions, i gestori Self-Hosted non vengono eseguiti nell'infrastruttura di GitHub, ma sui propri server o in ambienti virtuali macchine supportate dagli sviluppatori.
Eseguire attività di build sui propri server consente di avviare codice in grado di effettuare la scansione della rete interna dell'azienda, cercare nella FS locale chiavi di crittografia e token di accesso, analizzare le variabili d'ambiente con parametri per accedere a archivi esterni o servizi cloud. Senza un'adeguata isolamento dell'ambiente di build, i dati riservati trovati possono essere inviati all'esterno dagli aggressori, ad esempio, tramite chiamate a API esterne. Per identificare l'uso dei progetti «Self-Hosted Runner», può essere utilizzato lo strumento Gato, che analizza i file workflow pubblici e i log di esecuzione delle attività CI.
In PyTorch e in molti altri progetti che utilizzano il "Self-Hosted Runner", l'esecuzione di incarichi di build è consentita solo agli sviluppatori le cui modifiche sono state precedentemente revisionate e incluse nel codice sorgente del progetto. Avere lo stato di "contributor" quando si utilizzano le impostazioni predefinite nel repository consente di eseguire i gestori di GitHub Actions durante l'invio di pull request e, di conseguenza, di eseguire il proprio codice in qualsiasi ambiente GitHub Actions Runner collegato a quel repository o all'organizzazione che gestisce il progetto.
El legame con lo stato di «contributor» si è dimostrato facile da eludere: è sufficiente inviare una modifica insignificante in anticipo e attendere che venga accettata nel codice, dopodiché il sviluppatore riceve automaticamente lo status di collaboratore attivo, le cui pull request possono essere testate nell'infrastruttura CI senza ulteriori verifiche. Per ottenere lo status di sviluppatore attivo, durante l'esperimento sono state utilizzate modiche cosmetiche minime, relative alla correzione di errori di battitura nella documentazione. Per accedere al repository e allo storage delle versioni di PyTorch, durante l'attacco è stata effettuata l'intercettazione del token GitHub, utilizzato per accedere al repository dai processi di build, così come delle chiavi AWS impiegate per salvare i risultati della build.
Il problema non è specifico di PyTorch e coinvolge molti altri grandi progetti che utilizzano le impostazioni predefinite per il "Self-Hosted Runner" in GitHub Actions. Ad esempio, sono stati segnalati attacchi simili per l'inserimento di backdoor in alcuni importanti portafogli di criptovalute e progetti blockchain con capitalizzazioni miliardarie, modifiche alle versioni di Microsoft Deepspeed e TensorFlow, compromissione di una delle applicazioni di CloudFlare e anche esecuzione di codice sui computer nella rete Microsoft. I dettagli di questi incidenti non sono ancora stati divulgati. Nell'ambito dei programmi Bug Bounty, i ricercatori hanno inviato oltre 20 richieste per ottenere ricompense per un totale di diverse centinaia di migliaia di dollari.
Fonte: opennet.ru
