4837 kompromittierte GitHub-Konten: Angreifer schleust Secret-Stealer in Tausende Repositories ein

Zwei unabhängige Sicherheitsteams, Aikido Security und SafeDep, haben eine massive Kampagne zum Diebstahl von Cloud- und Infrastruktur-Zugangsdaten über das GitHub-Ökosystem registriert. Laut Aikido nutzte der Angreifer die Zugangsdaten von 4837 gehackten Konten, um ein Schadskript in Repositories einzuschleusen, auf die diese Benutzer Schreibzugriff hatten. Das Skript wurde nach Einschätzung des Unternehmens in mindestens 1806 Repositories ausgeführt. Eine separate Analyse von SafeDep identifizierte 8093 Repositories, die im Zeitraum zwischen Dienstag, 12:46 Uhr UTC, und dem 12. November, 04:36 Uhr UTC, bösartige Änderungen erhielten. Wichtig ist, dass diese Zahl alle entdeckten Repositories mit schädlichen Commits berücksichtigt, nicht nur die, in denen das Skript tatsächlich ausgeführt wurde. Da sich die Überprüfung zudem nur auf die Hauptzweige öffentlicher Projekte beschränkte, könnte das tatsächliche Ausmaß des Vorfalls nach Einschätzung der Analysten noch größer sein.

Wie der Angriff begann: Ein Test-Pull-Request

Die Kampagne startete mit einer Auskundschaftungsphase: Der Angreifer sendete einen Test-Pull-Request mit dem Titel „docs: dependency audit notes“ von einem Branch namens wfx-docs, um zu prüfen, ob ein kompromittiertes Konto tatsächlich den Inhalt eines Repositorys ändern kann. Ähnliche Anfragen tauchten in 61 764 Projekten auf, woraufhin in einigen von ihnen ein Secret-Stealer hinzugefügt wurde. SafeDep entdeckte 7309 Fälle von Skript-Injektionen in bestehende GitHub-Actions-Workflows sowie 771 weitere Fälle, in denen sich der Schadcode über den npm-postinstall-Mechanismus verbreitete – eine automatische Codeausführung bei der Paketinstallation. Im letzteren Fall konnte das Skript nicht nur in der Cloud-Infrastruktur des Projekts, sondern auch direkt auf dem Computer des Entwicklers ausgeführt werden. Normalerweise machte der Angreifer die Änderungen nach der Injektion innerhalb weniger Minuten rückgängig, und die Ausführungsprotokolle wurden zusammen mit den Läufen selbst gelöscht, sodass das Fehlen sichtbarer Spuren nicht bedeutet, dass keine Daten gestohlen wurden.

Was das Skript exfiltrierte

Der Schadcode sammelte praktisch alle ihm zugänglichen Anmeldedaten: GitHub-Actions-Secrets, GITHUB_TOKEN-Token, temporäre OIDC- und Actions-Runtime-Token, KI-Dienstschlüssel sowie Daten aus AWS-, Azure-, Google-Cloud-, Kubernetes-, npm-, PyPI- und SSH-Konfigurationsdateien. Zusätzlich kopierte das Skript den Inhalt des Repositorys, die letzten 100 Commits und aktuelle Workflow-Artefakte. Auf selbst gehosteten Runnern (self-hosted runners) konnten weitere Cloud-Zugangsdaten aus Metadaten virtueller Maschinen, Informationen über Docker-Container und systemd-Konfigurationen erlangt werden. Die gestohlenen Informationen wurden per HTTP POST an entfernte Server oder via Telegram gesendet: Bei der Überprüfung von 200 schädlichen Commits wurde in etwa 20 % der Fälle ausschließlich Telegram genutzt.

Festsetzung in der Cloud-Infrastruktur

Besondere Gefahr ging von Mechanismen zur Festsetzung (Persistence) in der Cloud aus. Nach Erhalt von GitHub-OIDC-Token konnte der Angreifer diese gegen Zugriffssitzungen für AWS, Google Cloud und Azure eintauschen, dauerhafte AWS-Schlüssel erstellen und Vertrauensrichtlinien für Cloud-Rollen ändern. In Azure konnten sie föderierte Identitäten mit dem Präfix wfx-ci- hinzufügen, die es Workflows erlaubten, sich ohne gespeichertes Passwort zu autorisieren. Das Kernproblem besteht darin, dass solche Mechanismen auch nach Widerruf der ursprünglichen Token und Schlüsselrotation weiterfunktionieren konnten, was standardmäßige Reaktionsmaßnahmen ohne eine vollständige Prüfung der Vertrauensrichtlinien unzureichend macht.

Verbindung zum GhostAction-Angriff

Aikido stellte zudem eine Überschneidung mit dem im Oktober durchgeführten GhostAction-Angriff fest: Konten, die damals betroffen waren, waren etwa 1000-mal häufiger an der neuen Kampagne beteiligt. Das Unternehmen verbindet jedoch beide Angriffe bisher nicht mit demselben Angreifer, da unterschiedliche Tools und Infrastrukturen verwendet wurden. Für betroffene Unternehmen bedeutet dies die Notwendigkeit des sofortigen Widerrufs aller Token und Schlüssel, einer Prüfung der Vertrauensrichtlinien für Cloud-Rollen, einer Überprüfung der GitHub-Actions-Workflows und npm-Abhängigkeiten sowie der Überwachung auf anomale Autorisierungen, einschließlich föderierter Identitäten mit verdächtigen Präfixen.