Le credenziali rubate di 4.837 account GitHub hanno permesso a un attaccante di distribuire malware mirato ai segreti dei repository e agli accessi al cloud, secondo quanto dichiarato da Aikido Security in un'analisi riportata da The Hacker News il 12 novembre. La campagna è iniziata martedì 10 novembre e il malware è stato eseguito in almeno 1.806 repository, dove Aikido ritiene che le credenziali siano probabilmente state rubate.
I proprietari dei repository, gli amministratori delle organizzazioni e gli sviluppatori che hanno installato codice interessato affrontano rischi diversi. Aikido considera compromesso qualsiasi account usato per aprire le pull request di test dell'attaccante, indipendentemente dal fatto che il malware sia poi stato eseguito. Dove l'esecuzione è avvenuta, tutti i segreti e i ruoli cloud accessibili ai workflow automatizzati devono essere considerati compromessi.
Le verifiche di scrittura hanno raggiunto 61.764 repository
L'attaccante ha verificato i permessi di ogni account sui repository inviando una pull request, cioè una proposta di modifica al codice, con il titolo docs: dependency audit notes dal branch wfx-docs. Aikido ha registrato questi test in 61.764 repository. I permessi da collaboratore o di organizzazione hanno riguardato 10.431 pull request di test, estendendo la campagna oltre i repository di proprietà degli account rubati. Il 92% di tali richieste risultava ancora aperto al momento del controllo.
La maggior parte dei repository sondati non ha ricevuto alcun payload successivo, oppure aveva impostazioni o permessi dell'account che ne impedivano l'esecuzione. La visibilità di Aikido era limitata ai repository pubblici, anche se le impostazioni dei repository privati presenti nel malware suggeriscono che potrebbe operare anche in ambienti privati.
SafeDep, azienda specializzata nella sicurezza della supply chain del software, ha individuato separatamente commit malevoli in 8.093 repository tra le 12:46 UTC del 10 novembre e le 04:36 UTC del 12 novembre. Questo dato misura la consegna, non l'esecuzione. La ricerca ha esaminato solo i branch predefiniti dei repository pubblici, quindi i ricercatori ritengono che il totale sia più alto.
I workflow di integrazione continua (CI) già esistenti, cioè i job automatizzati che compilano e verificano il codice, hanno ricevuto il payload in 7.309 repository. Altri 771 lo hanno ricevuto tramite un hook postinstall di npm, uno script attivato da npm install che può essere eseguito anche sul computer di uno sviluppatore.
L'attività è proseguita oltre la ricerca di Aikido, conclusa mercoledì. The Hacker News ha verificato tre pull request aggiuntive aperte tra le 05:04 e le 05:38 UTC del 12 novembre: ognuna usava lo stesso titolo e un branch wfx-docs, anche se non è chiara la successiva consegna del malware.
Cosa può sottrarre e conservare il malware
Aikido descrive uno stealer progettato per cercare credenziali nel runner, cioè la macchina che esegue un workflow. I suoi obiettivi comprendono segreti e variabili di GitHub Actions, GITHUB_TOKEN, i token runtime di Actions, le chiavi dei servizi di intelligenza artificiale e i segreti presenti nella memoria dei processi. Legge anche i file di credenziali usati da AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH e altri strumenti.
La raccolta si estende al contenuto dei repository, agli ultimi 100 commit e agli artefatti recenti dei workflow, cioè gli output dei job salvati. Sui runner self-hosted, il malware prende di mira anche le credenziali cloud esposte tramite instance metadata, lo stato dei container Docker e le systemd unit, che definiscono i servizi di sistema.
SafeDep ha individuato due canali per inviare all'esterno il materiale sottratto: richieste HTTP POST verso server dell'attaccante e messaggi a una chat Telegram. Circa un quinto dei 200 commit con payload campionati si affidava esclusivamente a Telegram.
L'accesso al cloud può persistere anche dopo la sostituzione dei segreti originali. Il malware può scambiare token GitHub OpenID Connect (OIDC), cioè asserzioni di identità che i workflow usano per richiedere l'accesso al cloud, con sessioni in AWS, GCP e Azure. Le sue funzioni su AWS includono la creazione di chiavi di accesso a lungo termine per gli utenti Identity and Access Management (IAM) e la modifica della trust policy di un ruolo per ammettere qualsiasi account AWS.
Per le applicazioni Azure AD, il malware può creare credenziali di identità federate il cui nome inizia con wfx-ci-. Queste stabiliscono una relazione di accesso attendibile, consentendo ai workflow del repository compromesso di autenticarsi senza un segreto memorizzato, anche dopo la rotazione dei token.
Aikido ha inoltre riscontrato un collegamento con la campagna GhostAction di ottobre, che usava account GitHub rubati per introdurre workflow in grado di sottrarre segreti. Gli account colpiti allora avevano circa 1.000 volte più probabilità rispetto agli altri account attivi di comparire nell'attività di novembre. In più di 100 repository, l'ultimo payload è entrato nei file di workflow di ottobre senza rimuovere il passaggio di furto di dati già presente. Aikido non attribuisce l'attività allo stesso attore, perché infrastruttura, strumenti e metodi sono diversi, e le credenziali rubate possono circolare tra più attaccanti.
L'esposizione dei pacchetti dipende dall'uso del codice
I trigger di pubblicazione automatica hanno portato il malware in almeno un pacchetto Packagist e in un modulo Go. Almeno 50 utenti compromessi sembrano pubblicare tramite npm, Go, Packagist, PyPI o crates, anche se Aikido ritiene che l'obiettivo apparente dell'attaccante fosse ottenere i segreti della CI.
La release malevola su Packagist è digitalelvis/neuronai-studio versione 3.14.3. La sua scheda riportava come data di pubblicazione l'11 novembre. Nelle prime ore del 12 novembre era ancora disponibile, con un avviso che segnalava le versioni del pacchetto come malware. Aikido consiglia di considerare compromessi i computer che lo hanno installato o aperto. L'esecuzione dipende dal comando: un normale composer install non avvia lo stealer, mentre npm install all'interno della directory vendor del pacchetto sì. Gli utenti dovrebbero bloccare v3.14.3 e fissare la versione v3.14.2 o una precedente.
Per github.com/onuragtas/docker-env, le versioni v1.0.278 e v1.0.280 contengono il payload solo in un workflow di GitHub Actions. Né il codice Go né i binari delle release sono cambiati, e le build Go non eseguono i file di workflow, quindi gli utenti del modulo potrebbero non essere stati esposti. Aikido raccomanda comunque di rimuovere entrambe le versioni.
I ricercatori hanno inoltre individuato un workflow malevolo in github.com/vkuznet/gocurl, pseudo-versione v0.0.0-20261111095532-8d5aad0cb0da. Quel workflow non è mai stato eseguito, ma gli utenti dovrebbero bloccare la pseudo-versione.
I commit attribuiti a wdio-bot hanno portato lo stealer in 28 repository WebdriverIO. Le release dei pacchetti non sono state interessate, ma il token del bot va considerato rubato.
Trovare le modifiche, poi revocare gli accessi
I proprietari dei repository dovrebbero esaminare l'attività dal 10 novembre in poi in ogni repository su cui possono scrivere. L'attaccante ha in genere annullato le modifiche malevole nel giro di pochi minuti e ha cancellato i log di esecuzione, eliminando di solito anche l'esecuzione del workflow. Un file attuale pulito, quindi, non chiarisce se le credenziali siano state esposte.
Cercate branch chiamati wfx-docs, branch di breve durata che corrispondono a chore/[a-z0-9]{8} e branch che corrispondono a ci-check-[0-9]{4}. Insieme al titolo della pull request docs: dependency audit notes, questi messaggi di commit identificano le modifiche rilevanti:
ci: refresh build cache: circa 1.500 righe inserite in un workflow esistente.chore: add ci helper: uno script.ci-xxxxxx.shabbinato a un hook postinstall inpackage.json, attivato da qualsiasinpm install.chore: add dependency audit workflow: un nuovo file.github/workflows/build-audit-xxxxxx.ymlsu un branchchore/.chore: initial commit: un commit che precede l'aggiunta di un file di workflow in un repository vuoto.ci: restoreeci: cleanup.
L'impronta SHA-256 dello script dello stealer è 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Gli indicatori di rete sono 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil e 153.75.82[.]159:8080.
L'assenza di artefatti wfx-loot, di voci di cache wfx- o di riepiloghi di step WFX-BEGIN non esclude il furto. I ricercatori hanno descritto una lacuna nella numerazione delle esecuzioni sul commit dell'attaccante come un indizio di esecuzione più affidabile.
Anche gli amministratori cloud dovrebbero verificare i meccanismi di persistenza individuati dai ricercatori:
- Entra ID: credenziali federate sconosciute denominate
wfx-ci-*. - AWS CloudTrail: sessioni
AssumeRoleWithWebIdentityoAssumeRoledenominatewfx-*, seguite daCreateAccessKeyoUpdateAssumeRolePolicy. - GCP: chiamate
GenerateAccessTokeneSignJwtprovenienti dal pool di identità del workload GitHub, che fornisce le identità dei workflow per l'accesso al cloud. - Vault: accessi tramite JSON Web Token (JWT) che usano l'emittente OIDC di GitHub.
SafeDep consiglia ai proprietari dei repository interessati di revocare token, concessioni di applicazioni OAuth, chiavi SSH e sessioni dell'autore del commit, attivare l'autenticazione a due fattori e ruotare ogni segreto e variabile leggibile dal repository. Gli sviluppatori che hanno eseguito npm install su un commit interessato dovrebbero considerare compromesso il proprio computer e ruotarne le chiavi.
