Massiver GitHub-CI-Angriff stiehlt Secrets aus Tausenden von Repositories

Ab Dienstag nutzte eine koordinierte Cyberattacke gestohlene Zugangsdaten von 4.837 GitHub-Konten, um Software-Supply-Chains zu infiltrieren. Die Angreifer pflanzten bösartigen Code ein, der darauf ausgelegt war, Secrets und Cloud-Zugangsdaten aus Continuous-Integration-(CI)-Workflows in mindestens 1.806 Repositories zu stehlen. Diese Kampagne unterstreicht die schwerwiegenden Risiken im Zusammenhang mit kompromittierten Entwickleridentitäten und automatisierten Build-Pipelines.

Was passiert ist

Der Angriff begann damit, dass der Angreifer Test-Pull-Requests mit dem Titel "docs: dependency audit notes" aus Branches namens "wfx-docs" eröffnete. Diese Tests wurden in 61.764 Repositories bereitgestellt, um Schreibzugriff zu verifizieren. In Repositories, denen Zugriff gewährt wurde, schob der Angreifer einen Secret-Stealer in die CI-Konfiguration. Laut Aikido Security war der Stealer darauf ausgelegt, Secrets, Cloud-Zugangsdaten und Runtime-Tokens zu ernten, die für die Workflow-Umgebung zugänglich waren. Forscher von SafeDep identifizierten 8.093 Repositories, die zwischen 12:46 UTC am Dienstag und 04:36 UTC am folgenden Tag bösartige Commits erhielten. Sie wiesen darauf hin, dass die tatsächliche Zahl wahrscheinlich höher ist, da ihre Analyse nur öffentliche Standard-Branches abdeckte.

Sobald der Stealer ausgeführt wurde, exfiltriert er Daten typischerweise per HTTP POST an bestimmte IP-Adressen oder über Telegram-Chats. Der Angreifer machte die Änderungen oft innerhalb weniger Minuten rückgängig und löschte die Protokolle der Workflow-Ausführungen, um Beweise zu verwischen. In vielen Fällen war der Schaden jedoch bereits angerichtet. Der Stealer zielte auf eine breite Palette von Zugangsdaten, darunter GitHub Actions Secrets, OIDC-Tokens sowie Schlüssel für AWS, Azure, GCP und Kubernetes. In einigen Fällen wurde die Malware über npm postinstall-Hooks eingeschleust, was bedeutet, dass jeder Entwickler, der "npm install" auf dem betroffenen Commit ausführte, potenziell seinen lokalen Rechner kompromittierte.

Wichtige Details

• Ausmaß: 4.837 GitHub-Konten wurden kompromittiert, wobei Test-Pull-Requests an 61.764 Repositories gesendet wurden.
• Auswirkung: Der Stealer lief in mindestens 1.806 Repositories, wobei bösartige Commits in über 8.093 Repositories gefunden wurden.
• Methode: Die Angriffe begannen mit Pull-Requests mit dem Titel "docs: dependency audit notes" aus "wfx-docs"-Branches.
• Persistenz: Die Malware erstellt Hintertüren in AWS und Azure, die eine Rotation der Zugangsdaten überleben, z. B. durch das Umschreiben von Trust Policies.
• Indikatoren: Achten Sie auf Branches wie "wfx-docs", "chore/[a-z0-9]{8}" oder Commit-Nachrichten wie "ci: refresh build cache".
• Betroffene Pakete: Bösartige Versionen wurden im Packagist-Paket digitalelvis/neuronai-studio v3.14.3 und mehreren Go-Modulen gefunden.

Hintergrund

Continuous-Integration-(CI)-Systeme wie GitHub Actions automatisieren den Prozess des Buildens, Testens und Bereitstellens von Code. Um zu funktionieren, benötigen diese Workflows oft Zugriff auf sensible Zugangsdaten, wie Schlüssel von Cloud-Anbietern oder Datenbankpasswörter. Diese Secrets werden in den Repository-Einstellungen gespeichert und während der Ausführung in die Runner-Umgebung injiziert. Wenn ein Angreifer Schreibzugriff auf ein Repository erhält, kann er die Workflow-Dateien so ändern, dass sie bösartige Schritte enthalten, die diese Secrets ausgeben oder an einen externen Server senden.

