SecBoard
Zurück zur Übersicht

GitHub 'Verified' Commits Can Be Rewritten Into New Hashes Without Breaking Signatures

The Hacker News·
Originalartikel lesen bei The Hacker News

Forschende haben entdeckt, dass signierte Git-Commits manipuliert werden können, ohne die Signatur zu brechen. Angreifer können neue Hashes für bestehende Commits erstellen, die auf GitHub weiterhin als "verifiziert" angezeigt werden. Dies betrifft alle Nutzer, die sich auf die Integrität von Git-Commits verlassen, und erfordert eine Überprüfung der Annahmen über die Einzigartigkeit von Commit-Hashes.

Kurzfassung

Forschende haben entdeckt, dass signierte Git-Commits manipuliert werden können, ohne die Signatur zu brechen. Angreifer können neue Hashes für bestehende Commits erstellen, die auf GitHub weiterhin als "verifiziert" angezeigt werden. Dies erfordert eine Überprüfung der Annahmen über die Einzigartigkeit von Commit-Hashes und betrifft alle Nutzer, die sich auf die Integrität von Git-Commits verlassen.

Relevanz für Manager / CISOs
Priorität:Hoch
Betroffene

Alle Nutzer, die sich auf die Integrität von Git-Commits verlassen, insbesondere solche, die GitHub nutzen und den "verifizierten" Status als Garantie für die Hash-Unveränderlichkeit betrachten.

Warum relevant

Die Integrität von Code-Repositories ist entscheidend für die Sicherheit der Softwarelieferkette. Wenn Commits manipuliert werden können, ohne die Signatur zu brechen, untergräbt dies das Vertrauen in die Code-Historie und kann zu unentdeckten Änderungen führen.

Realistisches Worst Case

Ein Angreifer könnte unbemerkt manipulierte Commits in ein Repository einschleusen, die trotz Änderungen am Hash weiterhin als "verifiziert" angezeigt werden, was die Einführung von bösartigem Code oder Backdoors erleichtern könnte.

Handlungsempfehlung

Organisationen sollten ihre Prozesse zur Überprüfung der Code-Integrität anpassen und sich nicht ausschließlich auf den "verifizierten" Status oder die Einzigartigkeit von Commit-Hashes verlassen. Zusätzliche Verifikationsschritte sind erforderlich.

Defensive Validierung / Purple-Team Checks
  • Überprüfen Sie, ob Ihre CI/CD-Pipelines sich ausschließlich auf den Commit-Hash oder den "verifizierten" Status verlassen, um die Integrität des Codes zu gewährleisten.
  • Implementieren Sie zusätzliche Prüfungen der Code-Integrität, die über die reine Signaturprüfung hinausgehen, z.B. durch Vergleich von Inhalten oder durch den Einsatz von Supply Chain Security Tools.
  • Informieren Sie Entwickler und Sicherheitsteams über diese Schwachstelle und die Notwendigkeit, die Annahmen bezüglich der Unveränderlichkeit von Commit-Hashes zu überdenken.
MITRE ATT&CK Zuordnung
TaktikTechnikKonfidenzBeleg
Defense EvasionT1562 Impair DefensesMediumAngreifer können neue Hashes für bestehende Commits erstellen, die auf GitHub weiterhin als "verifiziert" angezeigt werden.
ImpactT1490 Inhibit System RecoveryLownot specified in the article
Offene Punkte
  • Es wird nicht spezifiziert, welche spezifischen Tools oder Methoden Angreifer nutzen könnten, um diese Manipulation durchzuführen.
  • Der genaue technische Mechanismus, wie ein neuer Hash mit identischem Inhalt und gültiger Signatur erzeugt werden kann, wird nicht detailliert beschrieben.
  • Es wird nicht erwähnt, ob GitHub plant, Änderungen vorzunehmen, um dieses Verhalten zu adressieren.

Red-Team-Relevanz

Was heißt das für dein nächstes Assessment?

  • Initial Access möglich?Unklar
  • Privilege Escalation relevant?Unklar
  • Exploit öffentlich verfügbar?Unklar
  • Detection / Logging prüfbar?Ja
  • Für Purple-Team-Szenario geeignet?Unklar

Kundenfragen

  • Können wir Reconnaissance detektieren?

MITRE ATT&CK Kill Chain (1 Techniken)

Reconnaissance