Gestohlene Zugangsdaten für 4.837 GitHub-Konten ermöglichten es einem Angreifer, Schadsoftware auszubringen, die auf Repository-Geheimnisse und Cloud-Zugriffe abzielt, wie Aikido Security am 12. November in von The Hacker News berichteten Erkenntnissen mitteilte. Die Kampagne begann am Dienstag, dem 10. November, und die Schadsoftware wurde in mindestens 1.806 Repositories ausgeführt, wo Aikido vermutet, dass Zugangsdaten wahrscheinlich gestohlen wurden.
Eigentümer von Repositories, Organisationsadministratoren und Entwickler, die betroffenen Code installiert haben, sind unterschiedlich gefährdet. Aikido betrachtet jedes Konto, das für die Test-Pull-Requests des Angreifers genutzt wurde, als kompromittiert, unabhängig davon, ob anschließend Schadsoftware lief. Wo es zur Ausführung kam, sollten alle Geheimnisse und Cloud-Rollen, auf die die automatisierten Workflows zugreifen können, als kompromittiert gelten.
Schreibzugriffsprüfungen erreichten 61.764 Repositories
Der Angreifer prüfte die Repository-Berechtigungen jedes Kontos, indem er einen Pull Request – also einen vorgeschlagenen Code-Änderungsvorschlag – mit dem Titel docs: dependency audit notes aus einem wfx-docs-Branch einreichte. Aikido verzeichnete diese Prüfungen in 61.764 Repositories. Auf Mitarbeiter- oder Organisationsberechtigungen entfielen 10.431 Test-Pull-Requests, wodurch sich die Kampagne über Repositories hinaus ausweitete, die den gestohlenen Konten gehörten. 92 % dieser Anfragen waren bei der Prüfung noch offen.
Die meisten geprüften Repositories erhielten entweder keine weitere Nutzlast oder hatten Einstellungen beziehungsweise Kontoberechtigungen, die die Ausführung verhinderten. Aikidos Einblick beschränkte sich auf öffentliche Repositories, obwohl die Einstellungen in der Schadsoftware darauf hindeuteten, dass sie auch in privaten Repositories aktiv sein könnte.
SafeDep, ein Unternehmen für die Sicherheit von Software-Lieferketten, identifizierte getrennt davon schädliche Commits in 8.093 Repositories zwischen 12:46 UTC am 10. November und 04:36 UTC am 12. November. Damit wird die Zustellung gemessen, nicht die Ausführung. Die Suche umfasste nur die Standard-Branches öffentlicher Repositories, weshalb die Forscher die Gesamtzahl für höher einschätzen.
Bestehende Workflows der kontinuierlichen Integration (CI) – automatisierte Aufgaben, die Code bauen und prüfen – erhielten die Nutzlast in 7.309 Repositories. Weitere 771 erhielten sie über einen npm-Postinstall-Hook, ein Skript, das durch npm install ausgelöst wird und auch auf dem Rechner eines Entwicklers ausgeführt werden kann.
Die Aktivität ging über Aikidos Suche hinaus, die am Mittwoch endete. The Hacker News prüfte drei weitere Pull Requests, die zwischen 05:04 und 05:38 UTC am 12. November geöffnet wurden: Jeder verwendete denselben Titel und einen wfx-docs-Branch, doch ob anschließend Schadsoftware ausgeliefert wurde, war unklar.
Was die Schadsoftware abgreifen und behalten kann
Aikido beschrieb einen Stealer, der den Runner – die Maschine, auf der ein Workflow läuft – nach Zugangsdaten durchsucht. Zu seinen Zielen gehören GitHub-Actions-Geheimnisse und -Variablen, GITHUB_TOKEN, Laufzeit-Tokens von Actions, Schlüssel für KI-Dienste und Geheimnisse, die im Prozessspeicher gehalten werden. Außerdem liest er Zugangsdatendateien, die AWS, Azure, GCP, Kubernetes, npm, PyPI, SSH und andere Werkzeuge verwenden.
Die Sammlung erstreckt sich auf Repository-Inhalte, die letzten 100 Commits und aktuelle Workflow-Artefakte, also gespeicherte Job-Ausgaben. Auf selbst gehosteten Runnern zielt die Schadsoftware zusätzlich auf Cloud-Zugangsdaten ab, die über Instanz-Metadaten, den Zustand von Docker-Containern und systemd-Units offengelegt werden. Letztere definieren Systemdienste.
SafeDep fand zwei Wege, um gestohlenes Material abzuleiten: HTTP-POST-Anfragen an Server des Angreifers und Nachrichten an einen Telegram-Chat. Rund ein Fünftel der 200 untersuchten Nutzlast-Commits stützte sich ausschließlich auf Telegram.
Der Cloud-Zugriff kann selbst nach dem Austausch der ursprünglichen Geheimnisse fortbestehen. Die Schadsoftware kann GitHub-OpenID-Connect-(OIDC)-Tokens – Identitätsnachweise, mit denen Workflows Cloud-Zugriff anfordern – gegen Sitzungen in AWS, GCP und Azure tauschen. Zu ihren AWS-Fähigkeiten gehört das Anlegen langlebiger Zugriffsschlüssel für Benutzer von Identity and Access Management sowie das Ändern der Vertrauensrichtlinie einer Rolle, sodass jedes AWS-Konto zugelassen wird.
Bei Azure-AD-Anwendungen kann sie föderierte Identitätsnachweise anlegen, deren Name mit wfx-ci- beginnt. Diese begründen eine vertrauenswürdige Anmeldebeziehung, die es Workflows im kompromittierten Repository erlaubt, sich ohne gespeichertes Geheimnis zu authentifizieren, selbst nach einer Token-Rotation.
Aikido fand außerdem eine Verbindung zur GhostAction-Kampagne vom Oktober, die gestohlene GitHub-Konten nutzte, um Workflows einzuschleusen, die Geheimnisse stehlen. Damals betroffene Konten waren etwa 1.000-mal wahrscheinlicher als andere aktive Konten, in der Aktivität im November aufzutauchen. In mehr als 100 Repositories gelangte die neueste Nutzlast in die Workflow-Dateien vom Oktober, ohne deren bestehenden Datendiebstahl-Schritt zu entfernen. Aikido ordnete die Kampagne nicht demselben Akteur zu, da Infrastruktur, Werkzeuge und Methoden abwichen, und gestohlene Zugangsdaten können unter mehreren Angreifern kursieren.
Paketrisiko hängt davon ab, wie Code genutzt wird
Automatisch ausgelöste Veröffentlichungen brachten die Schadsoftware in mindestens ein Packagist-Paket und ein Go-Modul. Mindestens 50 kompromittierte Nutzer scheinen über npm, Go, Packagist, PyPI oder crates zu veröffentlichen, wobei Aikido das Erlangen von CI-Geheimnissen als offenbares Ziel des Angreifers einstufte.
Die schädliche Packagist-Version ist digitalelvis/neuronai-studio in Version 3.14.3. Im Eintrag war der 11. November als Veröffentlichungsdatum angegeben. Am frühen Morgen des 12. November war sie noch verfügbar, versehen mit einem Hinweis, dass Paketversionen als Schadsoftware markiert worden waren. Aikido empfiehlt, Rechner, auf denen sie installiert oder geöffnet wurde, als kompromittiert zu behandeln. Ob ausgeführt wird, hängt vom Befehl ab: Ein gewöhnliches composer install startet den Stealer nicht, ein npm install im vendor-Verzeichnis des Pakets hingegen schon. Nutzer sollten v3.14.3 sperren und auf v3.14.2 oder früher festlegen.
Bei github.com/onuragtas/docker-env enthalten die Versionen v1.0.278 und v1.0.280 die Nutzlast ausschließlich in einem GitHub-Actions-Workflow. Weder der Go-Code noch die Release-Binärdateien wurden verändert, und Go-Builds führen keine Workflow-Dateien aus. Modulnutzer sind daher womöglich nicht betroffen. Aikido empfiehlt trotzdem, beide Versionen zu entfernen.
Forscher identifizierten außerdem einen schädlichen Workflow in der Pseudoversion v0.0.0-20261111095532-8d5aad0cb0da von github.com/vkuznet/gocurl. Dieser Workflow wurde nie ausgeführt; Nutzer sollten die Pseudoversion dennoch sperren.
Commits, die wdio-bot zugeschrieben werden, brachten den Stealer in 28 WebdriverIO-Repositories. Paketveröffentlichungen waren nicht betroffen, doch das Token des Bots sollte als gestohlen gelten.
Änderungen finden, dann Zugriffe widerrufen
Eigentümer von Repositories sollten die Aktivität ab dem 10. November in jedem Repository prüfen, in das sie schreiben können. Der Angreifer machte schädliche Änderungen in der Regel innerhalb weniger Minuten rückgängig und löschte Ausführungsprotokolle; meist entfernte er auch den Workflow-Lauf. Eine saubere aktuelle Datei klärt daher nicht, ob Zugangsdaten offengelegt wurden.
Suchen Sie nach Branches namens wfx-docs, kurzlebigen Branches, die chore/[a-z0-9]{8} entsprechen, und Branches, die ci-check-[0-9]{4} entsprechen. Neben dem Pull-Request-Titel docs: dependency audit notes weisen folgende Commit-Nachrichten auf relevante Änderungen hin:
ci: refresh build cache: etwa 1.500 Zeilen wurden in einen bestehenden Workflow eingefügt.chore: add ci helper: ein Skript.ci-xxxxxx.shzusammen mit einem Postinstall-Hook inpackage.json, ausgelöst durch jedesnpm install.chore: add dependency audit workflow: eine neue Datei.github/workflows/build-audit-xxxxxx.ymlauf einemchore/-Branch.chore: initial commit: ein Commit, der in einem leeren Repository dem Hinzufügen einer Workflow-Datei vorausging.ci: restoreundci: cleanup.
Der SHA-256-Fingerabdruck des Stealer-Skripts lautet 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf. Netzwerkindikatoren sind 194.150.166[.]244:8080/exfil, 18.143.168[.]96:8080/exfil und 153.75.82[.]159:8080.
Fehlende wfx-loot-Artefakte, wfx--Cache-Einträge oder WFX-BEGIN-Schrittzusammenfassungen schließen einen Diebstahl nicht aus. Die Forscher beschrieben eine Lücke in der Lauf-Nummerierung des Angreifer-Commits als verlässlicheres Indiz für eine Ausführung.
Cloud-Administratoren sollten außerdem nach den Persistenzmechanismen suchen, die die Forscher identifiziert haben:
- Entra ID: unbekannte föderierte Anmeldedaten mit dem Namen
wfx-ci-*. - AWS CloudTrail: Sitzungen
AssumeRoleWithWebIdentityoderAssumeRolemit dem Namenwfx-*, gefolgt vonCreateAccessKeyoderUpdateAssumeRolePolicy. - GCP: Aufrufe von
GenerateAccessTokenundSignJwt, die aus dem GitHub-Workload-Identity-Pool stammen, der Workflow-Identitäten für Cloud-Zugriffe bereitstellt. - Vault: Anmeldungen mit JSON Web Token (JWT) über den GitHub-OIDC-Aussteller.
SafeDep rät Eigentümern betroffener Repositories, Tokens, OAuth-Anwendungsberechtigungen, SSH-Schlüssel und Sitzungen des Commit-Autors zu widerrufen, die Zwei-Faktor-Authentifizierung zu aktivieren und jedes Geheimnis und jede Variable, die das Repository auslesen kann, zu rotieren. Entwickler, die npm install gegen einen betroffenen Commit ausgeführt haben, sollten ihren Rechner als kompromittiert betrachten und dessen Schlüssel rotieren.
