Attacco Megalodon: la più grande campagna di avvelenamento di repository su GitHub

L'operazione si è svolta tra le 11:36 e le 17:48 UTC circa, suggerendo un sistema altamente automatizzato progettato per compromettere un gran numero di repository rapidamente, prima che i manutentori notassero le modifiche.

Come gli aggressori hanno iniettato migliaia di commit così rapidamente

La campagna si basava sull'automazione e sul mascheramento sociale per far sembrare i commit malevoli come normale manutenzione CI.

Bot CI fasulli e account usa-e-getta

Gli aggressori hanno creato account GitHub usa-e-getta con nomi utente casuali e identità di automazione contraffatte, come:

• build-bot
• auto-ci
• ci-bot
• pipeline-bot

Queste identità facevano sembrare i commit provenienti da sistemi di automazione di routine piuttosto che da un attaccante umano.

Metadati dei commit contraffatti

I dati di paternità dei commit e i messaggi sono stati creati per sembrare legittimi, spesso somiglianti a normali aggiornamenti di workflow o piccole modifiche alla configurazione CI. Questo ha aiutato i commit a mimetizzarsi nell'attività di sviluppo normale e ha ritardato i sospetti.

Presa di mira di protezioni di branch deboli

La campagna si è concentrata su repository in cui le regole di protezione dei branch erano deboli o assenti. Senza revisioni obbligatorie delle pull request o restrizioni su chi può modificare i workflow, gli aggressori potevano forzare le modifiche ai workflow direttamente sul branch predefinito del repository.

Workflow GitHub Actions avvelenati

Ogni commit malevolo inseriva un file di workflow GitHub Actions contenente un payload Bash codificato in Base64. Quando la pipeline CI veniva eseguita, lo script veniva attivato all'interno del runner di GitHub Actions e iniziava a raccogliere credenziali.

Questo design significava che l'attacco spesso rimaneva dormiente fino alla successiva esecuzione della CI che attivava il workflow.

Cosa tentava di rubare il payload

Lo script codificato in Base64 incorporato nei workflow era progettato per raccogliere dati sensibili dall'ambiente CI e inviarli a infrastrutture controllate dagli aggressori.

I bersagli segnalati includevano:

• Variabili d'ambiente CI/CD
• Credenziali per provider cloud (AWS, Google Cloud, Azure)
• Chiavi SSH private
• Token API e segreti delle applicazioni
• Token OIDC di GitHub Actions
• Altri segreti di configurazione esposti nell'ambiente del runner

Il malware raccoglieva variabili d'ambiente, informazioni di sistema e segreti accessibili al runner CI prima di esfiltrarli verso un server di comando e controllo.

Poiché le pipeline CI contengono spesso credenziali di deployment, compromettere un ambiente di build può aprire percorsi verso infrastrutture cloud, registry di pacchetti e deployment di produzione.

Perché rubare i token OIDC è particolarmente pericoloso

Un obiettivo principale del payload di Megalodon erano i token OIDC di GitHub Actions.

Le pipeline CI/CD moderne utilizzano spesso la federazione OpenID Connect (OIDC) per autenticarsi ai provider cloud senza archiviare credenziali a lunga durata. Invece, un workflow richiede un token di identità a breve durata che i provider cloud scambiano per credenziali di accesso temporanee.

Questo approccio migliora la sicurezza eliminando chiavi API statiche o credenziali di account di servizio. Tuttavia, introduce un nuovo rischio: se un attaccante riesce a rubare il token durante l'esecuzione della pipeline, può impersonare temporaneamente l'identità del job CI.

Poiché questi token sono fidati dai sistemi di identità cloud, un token rubato può potenzialmente essere scambiato per accesso cloud temporaneo con gli stessi permessi concessi alla pipeline di deployment.

Ciò significa che un workflow CI compromesso potrebbe portare a:

• accesso all'infrastruttura cloud
• dirottamento della pipeline di deployment
• recupero di segreti dai servizi cloud

Anche se i token OIDC scadono rapidamente, i permessi ad essi associati possono comunque rendere l'accesso a breve termine estremamente prezioso per gli aggressori.

Perché l'attacco è importante

La campagna Megalodon illustra uno spostamento negli attacchi alla supply chain, dal modificare il codice dell'applicazione al compromettere l'infrastruttura di automazione.

Prendendo di mira i workflow CI invece del codice sorgente, gli aggressori possono:

• rubare credenziali automaticamente quando le pipeline vengono eseguite
• accedere a sistemi di deployment e ambienti cloud
• rimanere nascosti all'interno di modifiche di automazione di routine

Poiché migliaia di repository si affidano a pipeline CI con credenziali potenti, una singola modifica a un workflow può esporre segreti attraverso molti sistemi a valle.

C'era un collegamento tra Megalodon e la violazione dell'estensione VS Code di GitHub?

Nello stesso periodo, GitHub ha rivelato un incidente di sicurezza separato che coinvolgeva un'estensione Visual Studio Code infetta installata su un dispositivo di un dipendente. L'estensione malevola ha permesso agli aggressori di accedere a circa 3.800 repository interni di GitHub prima che la compromissione fosse contenuta.

Quella violazione è stata ricondotta a un ambiente di sviluppo compromesso e ha coinvolto il furto di credenziali attraverso un'estensione trojanizzata distribuita tramite il marketplace di VS Code.

Alcuni report di sicurezza notano somiglianze nei tempi e nelle tattiche tra quell'incidente e altri attacchi alla supply chain che prendono di mira gli strumenti di sviluppo. Tuttavia, le prove pubbliche non hanno confermato che la violazione interna di GitHub abbia direttamente abilitato la campagna Megalodon.

Per ora, i due incidenti sono meglio compresi come eventi di sicurezza della supply chain separati ma contemporanei che hanno colpito l'ecosistema degli sviluppatori.

La lezione più ampia per la sicurezza CI/CD

Megalodon dimostra quanto velocemente l'automazione possa scalare un attacco alla supply chain attraverso migliaia di repository. Combinando bot impersonati, commit automatizzati e workflow CI avvelenati, gli aggressori hanno trasformato l'infrastruttura di build di routine in un sistema di raccolta di credenziali.

L'incidente ha rafforzato diverse priorità difensive per i team software:

• regole di protezione dei branch rigorose
• revisioni obbligatorie per le modifiche ai workflow
• permessi minimi per i job CI
• monitoraggio attento degli account di automazione e degli aggiornamenti dei workflow

Poiché le pipeline di sviluppo controllano sempre più i deployment cloud e l'infrastruttura di produzione, la sicurezza dei workflow CI/CD è diventata una parte critica della difesa della supply chain software.