Gestohlene GitHub-Tokens haben laut dem Cloud-Security-Unternehmen Wiz eine automatisierte Kampagne ermöglicht, mit der Geheimnisse aus privaten Repositories und aus GitHub-Enterprise-Server-Umgebungen abgezogen werden. Die Operation mit dem Namen Gheist macht die Logs von GitHub Actions zu einem Sammelkanal: Bösartige Workflows schreiben verschlüsselte Zugangsdaten in die Logs, die die Angreifer abrufen, bevor sie die Läufe löschen.
Wiz hat mehr als 13.500 von Angreifern angelegte Branches identifiziert, die mit mehr als 850 kompromittierten Konten in Verbindung stehen und sowohl persönliche Projekte als auch Unternehmens-Repositories betreffen. Diese Zahlen beziehen sich auf Branches und Konten; die Ergebnisse lassen jedoch nicht erkennen, wie viele Organisationen offengelegte Geheimnisse hatten.
Die Forscher beobachten Gheist seit dem 15. September. Laut dem Bericht von The Hacker News zur Analyse von Wiz war die Kampagne am 24. Oktober noch aktiv und wurde weiterhin verändert. Der Name stammt von gheist, dem User-Agent, den das Tooling in GitHub-API-Anfragen mitschickt.
Wo die Workflows liefen
GitHub-Audit-Einträge belegen die Ausführung in privaten Repositories und auf GitHub Enterprise Server: Läufe auf den bösartigen Branches wurden abgeschlossen, danach löschten Anfragen mit dem User-Agent gheist sie. Die AWS-CloudTrail-Protokolle zeigten zudem, dass legitime Workflows der Organisationen von diesen Branches aus liefen und AWS-Rollen übernahmen. Das deutet darauf hin, dass Actions-Jobs ohne Genehmigung gelaufen sind.
Innerhalb von Unternehmensorganisationen wechselte das Tooling innerhalb weniger Minuten zwischen Tokens von Nutzern und Automatisierungskonten. Vor dem Einschleusen des bösartigen Workflows klonte es private Repositories. Cloud-Zugangsdaten derselben Organisation wurden anschließend, Stunden später, genutzt, um AWS Secrets Manager nach Einträgen zu durchsuchen. Wiz konnte weder die Herkunft dieser Zugangsdaten feststellen noch ermitteln, wer sie verwendet hat.
Bei öffentlichen Repositories sah das Ergebnis anders aus. Jeder öffentliche Gheist-Lauf, den Wiz untersuchte, blieb über alle beobachteten Tool-Versionen hinweg in der Warteschleife auf Genehmigung und hatte daher seine Payload nicht ausgeführt.
GitHub hat diese Zurückhaltung am 28. Juli für Workflows eingeführt, die es als potenziell bösartig einstuft. Ein Mitwirkender mit Schreibrechten muss einen markierten Lauf genehmigen. Die Schutzmaßnahme gilt nur für öffentliche Repositories auf github.com; private Repositories und GitHub Enterprise Server fallen nicht darunter. Ihr Schutz hängt außerdem davon ab, dass GitHub den Lauf als verdächtig markiert.
Vom Repository-Zugriff zu lesbaren Zugangsdaten
Gheist beginnt mit einem bereits gestohlenen Token, das Schreibzugriff auf ein Repository gewährt. Wiz führte einige Tokens auf Infostealer-Logs und frühere Supply-Chain-Kompromittierungen zurück, darunter die im März erfolgte Kompromittierung des Schwachstellenscanners Trivy.
Bei Repositories, die über ein Token erreichbar sind, schiebt das Tool einen unsignierten Commit unter dem Namen des Token-Inhabers hoch. Eindeutig erkennbar ist die Kombination aus einem Branch, der dem Muster ^ci-sync-[0-9a-z]{6}$ entspricht, der Commit-Nachricht ci: sync config und einer einzigen hinzugefügten Datei: .github/workflows/sync-check.yml.
Dieser Push startet einen Workflow, der die Umgebung des Jobs und die erreichbaren Geheimnisse mit Base32-Kodierung in die Logs schreibt. Die Dokumentation von GitHub warnt, dass das Maskieren von Geheimnissen bei transformierten Werten fehlschlagen kann. Laut Wiz umgeht die Base32-Darstellung die Maskierung, weil sie vom Originalgeheimnis abweicht. Eine veröffentlichte Erkennungszeichenfolge lautet toJSON(secrets) }}' | base32 -w 120.
Obwohl der Workflow einen leeren permissions-Block deklariert, schränkt dieser sein GITHUB_TOKEN ein, verhindert aber nicht das Lesen von Geheimnissen. Die Angreifer nutzen ihr gestohlenes Token, um die entstandenen Logs über die API von GitHub abzurufen, und löschen den Lauf dann Sekunden später. Die Sammlung erfolgt daher über GitHub selbst, ohne dass ein separates, von den Angreifern kontrolliertes Ziel nötig wäre.
Eine Variante plant außerdem für jede Deployment-Umgebung einen Job, der auf die auf diese Umgebungen beschränkten Geheimnisse zugreift; laut Wiz enthalten diese häufig Zugangsdaten für die Produktion. Erforderliche Prüfer können diesen Zugriff verhindern: Laut der Dokumentation von GitHub bleiben die Geheimnisse einer Umgebung für einen Job so lange nicht verfügbar, bis ein erforderlicher Prüfer ihn genehmigt.
Um den 19. Oktober herum fügte eine weitere Variante einen Job hinzu, der auf Self-hosted-Runner abzielt, also auf die Maschinen, die Organisationen betreiben, um Actions-Jobs auszuführen. Er scheint Repositories mit einem registrierten Runner anzusprechen und versucht, nach 31 Arten von Tokens und Zugangsdaten zu suchen, darunter private Schlüssel, Prozessumgebungen, Anmeldedaten von AWS-Instanzrollen, Credential-Dateien von Runnern und das Token des Kubernetes-Service-Accounts. Wiz bezeichnete den Job als fehlerhaft und meldete jedoch keinen erfolgreichen Lauf.
Exponierung finden und eindämmen
Wiz empfiehlt, die GitHub-Audit-Logs auf den User-Agent gheist und auf Läufe zu prüfen, die auf ci-sync-*-Branches basieren und innerhalb einer Minute nach Abschluss gelöscht wurden. Bei Self-hosted-Runnern gehören zu den Indikatoren .gdmp_pat, .gdmp_patg, .gdmp_sweep und die Markierung in den Job-Logs ===== gdmp-pivot:.
Cloud-Logs bieten eine weitere Möglichkeit zur Erkennung, wenn Workflows OIDC nutzen, das kurzlebige Zugangsdaten anstelle gespeicherter Cloud-Schlüssel bereitstellt. Rollenübernahmen oder Token-Austausche können in ihrem Subject einen ci-sync--Branch erkennen lassen. Es gibt eine Einschränkung: Das Standard-OIDC-Subject von GitHub enthält den Branch-Namen nur für Jobs, die keine Deployment-Umgebung verwenden.
Das Entfernen eines Branches oder das Löschen eines Laufs macht bereits offengelegte Zugangsdaten nicht rückgängig. Wiz rät betroffenen Repositories, alle erreichbaren Geheimnisse auf Repository-, Organisations- und Umgebungsebene zu rotieren, die Tokens hinter den Commits zu widerrufen und die Geräte ihrer Inhaber auf Infostealer zu untersuchen. Angehaltene sync-check-Läufe sollten nicht genehmigt werden, und Code aus den eingeschleusten Branches sollte nicht ausgeführt werden. Falls einer dieser Branches auf einem Self-hosted-Runner gelaufen ist, empfiehlt Wiz, sowohl die Maschine als auch deren Cloud-Instanzrolle als kompromittiert zu behandeln.
Um künftige Zugriffe einzuschränken, empfiehlt Wiz erforderliche Prüfer für Umgebungen mit Produktions-Geheimnissen, OIDC-Vertrauensstellungen, die auf geschützte Branches oder Umgebungen beschränkt sind, sowie GitHub Apps oder kurzlebige Fine-grained-Tokens anstelle persönlicher Zugriffstoken. Außerdem rät Wiz zu kurzlebigen Self-hosted-Runnern ohne Zugriff auf den Docker-Socket oder auf die Cloud-Metadaten ohne Einschränkungen.
