Gheist-Kampagne stiehlt Geheimnisse aus privaten GitHub-Repos über Actions-Logs

Eine neue automatisierte Angriffskampagne mit dem Namen Gheist nutzt gestohlene GitHub-Tokens, um sensible Daten aus privaten Repositories zu extrahieren. Seit Mitte September haben Sicherheitsforscher bei Wiz beobachtet, wie Angreifer bösartige Workflows einschleusen, die Repository-Secrets direkt in die GitHub Actions Logs schreiben. Diese Angriffe zielen speziell auf private Repositories und Instanzen von GitHub Enterprise Server ab, wo bestehende automatische Schutzmaßnahmen weniger wirksam sind.

Was passiert ist

Die Gheist-Kampagne funktioniert so, dass kompromittierte Zugangsdaten verwendet werden, um neue Branches in den angegriffenen Repositories zu erstellen. Jeder Branch folgt einem spezifischen Namensschema, das mit ci-sync- beginnt, gefolgt von sechs zufälligen Zeichen. Die Angreifer committen eine einzelne Workflow-Datei in diese Branches, die so konzipiert ist, dass sie sofort beim Push ausgeführt wird. Dieser Workflow greift auf die Umgebungsvariablen und Secrets des Repositories zu, kodiert sie im Base32-Format und gibt sie dann auf der Standardausgabe (stdout) aus. Da die Daten kodiert sind, umgehen sie die automatische Secret-Masking-Funktion von GitHub, sodass die vollständigen Werte in den Build-Logs erscheinen.

Sobald der Workflow abgeschlossen ist, lädt das Tool des Angreifers die Logdatei über die GitHub API herunter und löscht anschließend den Workflow-Lauf sowie den Branch selbst. Diese schnelle Aufräumaktion erschwert die Erkennung, da die Beweise schnell verschwinden. Wiz berichtet, dass GitHub zwar einen Schutzmechanismus implementiert hat, der verdächtige Workflow-Läufe in öffentlichen Repositories pausiert, dieser Schutz jedoch derzeit nicht auf private Repositories oder selbst gehostete Installationen von GitHub Enterprise Server ausgeweitet wird. Folglich wurden alle Versuche in öffentlichen Repositories, die Wiz analysierte, blockiert, aber private und Enterprise-Umgebungen blieben anfällig für erfolgreiche Exfiltration.

Das Ausmaß der Kampagne ist erheblich. Wiz hat mehr als 13.500 eingeschleuste Branches über mehr als 850 kompromittierte Konten identifiziert. Diese Konten reichen von einzelnen Entwicklern bis hin zu großen Enterprise-Organisationen. In einigen Enterprise-Fällen wechselten die Angreifer innerhalb von Minuten zwischen mehreren Benutzer- und Automatisierungs-Tokens, klonen privaten Code und schleppten Workflows in mehrere Repositories ein. Die gestohlenen Tokens stammten oft von Infostealer-Malware oder früheren Supply-Chain-Kompromittierungen, wie etwa dem Vorfall im März, der den Trivy-Vulnerability-Scanner betraf.

Wichtige Details

• Die Kampagne verwendet den User-Agent-String gheist für alle API-Anfragen.
• Bösartige Branches werden nach dem Muster ci-sync- benannt, gefolgt von sechs alphanumerischen Kleinbuchstaben.
• Die committete Workflow-Datei ist immer .github/workflows/sync-check.yml mit der Commit-Nachricht ci: sync config.
• Secrets werden exfiltriert, indem sie im Base32-Format kodiert werden, um das Log-Masking von GitHub zu umgehen.
• Die automatische Anhaltung verdächtiger Läufe durch GitHub gilt derzeit nur für öffentliche Repositories auf github.com.
• Wiz hat seit dem 15. September über 13.500 eingeschleuste Branches von mehr als 850 kompromittierten Konten wiederhergestellt.

Hintergrund

