KIungefiltert

· 4 Min. Lesezeit · Read in English

Gheist: Gestohlene GitHub-Tokens leeren Secrets über Actions-Logs ab

Die Kampagne Gheist pflanzt mit gestohlenen GitHub-Tokens Workflows ein, die Secrets in Actions-Logs schreiben. Öffentliche Repos schützt GitHub inzwischen, private und Enterprise Server nicht.

Sicherheit

Eine laufende Kampagne namens Gheist missbraucht gestohlene GitHub-Tokens, um an die Secrets von Repositories zu kommen. Secrets sind hier die hinterlegten Zugangsdaten, mit denen Build- und Deploy-Pipelines arbeiten, etwa Cloud-Schlüssel oder API-Tokens. Entdeckt und benannt hat die Kampagne Wiz Research. Den Namen hat Wiz vom User-Agent gheist übernommen, den das Angriffswerkzeug bei Anfragen an die GitHub-API mitschickt. Berichtet haben unter anderem The Hacker News, Help Net Security und Dark Reading.

Was passiert

Das Werkzeug nimmt ein gestohlenes Token und schiebt in jedes Repository, auf das dieses Token Schreibzugriff hat, einen neuen Workflow. Ein Workflow ist eine Automatisierung in GitHub Actions, also GitHubs eingebautem CI/CD-System. Der eingeschleuste Workflow schreibt die Secrets, die der Job lesen kann, in sein eigenes Run-Log. Damit GitHubs Maskierung nicht greift, sind sie dabei kodiert. Das Werkzeug lädt das Log über die API herunter und löscht den Run wenige Sekunden später.

Der heikle Punkt: Die Daten verlassen GitHub über GitHub selbst. Es gibt keinen Angreifer-Server und keine ausgehende Verbindung, die eine Firewall blocken könnte. Eine Variante greift laut Wiz zusätzlich auf Secrets einzelner Deployment-Umgebungen zu, oft also auf Produktionszugänge. Seit etwa 19. Oktober gibt es außerdem eine Version, die auf selbst gehosteten Runnern nach Zugangsdaten sucht. Wiz nennt diese Variante fehlerhaft und hat keinen erfolgreichen Lauf gesehen.

Wie groß ist das?

Im Post hatte ich, gestützt auf Dark Reading, von Tausenden betroffenen Entwickler-Repos gesprochen. Die Zahlen von Wiz sind genauer: mehr als 13.500 eingeschleuste Branches aus über 850 kompromittierten Accounts, beobachtet seit dem 15. September. Wie viele Organisationen tatsächlich Secrets verloren haben, sagt Wiz nicht. Am 24. Oktober lief die Kampagne noch. Etwa zwei Drittel der Accounts waren da auf GitHub aber nicht mehr erreichbar.

Die Tokens stammen laut Wiz unter anderem aus Infostealer-Logs und aus früheren Lieferkettenangriffen, etwa der Kompromittierung des Scanners Trivy im März. Infostealer sind Schadprogramme, die Passwörter und Tokens von Entwicklerrechnern abgreifen. Eine Sicherheitslücke im eigentlichen Sinn steckt nicht dahinter, deshalb gibt es weder CVE noch Patch. Missbraucht wird ganz normaler Schreibzugriff.

Was sich seit dem Post geändert hat

Ein Detail gehört nachgereicht: Seit dem 28. Juli hält GitHub potenziell bösartige Workflow-Runs an, bis jemand mit Schreibrechten sie freigibt. Das gilt aber nur für öffentliche Repositories auf github.com. Jeder öffentliche Gheist-Run, den Wiz geprüft hat, hing in dieser Warteschleife fest. Der Wiz-Bericht trägt deshalb auch den Titel, dass der Angriff „stolpert“.

Bei privaten Repositories und bei GitHub Enterprise Server greift dieser Schutz nicht. Dort hat Wiz in Audit-Logs gesehen, wie die Runs durchliefen und gelöscht wurden. In einem Fall wurden Stunden später Cloud-Zugangsdaten derselben Organisation genutzt, um AWS Secrets Manager abzufragen. Woher genau diese Zugangsdaten stammten, lässt Wiz offen.

Wer betroffen ist

Betroffen ist jede Organisation, deren Mitglieder oder Automations-Accounts Tokens mit Schreibrechten besitzen, die irgendwo abgeflossen sein könnten. Besonders exponiert sind private Repos und selbst betriebene Enterprise-Server.

Was du tun solltest

Prüfen:

  • Nach Branches suchen, die mit ci-sync- beginnen und nur eine neue Workflow-Datei namens sync-check.yml mit der Commit-Nachricht „ci: sync config“ enthalten.
  • In den GitHub-Audit-Logs nach Runs auf solchen Branches suchen, die kurz nach dem Ende gelöscht wurden, und nach dem User-Agent gheist.
  • Wer OIDC nutzt, also kurzlebige Cloud-Anmeldungen direkt aus dem Workflow, sollte die Cloud-Audit-Logs nach Rollenübernahmen mit ci-sync- im Subject durchsuchen. Das funktioniert auch ohne GitHub-Logs.

Wenn ein Repo betroffen ist:

  • Alle Repository-, Organisations- und Umgebungs-Secrets rotieren, die das Repo nutzen konnte. Gelöschte Runs machen den Abfluss nicht rückgängig.
  • Die Tokens widerrufen, die die Commits gepusht haben, und die Rechner ihrer Besitzer auf Infostealer prüfen.
  • Lief so ein Branch auf einem selbst gehosteten Runner, die Maschine und ihre Cloud-Rolle als kompromittiert behandeln.
  • Angehaltene sync-check-Runs nicht freigeben.

Härten:

  • Für Umgebungen mit Produktions-Secrets Pflicht-Reviewer einrichten.
  • OIDC-Vertrauensrichtlinien auf geschützte Branches oder Umgebungen beschränken.
  • GitHub Apps oder kurzlebige, fein granulierte Tokens statt klassischer Personal Access Tokens verwenden.

Meine Einordnung: Gheist zeigt, dass ein Token mit Schreibrechten praktisch ein Schlüssel zu allen Secrets eines Repos ist. Die Sperre für öffentliche Repos ist gut, aber gerade die wertvollen Daten liegen meist in privaten Repos. Dort muss man sich selbst schützen.

Quellen