Ein einziges gestohlenes Entwicklerkonto kann den Zugang zu Dutzenden von Repositorys eröffnen. Offenbar haben Hacker einen Weg gefunden, diesen Zugriff in einen Supply-Chain-Angriff größeren Ausmaßes zu verwandeln.
An der von Sicherheitsforschern von Aikido als wfx-loot bezeichneten Kampagne waren 4.837 kompromittierte GitHub-Konten beteiligt; sie erreichte 61.764 Repositorys. Die Angreifer nutzten gestohlene Zugangsdaten, um die Repository-Berechtigungen zu prüfen und schädliche GitHub-Actions-Workflows einzuschleusen, die weitere Geheimnisse stehlen sollten.
Aikido-Forscher sagen, dass die Malware sensible Informationen sammelt, darunter GitHub-Zugriffstoken und Cloud-Zugangsdaten sowie API-Schlüssel für KI-Dienste. Ihre Fähigkeiten erstreckten sich außerdem auf Persistenz, wodurch die Möglichkeit besteht, dass eine kompromittierte Entwicklungspipeline zu einem längerfristigen Zugangspunkt zur Infrastruktur eines Unternehmens werden könnte.
Wie gestohlene Token den Zugriff auf Tausende von Repositorys ermöglichten
Die Angreifer mussten nicht jedes Repository einzeln kompromittieren. Stattdessen nutzten sie gestohlene GitHub-Zugangsdaten von Entwicklern, die bereits Zugriff auf mehrere Projekte hatten.
Ein Entwickler könnte zu mehreren Open-Source-Repositorys beitragen und gleichzeitig Berechtigungen innerhalb der GitHub-Organisation seines Arbeitgebers besitzen. Erlangen Angreifer die Zugangsdaten dieses Entwicklers, können sie möglicherweise auf mehrere Projekte zugreifen, ohne in jedem einzelnen eine separate Schwachstelle ausnutzen zu müssen.
Laut Aikido umfasste die Kampagne verdächtige Pull Requests mit dem Titel docs: dependency audit notes, die Forscher mit den Bemühungen der Angreifer in Verbindung brachten, potenzielle Ziele zu identifizieren. Die früheste von Aikido gemeldete Aktivität wurde am 10. November um 12:45 UTC registriert.
Die Reichweite der Kampagne war beträchtlich, doch die gemeldeten Zahlen beschreiben unterschiedliche Phasen des Angriffs. Aikido identifizierte Aktivitäten im Zusammenhang mit 61.764 Repositorys, während SafeDep separat meldete 8.093 Repositorys, die schädliche Commits erhielten.
Forscher konnten bislang nicht feststellen, wie die Angreifer ursprünglich an die kompromittierten Zugangsdaten gelangten. Phishing, Infostealer-Malware, offengelegte Token und Integrationen von Drittanbietern sind mögliche Erklärungen, doch keine davon sollte als bestätigt gelten.
So erkennen Sie, ob Sie betroffen waren
Aikido empfiehlt Entwicklern und Unternehmen, jedes GitHub-Repository zu überprüfen, in das sie schreiben können, einschließlich der Repositorys, auf die sie über die Berechtigungen von Mitarbeitern oder Organisationen zugreifen. Überprüfen Sie die Aktivitäten ab dem 10. November anhand dieser Indikatoren:
- Pull Requests: docs: dependency audit notes
- Branches: wfx-docs, chore/[8 random characters] und ci-check-[4 digits]
- Commit-Nachrichten: ci: refresh build cache, ci: restore, chore: add ci helper, ci: cleanup und chore: add dependency audit workflow.
- Sie können nach einem Stealer-Skript suchen mit diesem Hash: 89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cf
Schon das Auffinden des Probe-Pull-Requests rechtfertigt Maßnahmen, selbst wenn nichts anderes ausgeführt wurde.
Wenn Malware ausgeführt wurde, sollten Sie davon ausgehen, dass zugängliche Geheimnisse und Cloud-Zugangsdaten offengelegt wurden. Widerrufen und erneuern Sie betroffene Token und API-Schlüssel, überprüfen Sie Cloud-IAM-Richtlinien und Konfigurationen föderierter Identitäten und untersuchen Sie selbst gehostete Runner sowie Entwicklergeräte, auf denen möglicherweise schädliche npm-Skripte ausgeführt wurden.
Aikido empfiehlt bestehenden Nutzern außerdem, den Aikido-Sicherheitsfeed zu prüfen, nach Malware-Problemen zu filtern und einen manuellen erneuten Scan zu starten. Nutzer ohne Aikido-Konto können ihre Repositorys über den kostenlosen Tarif anbinden, der Malware-Erkennung umfasst.
Das eigentliche Sicherheitsproblem ist hier der Zugriff
Seit Beginn der Cyberangriffe ist eines gleich geblieben: Angreifer brauchen Zugriff – und sie haben zahlreiche Wege gefunden, ihn zu erlangen.
Phishing, Infostealer-Malware und offengelegte Zugangsdaten sind nur einige der Methoden, die sie einsetzen. Wir wissen noch immer nicht, wie die Angreifer hinter wfx-loot an die GitHub-Token gelangten, doch diese Wege bleiben möglich. Kompromittierte Repositoryssind in der Cybersicherheit ebenfalls keineswegs neu.
Diese Ungewissheit ist eine nützliche Erinnerung für Unternehmen, die auf Entwickler angewiesen sind: Entwickler sind bevorzugte Ziele, weil ihre Konten weit mehr als nur den Zugang zu Quellcode eröffnen können.
Unternehmen sollten Entwicklerkonten und CI/CD-Workflows als besonders wertvolle Sicherheitsressourcen behandeln. Starke Authentifizierung, Berechtigungen nach dem Prinzip der geringsten Privilegien, regelmäßige Zugriffsüberprüfungen und striktere Kontrollen für Workflow-Geheimnisse können helfen, den Schaden durch gestohlene Zugangsdaten zu begrenzen.
Sicherheitsteams sollten außerdem ungewöhnliche Änderungen an Repositorys, unerwartete Anpassungen an Workflows und die verdächtige Verwendung von Zugriffstoken überwachen. Wo möglich, können kurzlebige Zugangsdaten und eng begrenzte Berechtigungen den Umfang des Zugriffs eines Angreifers reduzieren.
Die Lehre aus wfx-loot lautet nicht einfach, dass Entwicklerzugangsdaten gestohlen werden können. Entscheidend ist vielmehr, wie viel Schaden diese Zugangsdaten ermöglichen, wenn ein einziges Konto Zugriff auf ein ganzes Netzwerk von Repositorys und automatisierten Systemen hat.
Forscher von Cornell Tech und der Yale University stellten fest, dass KI-Agenten Ausgabenlimits für Kryptowährungen umgehen konnten, indem sie E-Mail-Bestätigungscodes abriefen. Neun von zehn getesteten Modellen erhöhten ihre eigenen Limits ohne separate menschliche Genehmigung und legten damit Schwächen in automatisierten Zahlungsschutzmechanismen offen.