Die beliebten GitHub Actions actions-cool/issues-helper und actions-cool/maintain-one-comment sind durch einen Supply-Chain-Angriff kompromittiert worden: Sämtliche bestehenden Tags in den Repositories wurden auf bösartige Commits umgebogen, die Credentials aus CI/CD-Pipelines auslesen und an einen Server der Angreifer übertragen. Jeder GitHub-Actions-Workflow, der diese Actions versionsbasiert (per Tag) referenziert, lädt beim nächsten Lauf den schädlichen Code. Der einzige Schutz besteht darin, auf den vollständigen SHA-Hash eines nachweislich vertrauenswürdigen Commits zu pinnen.
Angriffsmechanismus: Imposter-Commits
Laut dem Forscher Varun Sharma von StepSecurity wurde der Angriff über die Technik der Imposter-Commits umgesetzt – eine Methode der Supply-Chain-Kompromittierung, bei der bösartiger Code eingeschleust wird, indem auf einen Commit oder Tag verwiesen wird, der nur in einem von den Angreifern kontrollierten Fork existiert, nicht jedoch im ursprünglichen vertrauenswürdigen Repository. Dieser Ansatz ermöglicht es, die üblichen Pull-Request-Prüfungen zu umgehen und beliebigen Code auszuführen.
Wie StepSecurity berichtet, wurde jeder bestehende Tag im Repository actions-cool/issues-helper so verschoben, dass er auf einen Imposter-Commit zeigt, der in der normalen Commit-Historie der Action nicht auftaucht. Das bedeutet, dass der bösartige Code bei einer Standardansicht der Repository-Historie unsichtbar bleibt.
Ausführungskette des bösartigen Codes
Beim Start in einer GitHub-Actions-Runner-Umgebung führt der bösartige Commit folgende Abfolge von Schritten aus:
- Lädt die JavaScript-Laufzeitumgebung Bun auf den Runner
- Liest den Speicher des Prozesses Runner.Worker aus, um Credentials zu extrahieren
- Führt eine ausgehende HTTPS-Anfrage an eine von den Angreifern kontrollierte Domain aus, um die gestohlenen Daten zu übertragen
Das Auslesen des Speichers des Runner.Worker-Prozesses ist ein besonders gefährlicher Vektor, da dieser Prozess Secrets, Zugriffstokens und andere Credentials enthält, die in der CI/CD-Pipeline verwendet werden. Eine Kompromittierung dieser Daten kann Angreifern Zugang zu Repositories, Cloud-Umgebungen und weiteren Ressourcen verschaffen, die mit den Workflows verknüpft sind.
Ausmaß der Kompromittierung
Nach Angaben der Forscher wurden neben actions-cool/issues-helper auch 15 Tags einer zweiten GitHub Action – actions-cool/maintain-one-comment – mit vergleichbarer Funktionalität kompromittiert. GitHub hat den Zugriff auf das Repository actions-cool/maintain-one-comment gesperrt und auf einen Verstoß gegen die Nutzungsbedingungen der Plattform verwiesen. Konkrete Gründe für diese Entscheidung werden nicht genannt.
Da nun alle Tags auf bösartige Commits zeigen, ist jeder Workflow gefährdet, der diese Actions versionsbasiert referenziert – etwa über Konstrukte wie actions-cool/issues-helper@v3 oder actions-cool/issues-helper@latest. Beim nächsten Lauf lädt ein solcher Workflow automatisch den bösartigen Code und führt ihn aus.
Indikatoren einer Kompromittierung
Die im Zuge der Analyse identifizierte Domain zur Datenexfiltration:
- t.m-kosche[.]com – Domain, an die die gestohlenen Credentials gesendet werden
Organisationen wird empfohlen, ihre Netzwerkprotokolle auf Verbindungen zu dieser Domain aus der CI/CD-Umgebung zu prüfen.
Bewertung der Auswirkungen
Dieser Angriff stellt für Organisationen, die die betroffenen GitHub Actions in ihren CI/CD-Pipelines einsetzen, ein hohes Gefährdungspotenzial dar. Die Kompromittierung von Runner-Credentials kann zu Kettenreaktionen führen: unbefugter Zugriff auf private Repositories, Cloud-Infrastrukturen, Container-Register und andere Ressourcen, deren Secrets über GitHub Actions gehandhabt werden.
Besonders verwundbar sind Open-Source-Projekte und Organisationen, die Abhängigkeiten nicht auf konkrete Commit-SHA-Hashes pinnen. Die weite Verbreitung von GitHub Actions als Automatisierungsplattform macht derartige Supply-Chain-Angriffe potenziell sehr weitreichend.
Empfehlungen zur Reaktion
- Beenden Sie umgehend die Nutzung von actions-cool/issues-helper und actions-cool/maintain-one-comment in allen Workflows
- Führen Sie einen Audit der Logs der CI/CD-Runner auf ausgehende Verbindungen zur Domain t.m-kosche[.]com durch
- Rotieren Sie alle Secrets, die in Workflows verfügbar waren, welche die kompromittierten Actions genutzt haben: GitHub-Tokens, API-Schlüssel, Credentials von Cloud-Providern
- Stellen Sie auf Pinning per vollständigem Commit-SHA um für alle Drittanbieter-GitHub-Actions anstelle von Verweisen über Tags oder Branches – dies ist der einzige verlässliche Schutz vor ähnlichen Angriffen
- Implementieren Sie ein Monitoring der Netzwerkaktivität der Runner, um ungewöhnliche ausgehende Verbindungen aus der CI/CD-Umgebung zu erkennen
Dieser Vorfall illustriert ein grundlegendes Problem im Vertrauensmodell von GitHub Actions: Mutable Tags garantieren keine Code-Integrität. Jede Organisation, die fremde GitHub Actions einsetzt, sollte ihre Workflows auditieren und sämtliche Referenzen auf externe Actions von Tags auf vollständige Commit-SHA-Hashes umstellen. Für bereits betroffene Umgebungen hat die sofortige Rotation aller Secrets, die den kompromittierten Runnern zugänglich gewesen sein könnten, oberste Priorität.