GitHub Actions ermöglicht es Entwicklern, Software-Workflows zu automatisieren, wie z. B. das Erstellen und Testen von Code. Diese Workflows erfordern oft Zugriff auf sensible Informationen wie API-Schlüssel, Datenbank-Passwörter und Cloud-Zugangsdaten, die als Repository-Secrets gespeichert werden. Standardmäßig kann jeder Benutzer mit Schreibzugriff auf ein Repository diese Secrets lesen. Wenn ein Workflow ausgeführt wird, versucht GitHub, bekannte Secret-Werte in den Logs zu maskieren, um versehentliche Offenlegungen zu verhindern. Dieses Masking basiert jedoch auf exakter String-Übereinstimmung. Wenn ein Secret geändert wird, z. B. durch Kodierung im Base32-Format oder Aufteilung in Teile, erkennt GitHub es möglicherweise nicht und maskiert es nicht, sodass der Rohwert in den Logs sichtbar bleibt.

Die Unterscheidung zwischen dem Schutz öffentlicher und privater Repositories ist hier entscheidend. GitHub hat kürzlich eine Funktion eingeführt, die Workflow-Läufe aus unverifizierten Quellen in öffentlichen Repositories zur manuellen Genehmigung anhält. Dies wirkt als starke Barriere gegen automatisierten Missbrauch in Open-Source-Projekten. Diese Funktion ist jedoch noch nicht für private Repositories oder GitHub Enterprise Server verfügbar, die viele Unternehmen für interne proprietäre Software nutzen. Diese Lücke führt dazu, dass selbst gehostete und private Umgebungen auf andere Sicherheitsmaßnahmen angewiesen sind, wie strenge Token-Verwaltung und Audit-Logging, die sich in Echtzeit schwerer überwachen lassen.

Warum das wichtig ist

Für Teams, die ihre eigene Software betreiben oder private Codebasen verwalten, unterstreicht dieser Vorfall eine schwache Stelle in der CI/CD-Sicherheitskette. Die Annahme, dass Logs sicher sind, weil Secrets maskiert werden, ist nicht mehr gültig. Angreifer nutzen aktiv Kodierungstechniken, um diese Schutzmaßnahmen zu umgehen. Wenn Ihre Organisation GitHub Actions für Deployments verwendet, insbesondere mit selbst gehosteten Runnern oder privaten Repositories, sind Ihre Secrets gefährdet, wenn ein Token kompromittiert wird. Die Tatsache, dass Angreifer die Läufe sofort löschen, bedeutet, dass traditionelles Monitoring das Ereignis möglicherweise vollständig übersieht, es sei denn, Sie haben detaillierte Audit-Logs aktiviert und prüfen diese aktiv.

Darüber hinaus demonstriert die Kampagne den Kaskadeneffekt des Token-Diebstahls. Ein einzelnes gestohlenes Personal Access Token oder Automatisierungs-Credential kann zur Kompromittierung der gesamten Cloud-Infrastruktur einer Organisation führen. In den von Wiz analysierten Fällen nutzten Angreifer den initialen Zugriff, um AWS-Rollen über OIDC anzunehmen, was potenziell breitere Kontrolle über Cloud-Ressourcen ermöglichte. Für IT-Leiter und DevOps-Ingenieure bedeutet dies, dass die Sicherung der CI/CD-Pipeline nicht nur Code-Qualität betrifft, sondern auch den Schutz der Schlüssel zu Ihrer Produktionsumgebung. Das Fehlen automatischer Blockaden in privaten Repos legt die Last der Erkennung voll und ganz auf das interne Sicherheitsteam.

Was Sie tun können

• Durchsuchen Sie Ihre Repositories nach Branches, die dem Muster ci-sync- gefolgt von sechs Zeichen entsprechen, und löschen Sie diese, falls gefunden.
• Rotieren Sie alle Repository-, Organisations- und Umgebungs-Secrets sofort, wenn Sie einen Verdacht auf Token-Kompromittierung haben.
• Überprüfen Sie die GitHub-Audit-Logs auf Workflow-Läufe in ci-sync-* Branches, die innerhalb einer Minute nach Abschluss gelöscht wurden.
• Prüfen Sie die Protokolle Ihres Cloud-Anbieters, wie z. B. AWS CloudTrail, auf Rollenannahmen, die mit Subjekten aus ci-sync- Branches verknüpft sind.
• Widerrufen Sie alle Tokens, die mit kompromittierten Konten verbunden sind, und scannen Sie die Geräte der Besitzer nach Infostealer-Malware.
• Verlangen Sie die manuelle Genehmigung eines Reviewers für Deployments in Umgebungen, die Produktions-Secrets enthalten.