Megalodon-Angriff trifft 5.561 GitHub-Repositories in sechs Stunden
Ein GitHub-CI/CD-Lieferkettenangriff namens Megalodon hat einen neuen Maßstab für automatisierte, großflächige Repository-Kompromittierung gesetzt. In einem einzigen Sechs-Stunden-Fenster schufen Angreifer 5.718 bösartige Code-Updates in 5.561 GitHub-Repositories, nutzten dabei gefälschte Identitäten, um Workflow-Dateien einzuschleusen, die darauf ausgelegt waren, Cloud-Zugangsdaten, SSH-Schlüssel und Quellcode-Geheimnisse stillschweigend abzugreifen. Die schiere Geschwindigkeit und das Ausmaß der Kampagne signalisieren eine Verlagerung hin zu industrialisierten Pipeline-Angriffen, die die Erkennungs- und Reaktionsfähigkeit der meisten Teams in Echtzeit übersteigen.
Wie der Megalodon-Angriff funktionierte: Gefälschte Identitäten und automatisierte Workflow-Injektion
Die Angreifer hinter Megalodon setzten weder auf Zero-Day-Exploits noch auf ausgefeilte Malware, die auf Endgeräten eingesetzt wird. Stattdessen nutzten sie das Vertrauen aus, das GitHubs eigener CI/CD-Infrastruktur entgegengebracht wird. Durch die Erstellung gefälschter Contributor-Identitäten reichten sie Pull Requests ein oder modifizierten Workflow-Konfigurationsdateien direkt – konkret die YAML-Dateien, die GitHub Actions zur Definition automatisierter Build- und Deployment-Pipelines verwendet.
Sobald eine bösartige Workflow-Datei in einem Repository landet, wird sie automatisch ausgeführt, sobald die Pipeline ausgelöst wird – typischerweise bei Push-Ereignissen oder dem Zusammenführen von Pull Requests. Diese Ausführung findet innerhalb der eigenen Runner-Umgebung von GitHub statt, die häufig Zugriff auf Repository-Geheimnisse, Umgebungsvariablen und auf Cloud-Anbieter beschränkte Tokens hat. Die Megalodon-Workflows nutzten dieses Zugriffsfenster, um Daten nach außen zu exfiltrieren – vermutlich an von Angreifern kontrollierte Infrastruktur – bevor ein Repository-Betreuer Anlass hatte, die Änderung zu überprüfen.
Das definierende Merkmal der Kampagne ist ihre Automatisierung. Nahezu 5.720 separate Code-Pushes über mehr als 5.500 Repositories in sechs Stunden durchzuführen ist kein manueller Aufwand. Dafür sind skriptgesteuerte Werkzeuge erforderlich, die Ziele identifizieren, sich mit gefälschten Identitäten authentifizieren, plausibel wirkende Workflow-Änderungen erstellen und diese parallel einreichen können. Dieses Automatisierungsniveau bedeutet, dass sich die Angriffsfläche schneller ausweitete, als ein menschliches Überwachungsteam hätte nachverfolgen können.
Welche Zugangsdaten gestohlen wurden und warum das für Entwickler wichtig ist
Die Nutzlast jedes bösartigen Workflows war das Abgreifen von Zugangsdaten. Zu den Zielen gehörten Cloud-Anbieter-Zugangsdaten – am häufigsten AWS-, GCP- und Azure-Zugriffsschlüssel, die als GitHub Secrets gespeichert oder in Workflow-Umgebungsvariablen referenziert wurden. Ebenfalls im Visier waren private SSH-Schlüssel für den Serverzugang oder die diensteübergreifende Authentifizierung sowie sämtliche im Quellcode oder in Konfigurationsdateien eingebetteten Klartextgeheimnisse.
Diese Arten von Zugangsdaten tragen ein kaskadierendes Risiko in sich. Ein gestohlener AWS-Zugriffsschlüssel, der an eine IAM-Rolle mit weitreichenden Berechtigungen gebunden ist, kann einem Angreifer ermöglichen, innerhalb von Minuten Infrastruktur bereitzustellen, Datenspeicher zu exfiltrieren oder sich seitlich in verbundene Dienste vorzubewegen. SSH-Schlüssel können dauerhaften Zugang zu Produktionsservern ermöglichen, lange nachdem der ursprüngliche Einbruch entdeckt und das GitHub-Repository bereinigt wurde. Der Wert dieser Daten reicht weit über die Repositories selbst hinaus.
Dies ist kein hypothetisches Risikomuster. Anfang dieses Jahres legte ein CISA-Auftragnehmer AWS-Schlüssel und Klartextpasswörter in einem öffentlichen GitHub-Repository offen, was zeigt, dass Credential-Missmanagement in Entwicklungsumgebungen selbst Organisationen mit dezidierten Sicherheitsmandaten betrifft. Megalodon hat lediglich denselben Angriffspfad industrialisiert, den individuelle menschliche Fehler bereits wiederholt demonstriert haben.
Es ist auch erwähnenswert, dass Werkzeuge und Pipelines zum Diebstahl von Zugangsdaten selbst Angriffsziele sind. Der jüngste Bitwarden-CLI-Lieferkettenangriff zeigte, dass selbst die Werkzeuge, die Entwickler zur Verwaltung von Geheimnissen nutzen, vorgelagert kompromittiert werden können – was bedeutet, dass sich die Vertrauenskette über jedes einzelne Repository oder jede Pipeline-Konfiguration hinaus erstreckt.
Defense-in-Depth für Entwicklungsteams: Secrets-Management, verschlüsselte Kommunikation und Zugriffskontrollen
Megalodon nutzte mehrere Schwachstellen aus, die sowohl in Open-Source- als auch in privaten Repositories weit verbreitet sind. Ihre Behebung erfordert einen mehrschichtigen Ansatz statt einer einzigen Maßnahme.
Erstens sollten Geheimnisse niemals als Klartext in Workflow-Dateien, Umgebungskonfigurationsdateien oder Quellcode gespeichert werden. GitHubs verschlüsseltes Secrets-Feature bietet eine Grundlage, aber diese Geheimnisse sollten auch dem Prinzip der minimalen Rechtevergabe folgen. Ein Workflow, der in einer Staging-Umgebung deployed, benötigt keine Produktionsdatenbankzugangsdaten. Eine enge Eingrenzung von Geheimnissen begrenzt den Schaden, wenn ein Workflow kompromittiert wird.
Zweitens schaffen Branch-Protection-Regeln und erforderliche Reviewer für Workflow-Dateiänderungen einen menschlichen Kontrollpunkt, den automatisierte Angriffe umgehen müssen. Das Erfordern mindestens einer genehmigten Überprüfung vor jeder Änderung an .github/workflows/-Dateien kann die Art der schnellen automatisierten Injektion, auf die Megalodon angewiesen war, verlangsamen oder blockieren.
Drittens verhindert das Verankern von Drittanbieter-GitHub-Actions an spezifische Commit-SHAs statt an fließende Tags einen separaten, aber verwandten Angriffsvektor, bei dem kompromittierte Action-Publisher einen Tag stillschweigend aktualisieren, um auf bösartigen Code zu verweisen. Dies war der Mechanismus bei mehreren jüngsten GitHub-Actions-Lieferkettenangriffen.
Schließlich können Audit-Logging und Anomalieerkennung bei Workflow-Ausführungen unerwartete ausgehende Netzwerkverbindungen oder ungewöhnliche Muster beim Zugriff auf Geheimnisse aufdecken. GitHubs Audit-Log-API und Drittanbieter-CI/CD-Sicherheitswerkzeuge können helfen, diese Signale sichtbar zu machen.
So überprüfen Sie jetzt Ihre GitHub-Repositories und CI/CD-Pipelines
Wenn Ihre Organisation GitHub-Repositories mit aktiven CI/CD-Pipelines betreibt, sind einige sofortige Maßnahmen vorrangig zu behandeln.
Überprüfen Sie alle Dateien unter .github/workflows/ auf kürzlich hinzugefügte oder geänderte Einträge, insbesondere solche, die von Ihnen unbekannten Contributoren hinzugefügt wurden. Prüfen Sie die Commit-Historie speziell für Workflow-Dateien – nicht nur die Standardbranch-Ansicht.
Rotieren Sie alle Geheimnisse, die während des Angriffszeitraums aktiv waren oder bei denen Sie nicht mit Sicherheit bestätigen können, dass sie nicht offengelegt wurden. Überprüfen Sie bei Cloud-Zugangsdaten die anbieterseitigen Zugriffsprotokolle auf ungewöhnliche API-Aufrufe im selben Zeitfenster.
Überprüfen Sie, welche Repository-Contributor und Anwendungen Schreibzugriff haben. Angriffe mit gefälschten Identitäten hängen von der Möglichkeit ab, Code zu pushen – daher entfernt das Verschärfen von Contributor-Berechtigungen und das Aktivieren erforderlicher Reviews für Workflow-Änderungen einen wesentlichen Einstiegspunkt.
Erwägen Sie abschließend die Einführung eines dedizierten Secrets-Scanning-Werkzeugs, das bei jedem Commit ausgeführt wird und Zugangsdaten abfängt, bevor sie jemals in ein Repository eingecheckt werden. Mehrere Open-Source- und kommerzielle Optionen lassen sich direkt mit GitHub integrieren.
Was das für Sie bedeutet
Die Megalodon-Kampagne ist ein praktisches Beispiel dafür, warum CI/CD-Pipelines zu einer primären Angriffsfläche geworden sind. Entwickler und Sicherheitsteams, die Pipeline-Sicherheit als nachrangig gegenüber Anwendungssicherheit behandeln, hinterlassen einen weit offenen Weg zu ihren sensibelsten Zugangsdaten.
Beginnen Sie diese Woche mit einem Secrets-Audit. Überprüfen Sie, wer Ihre Workflow-Dateien ändern kann, rotieren Sie Zugangsdaten, die Sie nicht als sauber verifizieren können, und aktivieren Sie Branch-Protection auf Ihrem Standard-Branch, falls noch nicht geschehen. Die Geschwindigkeit des Megalodon-Angriffs bedeutet, dass die Exfiltration zum Zeitpunkt eines Alarms möglicherweise bereits abgeschlossen ist. Prävention und Zugriffsbeschränkung sind die einzigen zuverlässigen Verteidigungsmaßnahmen.
