wfx-loot su GitHub: come rilevare il furto di segreti e intervenire

La campagna wfx-loot ha usato 4.837 account già compromessi di GitHub per aprire pull request in 61.764 repository dal 10 novembre. Aikido ha identificato almeno 1.835 repository in cui è stato eseguito un payload che rubava segreti di GitHub Actions e credenziali cloud; il codice poteva anche raggiungere pacchetti pubblicati tramite automazioni.

I repository potenzialmente interessati sono quelli in cui un account compromesso poteva scrivere, compresi quelli accessibili tramite collaborazione o appartenenza a un'organizzazione, anche se non appartenevano a quell'account. Il primo indizio potrebbe essere una pull request intitolata docs: dependency audit notes, proveniente dal branch wfx-docs. Aikido avverte che quella pull request era una verifica dei permessi: per sapere se c'è stato un furto, occorre cercare anche le modifiche successive e gli indizi di esecuzione.

Per prima cosa, determina se c'è stata un'esecuzione

Cerca nei repository a cui hai accesso pull request con quel titolo, oltre a branch chiamati chore/ seguiti da otto caratteri casuali. Controlla anche i commit intitolati ci: refresh build cache, chore: add ci helper o chore: add dependency audit workflow. Sono indicatori descritti da Aikido; la loro presenza giustifica un'indagine sul repository, ma una pull request di verifica, da sola, non conferma che siano state esfiltrate credenziali.

Il payload è stato inserito in tre modi: modificando un workflow GitHub Actions esistente, aggiungendo uno script con un hook di installazione npm oppure creando un nuovo workflow in un branch temporaneo. Cerca modifiche ai workflow e agli script, compresi quelli che sono già stati ripristinati. L'attaccante poteva eliminare il workflow di esecuzione e i relativi log in meno di un minuto. Aikido segnala che un numero di esecuzione mancante nella cronologia può essere un indizio; l'assenza di log, artefatti o riepiloghi non dimostra che non ci sia stato un furto.

Se il workflow è stato eseguito, non limitare la verifica alle variabili presenti nel codice del repository. Il payload poteva raccogliere segreti e variabili di Actions, token di esecuzione, credenziali cloud, file di configurazione, chiavi SSH, file .env e credenziali di strumenti di sviluppo e IA. Considera esposto tutto ciò che era accessibile ai workflow interessati e al runner su cui sono stati eseguiti.

Passaggi per contenere l'incidente

1. Identifica l'ambito dei permessi di scrittura. Controlla i repository di proprietà e quelli a cui l'account poteva accedere come collaboratore o tramite appartenenza a un'organizzazione. Aikido ha registrato 10.431 pull request in repository che non appartenevano all'account compromesso. Includi i progetti con automazioni di pubblicazione: la campagna ha raggiunto un pacchetto Packagist e due tag di un modulo Go.

2. Conserva ciò che è ancora disponibile. Salva le pull request, i branch, i commit e i log disponibili per ogni repository sospetto prima di ripulirlo. Annota le modifiche e gli orari rilevati. Non fare affidamento sulla cronologia delle esecuzioni: l'attaccante poteva eliminarla e il numero di esecuzione mancante potrebbe essere l'unica traccia del fatto che il workflow sia stato eseguito.

3. Revoca e ruota le credenziali accessibili. Se confermi che il payload è stato eseguito, considera compromessi i segreti e le credenziali disponibili per quei workflow. Includi le credenziali cloud e dei servizi, non solo i segreti di GitHub Actions; dai priorità a quelle che i workflow interessati potevano utilizzare.

4. Controlla AWS e Azure per individuare eventuali meccanismi di persistenza. Il payload disponeva di funzioni per ampliare e mantenere l'accesso: poteva modificare la policy di attendibilità di un ruolo AWS e aggiungere credenziali di identità federata alle applicazioni Azure. Verifica la presenza di modifiche non autorizzate a tali autorizzazioni e configurazioni. Ruotare una chiave non basta se è stato modificato anche il modo in cui viene concesso l'accesso.

5. Esamina i runner interessati. Lo script poteva leggere l'ambiente e la memoria dei processi del runner; sui runner autogestiti cercava anche credenziali e stato dei container. Esamina il runner su cui è stato eseguito il workflow e le credenziali a sua disposizione. Se è stato installato un pacchetto sospetto, considera compromessa la macchina secondo le indicazioni specifiche di Aikido per Packagist.

6. Controlla i pacchetti interessati. Aikido identifica digitalelvis/neuronai-studio di Packagist, versione 3.14.3, e i tag v1.0.278 e v1.0.280 di github.com/onuragtas/docker-env. Aikido consiglia di considerare compromessa qualsiasi macchina che abbia installato o aperto la versione di Packagist. Nei tag Go, il payload era presente solo in un file di workflow GitHub Actions: Aikido afferma che il codice sorgente e i binari pubblicati non sono stati modificati, pur consigliando di ritirare quei pacchetti.

7. Estendi l'analisi all'organizzazione. Verifica se lo stesso account ha aperto pull request in più repository e se i token associati disponevano di permessi più ampi. SecurityWeek riporta che gli attaccanti hanno usato token validi appartenenti ad account di sviluppatori e bot; non hanno sfruttato una vulnerabilità di GitHub Actions. Se rilevi attività in più progetti, controlla anche le relative integrazioni e le credenziali cloud disponibili.

8. Ripeti la ricerca dopo la pulizia. Dopo aver revocato gli accessi e verificato le modifiche, controlla di nuovo branch, pull request, workflow e configurazioni cloud. Aikido descrive meccanismi progettati per persistere anche dopo la rotazione delle credenziali; perciò, la risposta non si conclude con l'eliminazione del file malevolo o la chiusura della pull request.

Errori che possono lasciare una porta aperta

Non confondere la verifica con l'esecuzione. La pull request di prova mirava a confermare che il token avesse il permesso di scrittura; Aikido indica che era solo la fase iniziale. Ma non considerarla innocua: cerca i commit e i workflow che potrebbero averla seguita e verifica se ci sono indizi di esecuzione.

Non considerare rassicurante l'assenza di log. L'attaccante ripristinava le modifiche ed eliminava le esecuzioni e i log. Secondo Aikido, non basta nemmeno non trovare artefatti wfx-loot, voci di cache o riepiloghi con WFX-BEGIN: questi canali erano disattivati nella configurazione osservata. Una cronologia apparentemente pulita non esclude il furto.

Non limitarti ai repository di tua proprietà. Gli account compromessi potevano scrivere nei progetti di terzi tramite accesso di collaborazione o di organizzazione. Controlla tutti i repository per cui quelle credenziali avevano i permessi, compresi quelli che pubblicano pacchetti automaticamente.

Non ruotare i segreti senza controllare i permessi. Aikido documenta funzioni che modificano le configurazioni di attendibilità in AWS e Azure. Verifica se ci sono state modifiche persistenti in questi ambienti, oltre a revocare i token e ruotare i segreti; in caso contrario, un accesso aggiuntivo potrebbe sopravvivere alla rotazione.

La soglia pratica è chiara: se il payload è stato eseguito, considera esposto ogni segreto a cui il workflow poteva accedere e controlla i permessi cloud associati. Se trovi solo la pull request di verifica, continua a indagare sulle modifiche successive prima di chiudere il caso.

Fonti: Help Net Security, MuySeguridad. Sicurezza informatica., Aikido Security, SecurityWeek, TechRadar