L'attacco Megalodon colpisce 5.561 repository GitHub in sei ore
Un attacco alla supply chain CI/CD di GitHub denominato Megalodon ha stabilito un nuovo punto di riferimento per la compromissione automatizzata e su larga scala dei repository. In una finestra di soli sei ore, gli aggressori hanno inviato 5.718 aggiornamenti di codice malevolo su 5.561 repository GitHub, utilizzando identità false per iniettare file di workflow progettati per sottrarre silenziosamente credenziali cloud, chiavi SSH e segreti del codice sorgente. La velocità e il volume della campagna segnalano un cambiamento verso attacchi industrializzati alle pipeline, che superano la capacità della maggior parte dei team di rilevare o rispondere in tempo reale.
Come ha funzionato l'attacco Megalodon: identità false e iniezione automatizzata di workflow
Gli aggressori dietro Megalodon non hanno fatto affidamento su exploit zero-day o malware sofisticati distribuiti sui dispositivi degli utenti finali. Hanno invece sfruttato la natura fidata dell'infrastruttura CI/CD di GitHub stessa. Costruendo identità false di collaboratori, hanno inviato pull request o modificato direttamente i file di configurazione del workflow, in particolare i file YAML che GitHub Actions utilizza per definire le pipeline automatizzate di build e distribuzione.
Una volta che un file di workflow malevolo approda in un repository, viene eseguito automaticamente ogni volta che la pipeline si attiva, tipicamente in seguito a eventi di push o merge di pull request. Tale esecuzione avviene all'interno dell'ambiente runner di GitHub, che spesso ha accesso ai segreti del repository, alle variabili d'ambiente e ai token relativi ai provider cloud. I workflow di Megalodon hanno sfruttato quella finestra di accesso per esfiltrare dati verso l'esterno, probabilmente verso infrastrutture controllate dagli aggressori, prima che qualsiasi responsabile del repository avesse motivo di esaminare la modifica.
La caratteristica distintiva della campagna è la sua automazione. Eseguire quasi 5.720 push di codice distinti su più di 5.500 repository in sei ore non è uno sforzo manuale. Richiede strumenti con script in grado di identificare obiettivi, autenticarsi con identità false, elaborare modifiche ai workflow dall'aspetto plausibile e inviarle in parallelo. Questo livello di automazione significa che la superficie d'attacco si è espansa più velocemente di quanto qualsiasi team di monitoraggio umano potesse tracciare.
Quali credenziali sono state rubate e perché questo è importante per gli sviluppatori
Il payload di ciascun workflow malevolo era la raccolta di credenziali. Gli obiettivi includevano le credenziali dei provider cloud, più comunemente chiavi di accesso AWS, GCP e Azure archiviate come GitHub Secrets o referenziate all'interno delle variabili d'ambiente del workflow. Erano nel mirino anche le chiavi private SSH utilizzate per l'accesso ai server o per l'autenticazione tra servizi, insieme a qualsiasi segreto in chiaro incorporato nel codice sorgente o nei file di configurazione.
Questi tipi di credenziali comportano rischi a cascata. Una chiave di accesso AWS rubata legata a un ruolo IAM con ampie autorizzazioni può consentire a un aggressore di avviare infrastrutture, esfiltrare archivi dati o spostarsi lateralmente nei servizi connessi in pochi minuti. Le chiavi SSH possono fornire accesso persistente ai server di produzione molto tempo dopo che la violazione originale è stata rilevata e il repository GitHub è stato ripristinato. Il valore di questi dati si estende ben oltre i repository stessi.
Non si tratta di un pattern di rischio ipotetico. All'inizio di quest'anno, un appaltatore della CISA ha esposto chiavi AWS e password in chiaro su un repository GitHub pubblico, dimostrando che la gestione scorretta delle credenziali negli ambienti di sviluppo riguarda anche organizzazioni con mandati di sicurezza dedicati. Megalodon ha semplicemente industrializzato lo stesso percorso di exploit che i singoli errori umani hanno già dimostrato ripetutamente.
Vale anche la pena notare che gli strumenti e le pipeline per il furto di credenziali sono essi stessi degli obiettivi. Il recente attacco alla supply chain di Bitwarden CLI ha dimostrato che persino gli strumenti che gli sviluppatori utilizzano per gestire i segreti possono essere compromessi a monte, il che significa che la catena di fiducia si estende oltre qualsiasi singolo repository o configurazione di pipeline.
Difesa in profondità per i team di sviluppo: gestione dei segreti, comunicazioni cifrate e controlli degli accessi
Megalodon ha sfruttato diverse vulnerabilità comuni sia nei repository open source che in quelli privati. Affrontarle richiede un approccio a più livelli piuttosto che un singolo controllo.
In primo luogo, i segreti non dovrebbero mai essere archiviati in chiaro all'interno dei file di workflow, dei file di configurazione dell'ambiente o del codice sorgente. La funzionalità Secrets cifrati di GitHub fornisce una base di partenza, ma tali segreti dovrebbero anche seguire il principio del privilegio minimo. Un workflow che distribuisce in un ambiente di staging non ha bisogno delle credenziali del database di produzione. Limitare l'ambito dei segreti riduce il raggio d'azione quando un workflow viene compromesso.
In secondo luogo, le regole di protezione dei branch e i revisori obbligatori per le modifiche ai file di workflow creano un punto di controllo umano che gli attacchi automatizzati devono aggirare. Richiedere almeno una revisione approvata prima di qualsiasi modifica ai file .github/workflows/ può rallentare o bloccare il tipo di iniezione automatizzata rapida su cui si è basato Megalodon.
In terzo luogo, fissare le GitHub Actions di terze parti a SHA di commit specifici piuttosto che a tag variabili previene un vettore di attacco separato ma correlato, in cui i publisher di action compromessi aggiornano silenziosamente un tag per puntare a codice malevolo. Questo è stato il meccanismo alla base di diversi recenti incidenti nella supply chain di GitHub Actions.
Infine, la registrazione degli audit e il rilevamento delle anomalie nelle esecuzioni del workflow possono evidenziare connessioni di rete in uscita inaspettate o pattern insoliti di accesso ai segreti. L'API del log di audit di GitHub e gli strumenti di sicurezza CI/CD di terze parti possono contribuire a far emergere questi segnali.
Come verificare ora i tuoi repository GitHub e le pipeline CI/CD
Se la tua organizzazione gestisce repository GitHub con pipeline CI/CD attive, è opportuno dare priorità ad alcuni passaggi immediati.
Esamina tutti i file in .github/workflows/ per individuare eventuali voci aggiunte o modificate di recente, in particolare quelle aggiunte da collaboratori che non riconosci. Controlla la cronologia dei commit per i file di workflow nello specifico, non solo la visualizzazione del branch predefinito.
Ruota tutti i segreti che erano attivi durante il periodo dell'attacco o che non puoi confermare con certezza come non esposti. Per le credenziali cloud, esamina i log di accesso lato provider per eventuali chiamate API insolite durante lo stesso intervallo di tempo.
Verifica quali collaboratori e applicazioni del repository hanno accesso in scrittura. Gli attacchi con identità false dipendono dalla capacità di inviare codice, quindi restringere le autorizzazioni dei collaboratori e abilitare le revisioni obbligatorie per le modifiche ai workflow elimina un punto di accesso chiave.
Infine, valuta l'adozione di uno strumento dedicato alla scansione dei segreti che venga eseguito ad ogni commit, intercettando le credenziali prima che vengano mai committate in un repository. Diverse opzioni open source e commerciali si integrano direttamente con GitHub.
Cosa significa per te
La campagna Megalodon è un'illustrazione pratica del motivo per cui le pipeline CI/CD sono diventate una superficie d'attacco primaria. Gli sviluppatori e i team di sicurezza che trattano la sicurezza delle pipeline come secondaria rispetto alla sicurezza delle applicazioni lasciano un percorso completamente aperto verso le loro credenziali più sensibili.
Inizia con un audit dei segreti questa settimana. Verifica chi può modificare i tuoi file di workflow, ruota le credenziali che non puoi verificare come pulite e abilita la protezione del branch sul tuo branch predefinito se non l'hai ancora fatto. La velocità dell'attacco Megalodon significa che nel momento in cui scatta un avviso, l'esfiltrazione potrebbe essere già completata. La prevenzione e la limitazione degli accessi sono le uniche difese affidabili.
