Quando un workflow diventa l’arma: la campagna di avvelenamento CI su GitHub nascosta in bella vista

Introduzione

L’automazione dovrebbe ridurre gli attriti. In questo caso, sembra essere diventata il sistema di distribuzione. Una campagna etichettata Megalodon è stata collegata a migliaia di repository GitHub e a file di workflow che potevano trasformare l’infrastruttura di build in payload eseguibili. Il pattern conta più del numero grezzo: quando viene toccata l’automazione di un repository, l’attaccante potrebbe non aver bisogno di compromettere la build per abusarne.

Dati rapidi

• I ricercatori hanno reso nota una campagna automatizzata chiamata Megalodon.
• Secondo quanto riportato, ha inserito 5.718 commit malevoli in 5.561 repository GitHub nell’arco di circa sei ore.
• L’attività ha usato account usa e getta e nomi autore contraffatti in stile CI come build-bot, auto-ci, ci-bot e pipeline-bot.
• I workflow di GitHub Actions inseriti contenevano payload Bash codificati in base64.
• Lo stralcio visibile suggerisce un obiettivo di esfiltrazione, ma il bersaglio completo ed il successo di un eventuale furto non sono pienamente visibili.

Corpo

Dal punto di vista difensivo, si tratta di un classico problema di avvelenamento CI/CD. I workflow di GitHub Actions non sono solo configurazione; sono automazione eseguibile. Quando un file di workflow viene alterato, il percorso del codice può passare da “code review” a “code execution” non appena si attiva il trigger. Ecco perché i file di workflow meritano la stessa attenzione del codice applicativo.

L’uso riportato di account usa e getta e di identità fasulle simili a bot è altrettanto indicativo. Questo tipo di camuffamento è progettato per far sembrare i commit malevoli rumore di automazione di routine. Nei repository in rapido movimento, nomi che ricordano l’infrastruttura di build possono ridurre i sospetti abbastanza a lungo da far sì che un workflow dannoso venga unito, o almeno lasciato in sede fino all’esecuzione del job successivo.

Il rischio maggiore non è solo una pipeline interrotta. I job di GitHub Actions possono interagire con credenziali limitate al repository e con altri secret a seconda di come è configurato il workflow. Se viene eseguito un workflow malevolo, potrebbe essere in grado di leggere variabili d’ambiente, token o altro materiale che non dovrebbe mai uscire dal runner. In alcuni ambienti, questo può creare un percorso da un singolo file di workflow all’accesso al cloud, alla pubblicazione di pacchetti o a successive manomissioni del repository.

Resta una cautela importante: i dettagli disponibili non mostrano completamente il bersaglio dell’esfiltrazione e non dimostrano che ogni repository colpito abbia eseguito il payload. Questa incertezza è importante. La lezione tecnica resta comunque chiara: un file di workflow fa parte della superficie d’attacco, non è uno script di supporto innocuo.

Le linee guida di sicurezza di GitHub rendono esplicita questa distinzione. Le autorizzazioni predefinite dei token dovrebbero essere ridotte al minimo, gli input non attendibili non dovrebbero essere interpolati direttamente nei comandi shell e i trigger ad alto rischio come pull_request_target richiedono una progettazione attenta perché possono modificare in modo sottile il confine dei privilegi. Questi controlli non bloccano ogni caso di abuso, ma aumentano il costo di trasformare l’automazione contro il suo proprietario.

Conclusione

La lezione più profonda è che gli attacchi alla supply chain del software non iniziano sempre con il furto del codice sorgente o con la compromissione di una pagina di login. A volte iniziano con un file di workflow che sembra ordinario, viene eseguito automaticamente e eredita più fiducia di quanta ne meriti. Nel CI/CD moderno, la linea tra comodità e compromissione è spesso larga solo pochi permessi.

TECHCROOK

Chiave di sicurezza hardware: Una piccola chiave di sicurezza USB o NFC aggiunge una forte autenticazione a due fattori per GitHub, le console cloud e gli account degli sviluppatori. È un modo pratico per irrobustire l’accesso ai repository, alle impostazioni CI/CD e ad altri login amministrativi sensibili.

Scheda Techcrook: Chiave di sicurezza hardware

WIKICROOK

• GitHub Actions: il sistema di automazione di GitHub per eseguire workflow attivati dagli eventi del repository.
• CI/CD: integrazione continua e distribuzione continua, la pipeline automatizzata di build-test-release usata nella distribuzione software.
• Workflow file: una configurazione YAML che definisce cosa fa un job di GitHub Actions e quando viene eseguito.
• GITHUB_TOKEN: un token temporaneo con ambito sul repository che GitHub crea per i job del workflow.
• pull_request_target: un trigger di GitHub Actions che può essere eseguito con permessi del repository più elevati rispetto a un normale workflow di pull request.