Dieser Angriff nutzt speziell OpenID Connect (OIDC)-Tokens, die es CI-Runnern ermöglichen, sich bei Cloud-Anbietern zu authentifizieren, ohne langfristige Secrets zu speichern. Durch das Stehlen dieser kurzlebigen Tokens kann der Angreifer neue Sitzungen bei den Cloud-Anbietern anfordern. Gefährlicher noch: Der Stealer enthält Logik zur Erstellung persistenter Hintertüren, wie das Hinzufügen von föderierten Identitätsnachweisen in Azure oder das Erstellen von langfristigen Access Keys in AWS. Dies stellt sicher, dass der Angreifer den Zugriff behält, auch nachdem die ursprünglich kompromittierten Tokens rotiert wurden.

Warum es wichtig ist

Für Teams, die eigene Software betreiben oder selbst gehostete Infrastruktur verwalten, unterstreicht dieser Vorfall die kritische Bedeutung der Absicherung von CI/CD-Pipelines. Viele Organisationen gehen davon aus, dass sie gegen solche Angriffe immun sind, weil ihr Code privat ist oder ihre Runner selbst gehostet werden. Der Stealer war jedoch darauf ausgelegt, private Repositories und selbst gehostete Runner zu targets, indem er Zugangsdaten aus Instance-Metadaten und Docker-Container-Zuständen extrahierte. Wenn Ihre CI-Pipeline weitreichende Berechtigungen hat, kann ein einzelner kompromittierter Commit zur vollständigen Übernahme eines Cloud-Kontos führen.

Die vom Angreifer verwendeten Persistenzmechanismen erschweren die Behebung. Das bloße Rotieren von Secrets reicht nicht aus, wenn der Angreifer Cloud-Identitätsrichtlinien geändert hat. Teams müssen ihre Cloud-Konfigurationen auf nicht autorisierte föderierte Zugangsdaten oder Änderungen an Trust Policies überprüfen. Darüber hinaus bedeutet die Nutzung von npm postinstall-Hooks, dass die Bedrohung über die CI-Umgebung hinaus auf Entwickler-Arbeitsstationen reicht. Jedes Teammitglied, das den bösartigen Code gezogen hat, könnte versehentlich Malware installiert haben, was eine breitere Incident-Response-Bemühung erfordert.

Was Sie tun können

• Repositories prüfen: Suchen Sie nach Branches namens "wfx-docs", "chore/[a-z0-9]{8}" oder Pull Requests mit dem Titel "docs: dependency audit notes".
• Zugangsdaten rotieren: Rotieren Sie sofort alle Secrets, Variablen und Tokens in betroffenen Repositories. Widerrufen Sie OAuth-App-Gewährungen und SSH-Schlüssel für kompromittierte Konten.
• Cloud-Logs prüfen: Achten Sie auf ungewöhnliche Aktivitäten in AWS CloudTrail, Azure Entra ID und GCP Logs, insbesondere auf "AssumeRoleWithWebIdentity" oder föderierte Zugangsdaten mit dem Präfix "wfx-ci-."
• Lokale Rechner inspizieren: Wenn Sie "npm install" auf einem potenziell betroffenen Commit ausgeführt haben, betrachten Sie Ihren Rechner als kompromittiert und rotieren Sie lokale Schlüssel.
• Bösartige Pakete blockieren: Pinnen Sie digitalelvis/neuronai-studio auf v3.14.2 oder früher und entfernen Sie betroffene Versionen von github.com/onuragtas/docker-env und github.com/vkuznet/gocurl.
• 2FA aktivieren: Stellen Sie sicher, dass die Zwei-Faktor-Authentifizierung für alle GitHub-Konten aktiviert ist, um Credential-Stuffing-Angriffe zu verhindern.