Code-Injektion: GitHub Actions für Passwörterraub missbraucht

Ein neuer Supply-Chain-Angriff manipuliert GitHub Actions über gefälschte Tags, um sensible CI/CD-Zugangsdaten an Stealer-Server zu übertragen.

Die Bedrohungslage im Bereich der Software-Lieferketten (Software Supply Chain) verschärft sich weiter. Sicherheitsforscher des IT-Sicherheitsunternehmens StepSecurity haben einen schwerwiegenden Angriff auf weit verbreitete GitHub Actions dokumentiert. Betroffen ist unter anderem das populäre Workflow-Werkzeug „actions-cool/issues-helper“. Angreifer haben hierbei bestehende Versions-Tags manipuliert, um Schadcode direkt in die CI/CD-Pipelines (Continuous Integration/Continuous Delivery) von Entwicklern einzuschleusen. Das primäre Ziel der Kampagne ist der Diebstahl von sensiblen Zugangsdaten und Cloud-Geheimnissen direkt aus der Laufzeitumgebung der betroffenen Entwickler-Server.

Manipulierte Imposter-Commits

Der Angriff nutzt eine hochentwickelte Methode aus, die in Entwicklerkreisen als „Imposter Commit“ bezeichnet wird. Laut Varun Sharma, Forscher bei StepSecurity, wurde jeder existierende Versions-Tag im betroffenen Repository so umgeleitet, dass er auf einen gefälschten Commit verweist. Dieser bösartige Commit taucht in der regulären, sichtbaren Commit-Historie des Original-Repositorys überhaupt nicht auf.

Bei einem Imposter-Commit befindet sich der Schadcode physisch in einer vom Angreifer kontrollierten Abspaltung (Fork) des Projekts. GitHub erlaubt es jedoch unter bestimmten Bedingungen, dass Commits aus Forks über ihre eindeutige Hash-ID auch im Kontext des Originalprojekts referenziert werden können. Da Entwickler ihre Workflows häufig auf veränderliche Tags wie @v1 oder @v2 anstatt auf feste Code-Hashes (SHAs) ausrichten, zog das System bei der nächsten automatischen Ausführung ohne Warnung den manipulierten Code. Durch diese Taktik umgehen die Angreifer die standardmäßigen Pull-Request-Überprüfungen (PR Reviews) und erlangen eine willkürliche Code-Ausführung auf den Systemen der Opfer.

Schadcode extrahiert Daten aus dem Worker-Prozess

Sobald eine kompromittierte GitHub Action auf einem sogenannten Runner, der virtuellen Maschine, die den CI/CD-Workflow ausführt, gestartet wird, initiiert der Schadcode eine präzise Angriffssequenz. Zunächst lädt das Skript die JavaScript-Laufzeitumgebung „Bun“ auf den Runner herunter, um eine effiziente Ausführung der Spionage-Skripte zu gewährleisten.

Im nächsten Schritt greift die Malware direkt auf den Arbeitsspeicher des Systems zu. Sie liest gezielt die Speicherbereiche des Prozesses mit dem Namen Runner.Worker aus. In diesem Prozess hält das GitHub-System während der Ausführung des Workflows sämtliche Umgebungsvariablen, API-Schlüssel, GitHub-Tokens und Secrets für Cloud-Dienste wie AWS, Azure oder Google Cloud bereit. Die extrahierten Geheimnisse werden im Anschluss über einen ausgehenden HTTPS-Aufruf an eine vom Angreifer kontrollierte Domäne übermittelt. Als primäres Ziel für die Datenexfiltration identifizierten die Forscher die Adresse t.m-kosche.com.

Verbindung zur globalen Mini-Shai-Hulud-Kampagne

Die Entdeckung der Exfiltrations-Domäne t.m-kosche.com stellt eine direkte Verbindung zu einer weiteren aktuellen Angriffswelle her. Genau diese Infrastruktur wurde am selben Tag bei einer massiven Kompromittierung des @antv-Ökosystems innerhalb der npm-Paketregistrierung beobachtet. Dort infizierte der als „Mini Shai-Hulud“ bekannte Wurm hunderte von Software-Bibliotheken.

Die Übereinstimmung der Command-and-Control-Infrastruktur (C2) deutet stark darauf hin, dass beide Angriffscluster von derselben Bedrohungsgruppe gesteuert werden. Die cyberkriminelle Vereinigung, die im Untergrund als „TeamPCP“ agiert, hatte zuvor den Quellcode ihres Spionagewerkzeugs Shai-Hulud offengelegt, was zu einer massiven Welle von Nachahmer-Angriffen über verschiedene Plattformen hinweg führte. Die Ausweitung der Angriffe von npm-Paketen auf GitHub Actions zeigt, dass die Täter systematisch die gesamte Pipeline der Softwareentwicklung ins Visier nehmen, um an wertvolle Cloud-Anmeldedaten von Unternehmen zu gelangen.

Ausweitung auf weitere Open-Source- und Enterprise-Projekte

Die Untersuchungen von StepSecurity legten offen, dass der Angriff nicht auf ein einzelnes Repository beschränkt blieb. Die Analysten stellten fest, dass auch 15 Tags einer zweiten weit verbreiteten GitHub Action namens „actions-cool/maintain-one-comment“ mit exakt derselben Schadfunktionalität kompromittiert wurden. Das Ausmaß des betroffenen Entwicklerkreises ist erheblich, da diese automatisierten Helfer-Werkzeuge in zahlreichen Open-Source- und Enterprise-Projekten fest integriert sind.

Als unmittelbare Reaktion auf die Sicherheitsmeldungen hat die Microsoft-Tochtergesellschaft GitHub den Zugriff auf die betroffenen Repositories vollständig gesperrt. Auf den entsprechenden Seiten wird derzeit ausgegeben, dass der Zugriff aufgrund eines „Verstoßes gegen die Nutzungsbedingungen von GitHub“ deaktiviert wurde. Genaue Details darüber, wie die Angreifer die administrative Kontrolle über die Tags der Original-Repositories erlangen konnten – ob durch kompromittierte Entwickler-Zugänge oder Token-Diebstahl –, wurden bislang weder von GitHub noch von den betroffenen Maintainern offiziell kommuniziert.

Schutzmaßnahmen für CI/CD-Pipelines

Sicherheitsrelevante Vorfälle dieser Art unterstreichen das fundamentale Risiko bei der Verwendung von veränderlichen Versions-Tags in der Softwareentwicklung. Da jeder Workflow, der die betroffenen Aktionen über eine Versionsnummer (z. B. uses: actions-cool/issues-helper@v3) referenziert, bei der nächsten Ausführung automatisch den Schadcode zieht, müssen Administratoren ihre Sicherheitsstrategie anpassen.

Ein wirksamer Schutz gegen Tag-Shifting und Imposter-Commits ist laut den Experten von StepSecurity ausschließlich durch das sogenannte „Pinning“ auf den vollständigen kryptografischen Commit-SHA möglich. Workflows, die eine Action explizit über den unveränderlichen 40-stelligen Commit-Hash aufrufen (z. B. uses: actions-cool/issues-helper@123456...), blieben von dem Angriff gänzlich unberührt, da dieser Hashwert im Nachgang von Angreifern physisch nicht manipuliert oder auf ein anderes Commit-Ziel umgeleitet werden kann. Unternehmen wird dringend empfohlen, bestehende CI/CD-Konfigurationen zu überprüfen und automatisierte Validierungswerkzeuge zu implementieren, die die Integrität externer Abhängigkeiten kontinuierlich überwachen.