CodeQL-Lieferkettenangriffsrisiko – Sicherheitsvorfall ausgelöst durch offengelegtes GitHub-Secret

• Durch ein offengelegtes GitHub-Secret war CodeQL, das statische Analysetool von GitHub, einem Lieferkettenangriff ausgesetzt
• Der betreffende Schlüssel war 1,022 Sekunden lang gültig; in dieser Zeit konnte ein Angreifer in GitHub-Actions-Workflows beliebigen Code ausführen
• Diese Schwachstelle ist als öffentliche CVE erfasst: CVE-2025-24362

Zentrale Schadensszenarien

Über diese Schwachstelle hätte ein Angreifer folgende Angriffe ausführen können:

• Exfiltration des Quellcodes von Repositories, die CodeQL verwenden (Verletzung geistigen Eigentums)
• Diebstahl von GitHub-Actions-Secrets und mögliche Folgeangriffe
• Codeausführung über CodeQL-Workflows in interner Infrastruktur
• Auch Secrets aus Workflows, die GitHub Actions Cache verwenden, konnten gestohlen werden

Angriffserkennung und Experimentverlauf

• Das Forschungsteam von Praetorian entwickelte ein Tool zum Scannen von Secrets, die in von GitHub Actions erzeugten Workflow-Artefakten enthalten sind
• In CodeQL-bezogenen Repositories wurde ein Debug-Artefakt mit enthaltenem Secret entdeckt
• Es wurde das PoC-Tool artifact_racer.py erstellt und ausgeführt, das belegt, dass ein Angreifer während der Gültigkeit des Schlüssels Branches/Tags erstellen und Dateien pushen konnte

Zentrale Versuchsergebnisse

• Mit diesem Token konnte ein Angreifer:
  • einen neuen Branch erstellen
  • Dateien pushen
  • Tags hinzufügen
• CodeQL referenziert standardmäßig das Tag v3, und ein Angreifer konnte dieses Tag überschreiben → Verteilung von Schadcode an alle CodeQL-Nutzer möglich

Ausbreitungspotenzial: Warum ist das gefährlich?

• Die meisten Nutzer konfigurieren CodeQL nicht manuell, sondern klicken in den GitHub-Repository-Einstellungen auf die Schaltfläche "Enable CodeQL"
• Der dabei automatisch eingerichtete Workflow referenziert das Repository github/codeql-action und basiert auf dem Tag v3
• Wenn ein Angreifer das Tag v3 mit einem bösartigen Commit überschreibt, wird in zahlreichen Projekten automatisch Schadcode ausgeführt

Zusätzliche Angriffsmöglichkeit: Cache Poisoning

• Der standardmäßige CodeQL-Workflow verwendet GitHub Actions Cache
• Dadurch kann ein Angreifer einen bösartigen Cache in die Build-Pipeline einschleusen und in nachfolgenden Workflows Secrets stehlen sowie internen Zugriff erlangen
• Prominente potenzielle Ziele:
  • Homebrew
  • Angular
  • Grafana

Reaktion und Patch von GitHub

• Nach Meldung der Schwachstelle am 22. Januar 2025 hat GitHub innerhalb von 3 Stunden:
  • den verwundbaren Workflow gestoppt
  • einen PR zur Verhinderung des Uploads von Secrets eingereicht
  • eine gepatchte Version veröffentlicht: CodeQL Action v3.28.3
• Offizielle Sicherheitswarnung: GHSA-vqf5-2xx6-9wfm

Gegenmaßnahmen

• Beim Hochladen von Artefakten in Workflows sollten die hochzuladenden Dateien eingeschränkt werden
• Vorsicht bei Umgebungsvariablen sowie Dateien in .git/config und im Verzeichnis _temp/
• GITHUB_TOKEN sollte nur mit Leserechten versehen werden
• Vor dem Upload wird ein Secret-Scan empfohlen (mit Tools wie Nosey Parker)

Fazit

• Schon mit der Standardkonfiguration von CodeQL können zahlreiche Projekte Lieferkettenangriffen ausgesetzt sein
• Sicherheitslücken in GitHub Actions bleiben eine ernste Bedrohung, und die Community braucht weiterhin Aufmerksamkeit und Abwehrstrategien

Weiterführende Informationen

• CVE-Informationen: CVE-2025-24362
• PoC-Branch: testpoc
• Commit-Link: Commit
• Tag-Link: Tag

[GN⁺]

Hacker-News-Kommentare

• Es gibt die Meinung, dass die Veröffentlichung unveränderlicher GitHub Actions mehr als 70 % der Angriffe verhindern könnte
  • Man denke, dass die wöchentlichen Probleme bei GitHub sie dazu bringen werden, dies zu veröffentlichen
• Es gibt keine Erwähnung dazu, warum das temporäre Token die Berechtigung hatte, neue Deployments zu erstellen und Artefakt-Nachweise zu erzeugen
  • Zur Behebung des Problems wurden Debug-Logs deaktiviert, aber es gibt keine Antwort darauf, ob die Berechtigungen des temporären Tokens stärker an eine Code-Analyse-Engine angepasst wurden
• Ich bin zunehmend überzeugt, dass CI und CD vollständig getrennte Umgebungen sein sollten
  • Eine Kompromittierung von CI sollte nicht zum Abfluss von CD-bezogenen Tokens führen
• Die Reaktionszeit von GitHub ist sehr beeindruckend
• Es gibt die Meinung, dass man als Person mit dem Nachnamen Prater gerne praetorian.com besitzen würde
• Die Nutzung öffentlicher GitHub Actions kann Probleme verursachen, und sie zu verwenden, ohne die Workflow-Prozeduren zu analysieren, ist noch riskanter
  • Stattdessen wird empfohlen, woodpecker oder andere hervorragende CI-Builder (circle, travis, gitlab usw.) selbst zu hosten
• Es wird erwähnt, dass für OpenZFS-PRs CodeQL verwendet wird und es bei OpenZFS kein Problem gibt
  • Der Code von OpenZFS ist kein Geheimnis
• Es gibt die Frage, ob das Problem behoben wurde
• Es gibt Beschwerden, dass die Performance der Seite so schlecht ist, dass Scrollen fast unmöglich ist