Token GitHub rubati hanno permesso una campagna automatizzata per estrarre segreti da repository privati e ambienti GitHub Enterprise Server, secondo la società di sicurezza cloud Wiz. L'operazione, chiamata Gheist, trasforma i log di GitHub Actions in un canale di raccolta: workflow malevoli scrivono credenziali codificate nei log, che gli attaccanti recuperano prima di eliminare le esecuzioni.
Wiz ha recuperato oltre 13.500 branch creati dagli attaccanti, associati a oltre 850 account compromessi, che coprono sia progetti personali sia repository aziendali. Questi dati misurano branch e account; i risultati non stabiliscono quante organizzazioni abbiano avuto segreti esposti.
I ricercatori seguono Gheist dal 15 settembre. Al 24 ottobre risultava ancora attivo e in continua evoluzione, secondo il report di The Hacker News sull'analisi di Wiz. Il nome deriva da gheist, lo user agent che lo strumento invia nelle richieste alle API di GitHub.
Dove sono stati eseguiti i workflow
I log di audit di GitHub hanno fornito prove dell'esecuzione in repository privati e su GitHub Enterprise Server: le esecuzioni sui branch malevoli sono state completate, dopodiché richieste con lo user agent gheist le hanno eliminate. I log di AWS CloudTrail hanno inoltre mostrato che workflow legittimi delle organizzazioni venivano eseguiti da quei branch e assumevano ruoli AWS, il che indica che i job di Actions erano stati eseguiti senza approvazione.
All'interno delle organizzazioni enterprise, lo strumento ha alternato nel giro di pochi minuti token appartenenti a utenti e account di automazione. Ha clonato i repository privati prima di introdurre il workflow malevolo. Le credenziali cloud della stessa organizzazione sono state poi usate, ore dopo, per enumerare AWS Secrets Manager. Wiz non ha stabilito l'origine di tali credenziali né identificato chi le ha usate.
I repository pubblici hanno mostrato un esito diverso. Ogni esecuzione pubblica di Gheist esaminata da Wiz, in tutte le versioni dello strumento osservate, è rimasta in attesa di approvazione e quindi non ha eseguito il payload.
GitHub ha introdotto questa sospensione il 28 luglio per i workflow che identifica come potenzialmente malevoli. Un collaboratore con accesso in scrittura deve approvare un'esecuzione segnalata. La misura copre solo i repository pubblici su github.com; i repository privati e GitHub Enterprise Server ne restano fuori. Anche la sua protezione dipende dal fatto che GitHub segnali l'esecuzione.
Dall'accesso ai repository alle credenziali leggibili
Gheist parte da un token già rubato che concede accesso in scrittura a un repository. Wiz ha ricondotto alcuni token a log di infostealer e a precedenti compromissioni della supply chain, tra cui la compromissione di marzo dello scanner di vulnerabilità Trivy.
Per i repository raggiungibili con un token, lo strumento esegue il push di un commit non firmato a nome del proprietario del token. La combinazione che lo identifica è un branch corrispondente a ^ci-sync-[0-9a-z]{6}$, il messaggio di commit ci: sync config e un unico file aggiunto: .github/workflows/sync-check.yml.
Quel push avvia un workflow che scrive nei log l'ambiente del job e i segreti accessibili, usando la codifica base32. La documentazione di GitHub avverte che il mascheramento dei segreti può non funzionare quando i valori sono stati trasformati. Secondo Wiz, la rappresentazione base32 elude il mascheramento perché è diversa dal segreto originale. Una delle stringhe di rilevamento pubblicate è toJSON(secrets) }}' | base32 -w 120.
Sebbene il workflow dichiari un blocco permissions vuoto, questo limita il suo GITHUB_TOKEN senza impedirgli di leggere i segreti. Gli attaccanti si affidano al token rubato per recuperare i log risultanti tramite l'API di GitHub, poi cancellano l'esecuzione pochi secondi dopo. La raccolta quindi sfrutta la stessa GitHub, senza richiedere una destinazione separata controllata dagli attaccanti.
Una variante pianifica anche un job per ogni ambiente di deployment, per raggiungere i segreti associati a quegli ambienti, che secondo Wiz includono spesso credenziali di produzione. I revisori obbligatori possono impedire questo accesso: la documentazione di GitHub spiega che i segreti di un ambiente restano non disponibili a un job finché un revisore obbligatorio non lo approva.
Intorno al 19 ottobre, un'altra variante ha aggiunto un job rivolto ai runner self-hosted, cioè le macchine che le organizzazioni gestiscono per eseguire i job di Actions. Sembra prendere di mira i repository con un runner registrato e cerca di individuare 31 tipi di token e credenziali, tra cui chiavi private, ambienti di processo, credenziali del ruolo di istanza AWS, file di credenziali del runner e il token dell'account di servizio Kubernetes. Wiz ha descritto il job come difettoso e non ha segnalato esecuzioni riuscite.
Individuare e contenere l'esposizione
Wiz consiglia di controllare i log di audit di GitHub alla ricerca dello user agent gheist e delle esecuzioni su branch ci-sync-* eliminate entro un minuto dal completamento. Sui runner self-hosted, tra gli indicatori figurano .gdmp_pat, .gdmp_patg, .gdmp_sweep e il marcatore nei log dei job ===== gdmp-pivot:.
I log cloud offrono un'altra strada per il rilevamento quando i workflow usano OIDC, che fornisce credenziali a breve durata invece di chiavi cloud memorizzate. Le assunzioni di ruolo o gli scambi di token possono individuare un branch ci-sync- nel relativo subject. Esiste però un limite: il subject OIDC predefinito di GitHub include il nome del branch solo per i job che non usano un ambiente di deployment.
Rimuovere un branch o eliminare un'esecuzione non può annullare le credenziali già esposte. Wiz consiglia alle organizzazioni coinvolte di ruotare tutti i segreti accessibili a livello di repository, organizzazione e ambiente, revocare i token dietro i commit e verificare la presenza di infostealer sui dispositivi dei proprietari. Le esecuzioni sync-check trattenute devono restare non approvate, e il codice dei branch inseriti non va eseguito. Se uno di quei branch è stato eseguito su un runner self-hosted, Wiz raccomanda di considerare compromessi sia la macchina sia il suo ruolo di istanza cloud.
Per limitare gli accessi futuri, Wiz raccomanda revisori obbligatori per gli ambienti che contengono segreti di produzione, trust OIDC limitato a branch o ambienti protetti, e GitHub Apps o token fine-grained a breve durata al posto dei personal access token. Consiglia inoltre runner self-hosted a breve durata, senza accesso al socket Docker o accesso illimitato ai metadati cloud.
