Gheist stiehlt Repository-Geheimnisse über manipulierte GitHub-Actions-Workflows
Wiz beobachtet seit dem 15. September eine Kampagne, die gestohlene GitHub-Tokens nutzt, um manipulierte Workflows in Repositories einzuschleusen. Diese Workflows schreiben erreichbare Geheimnisse in GitHub-Actions-Logs, die anschließend heruntergeladen werden. Betroffen sind laut der Analyse nicht nur öffentliche Projekte, sondern auch private Repositories und GitHub-Enterprise-Umgebungen.
Der Angriff beginnt mit einem neuen Branch namens ci-sync- plus sechs zufälligen Zeichen. Darin liegt die Datei .github/workflows/sync-check.yml mit der Commit-Nachricht ci: sync config. Beim Start des Workflows werden die Umgebungsvariablen und die für den Job erreichbaren Secrets ausgegeben. Eine Base32-Kodierung erschwert dabei nicht nur die Auswertung, sondern kann auch die automatische Maskierung von GitHub umgehen. Das Löschen des Branches oder des Workflow-Laufs beseitigt die bereits erfolgte Offenlegung nicht.
Für öffentliche Repositories gibt es eine wichtige Einschränkung: GitHub hält verdächtige Workflow-Läufe seit dem 28. Juli zur Freigabe durch einen Schreibberechtigten zurück. Dieser Schutz gilt laut GitHub derzeit jedoch nur für öffentliche Repositories auf github.com; GitHub Enterprise Server ist nicht abgedeckt. Wiz zufolge blieb jeder von der Firma geprüfte öffentliche Gheist-Lauf auf diese Weise blockiert. Private Repositories und Enterprise-Installationen können die Workflows dagegen ausführen lassen.
Die Größenordnung ist erheblich, ohne dass sich daraus die Zahl tatsächlich offengelegter Organisationen ableiten lässt: Wiz hat mehr als 13.500 derartigen Branches aus über 850 kompromittierten Konten geborgen. In Unternehmensumgebungen wechselte das Werkzeug innerhalb weniger Minuten zwischen Tokens mehrerer Nutzer und Automatisierungskonten. Anschließend klonte es private Repositories und legte die schädlichen Workflows an. In einzelnen Fällen wurden später auch AWS-Rollen angenommen und AWS Secrets Manager aufgelistet.
Betreiber sollten ihre GitHub-Audit-Logs nach ci-sync-*-Branches, kurz nach Abschluss gelöschten Workflow-Läufen und dem User-Agent gheist durchsuchen. Ergänzend können Cloud-Audit-Logs Hinweise liefern, wenn OIDC-Anmeldungen eine ci-sync-Branch im Betreff enthalten. Auf selbst betriebenen Runnern nennt Wiz außerdem die Dateien .gdmp_pat, .gdmp_patg und .gdmp_sweep sowie die Zeichenfolge gdmp-pivot als Suchmerkmale.
Findet ein Unternehmen einen solchen Branch, empfiehlt Wiz, alle Repository-, Organisations- und Umgebungsgeheimnisse zu rotieren, die das Repository verwenden konnte. Die Tokens, mit denen die Commits erstellt wurden, sollten widerrufen werden. Lief ein betroffener Workflow auf einem selbst gehosteten Runner, ist laut der Empfehlung auch die Maschine einschließlich ihrer Cloud-Instanzrolle als kompromittiert zu behandeln. Verdächtige Läufe dürfen nicht freigegeben werden; Code aus ci-sync-Branches sollte nicht ausgeführt werden.
Als vorbeugende Maßnahmen nennt Wiz verpflichtende Freigaben für Umgebungen mit Produktionsgeheimnissen, auf geschützte Branches oder Umgebungen begrenzte OIDC-Vertrauensregeln sowie GitHub Apps oder kurzlebige, fein granularisierte Tokens anstelle persönlicher Zugriffstokens. Selbst gehostete Runner sollten kurzlebig betrieben werden und keinen Zugriff auf den Docker-Socket oder Cloud-Metadaten erhalten.