Die Python Software Foundation hat nach dem Lieferkettenangriff „GhostAction“ alle potenziell kompromittierten PyPI-Tokens widerrufen. Laut PyPI gibt es keine Hinweise auf missbräuchliche Veröffentlichungen, dennoch wurde die Revokation als präventive Maßnahme umgesetzt, um Folgeschäden und sekundäre Angriffe zu verhindern.
Hintergrund: GitHub-Actions-Missbrauch und Secret-Exfiltration
Sicherheitsforscher von GitGuardian entdeckten manipulierte GitHub-Actions-Workflows (u. a. „FastUUID“), die zur Exfiltration von Secrets auf externe Server missbraucht wurden. Erbeutet wurden dabei auch Authentifizierungstokens für PyPI. Eine erste Meldung an PyPI erfolgte umgehend, doch eine Spam-Fehlzuordnung verzögerte die Reaktion bis zum 10. September.
Die Vorgehensweise folgt einem typischen Software-Lieferkettenangriff: Nicht die Zielsoftware selbst wird kompromittiert, sondern die CI/CD-Infrastruktur, in der Builds, Tests und Releases stattfinden. Dadurch erhalten Angreifer Zugriff auf hochprivilegierte Secrets und Automatisierungen.
Umfang und Auswirkungen der GhostAction-Kampagne
Nach Einschätzung von GitGuardian wurden mehr als 3.300 Secrets abgeflossen, darunter Tokens für PyPI, npm, DockerHub und GitHub sowie API-Schlüssel für Cloudflare und AWS und Datenbankzugänge. Solche Beute erlaubt laterale Bewegungen, die Manipulation von Build-Pipelines und potenziell die unbemerkte Verteilung kompromittierter Artefakte.
Reaktion von Plattformen und Maintainer-Teams
GitGuardian eröffnete Issues in über 570 betroffenen Repositories und informierte die Security-Teams von GitHub, npm und PyPI. Viele Maintainer rotierten Tokens, rollten Commits zurück und entfernten schädliche Workflows. PyPI meldete keine kompromittierten Repositories oder bösartigen Uploads, widerrief aber vorsorglich alle gefährdeten Tokens und kontaktierte Projektverantwortliche zur Wiederherstellung und Härtung.
Risikoanalyse: Warum langfristige Tokens problematisch sind
Langzeit-Tokens erhöhen die Angriffsfläche. Werden sie exfiltriert, bleiben sie häufig über Wochen einsatzfähig und ermöglichen Angreifern persistente Zugriffe. In CI/CD-Umgebungen mit breiten Berechtigungen verschärft sich das Risiko erheblich.
Kurzlebige Credentials und PyPI Trusted Publishers
PyPI empfiehlt die Umstellung auf kurzlebige, OIDC-gestützte Anmeldedaten via Trusted Publishers. Dabei wird die Vertrauensbeziehung zwischen Repository und PyPI verifiziert und für jede Veröffentlichung ein zeitlich begrenztes Token bereitgestellt. Selbst bei Exfiltration verfällt das Token schnell, und unautorisierte Publikationen werden erschwert.
Abwehrmaßnahmen: Praktiken für robuste CI/CD-Sicherheit
Minimalprinzip und kurze Lebensdauer: Rechte strikt nach dem Need-to-know-Prinzip vergeben und Ablaufzeiten setzen. Für GITHUB_TOKEN standardmäßig restriktive Permissions konfigurieren und nur gezielt erweitern.
Workflow-Härtung: Änderungen an Workflows nur mit Review zulassen, Ausführungen aus Forks begrenzen, externe Actions per Commit-SHA pinnen und verifizierte Publisher bevorzugen. Branch-Protection-Regeln und verpflichtende Statuschecks etablieren; wo möglich ephemeral Runner nutzen.
Monitoring und Früherkennung: Secret-Scanning, Audit-Logs, Release- und Authentifizierungsprotokolle aktiv überwachen. Anomalien wie unerwartete Veröffentlichungen, neue OIDC-Bindings oder Rechteausweitungen sofort untersuchen.
Schnelle Reaktion und Forensik: Bei Verdacht unverzüglich Tokens widerrufen, Artefakte neu bauen, kompromittierte Workflows bereinigen und die Lieferkette auf Manipulation prüfen. Frameworks wie OpenSSF Scorecards und SLSA helfen bei der Reifegradsteigerung.
Bedeutung für die Open-Source-Ökosysteme
GhostAction verdeutlicht die Hebelwirkung von Angriffen auf Automatisierung und Secretspeicher. Auch ohne nachweislich bösartige Uploads erzeugt die breite Exfiltration von Secrets systemische Risiken: Token-Wiederverwendung, unautorisierte Repository-Zugriffe und subtile Build-Manipulationen, die sich erst zeitverzögert zeigen.
Organisationen sollten jetzt handeln: auf PyPI Trusted Publishers und kurzlebige Credentials umstellen, GITHUB_TOKEN einschränken, Actions-Versionen pinnen, Telemetrie auswerten und regelmäßige Secret- und Workflow-Audits etablieren. Je kürzer die Gültigkeit von Tokens und je strenger die Kontrolle der Software-Lieferkette, desto geringer die Chancen für den nächsten GhostAction-Angriff.
