Secrets in der Git-Historie

Was ist Secrets in der Git-Historie?

Das Löschen fest im Quellcode hinterlegter Zugangsdaten in einem neuen Commit entfernt sie nicht aus früheren Commits. Der aktuelle Code kann sauber aussehen, während der Schlüssel in der Historie jahrelang lesbar bleibt. Sie finden den Lösch-Commit, lesen den Schlüssel aus einem früheren Commit und verwenden ihn gegen die aktive Admin-API. Dann bereinigen Sie die Historie mit git filter-repo — im Übungsablauf absichtlich vor der Rotation — und sehen, warum der Widerruf des Schlüssels eigentlich der erste Schritt sein muss.

Was Sie lernen in Secrets in der Git-Historie

• Erkennen, dass das Löschen eines fest hinterlegten Secrets per Commit es nicht entfernt: Git behält den Wert in den früheren Commits, sodass jeder, der das Repo klont, ihn lesen kann
• Den Angriffsweg nachvollziehen: ein öffentliches Repo klonen, die Commit-Historie einer Datei auflisten, den Commit vor der Löschung anzeigen und einen nie rotierten API-Schlüssel erneut verwenden
• Verstehen, dass das Umschreiben der Historie ein bereits geklontes oder gescanntes Secret nicht zurückholt und deshalb erst die Rotation der Zugangsdaten den geleakten Wert wirklich ungültig macht
• Die Rotation der Zugangsdaten als vorrangige Gegenmaßnahme setzen und das Umschreiben der Historie mit git filter-repo oder BFG samt erzwungener Aktualisierung des Remotes als Aufräumarbeit begreifen, die das Secret aus jedem Commit tilgt — nicht als die eigentliche Lösung
• Wiederholung verhindern, indem Secrets über Umgebungsvariablen aus dem Quellcode herausgehalten werden und ein Pre-Commit-Hook mit Secret-Scanning Zugangsdaten blockiert, bevor sie in die Historie des Repositorys gelangen

Secrets in der Git-Historie — Trainingsschritte

1. Das Ziel auskundschaften

   Bob hat heute Larkfell im Visier, einen Anbieter von Entwicklerplattformen, der einen großen Teil seiner Arbeit öffentlich betreibt. Zuerst sieht er sich das öffentliche Repository an und prüft, was das Unternehmen ausliefert. Dann sucht er nach einem Zugang. Für Bob ist ein Open-Source-Repo ergiebig: Das ganze Projekt, jede Datei und deren frühere Versionen können heruntergeladen werden.

2. Das Repo klonen

   Bob klont das Repository auf seinen eigenen Rechner, um das gesamte Projekt offline und in aller Ruhe durchsuchen zu können. Was er dabei herunterlädt, sind nicht nur die aktuellen Dateien, sondern die komplette Historie — und genau darauf hat er es abgesehen.

3. Den aktuellen Code prüfen

   Bevor er tiefer sucht, öffnet Bob die aktuelle Produktionskonfiguration und prüft, ob darin offensichtlich ein Secret steht. Die Datei enthält keines: Der Admin-Schlüssel wird aus einer Umgebungsvariablen gelesen und ist nicht fest im Quellcode hinterlegt. Bei einer flüchtigen Prüfung würde Bob hier aufhören.

4. Die Historie durchgehen

   Eine saubere Datei in HEAD sagt nichts über frühere Versionen aus. Der Schlüssel fehlt im aktuellen Code, aber Git bewahrt frühere Versionen dieser Datei in der Commit-Historie auf. Bob lässt sich deshalb ihre Commit-Historie anzeigen, um herauszufinden, was früher darin stand.

5. Der Schlüssel ist noch da

   Bob zeigt den Commit an, der die Konfiguration eingeführt hat — unmittelbar vor der späteren Korrektur. Der Lösch-Commit hat den Schlüssel nur aus dem aktuellen Code entfernt; im früheren Commit steht er weiterhin. Im Diff ist der Produktions-Admin-API-Schlüssel im Klartext zu lesen.

6. Der Schlüssel funktioniert noch

   Offengelegte Zugangsdaten sind erst dann als Angriffsweg bestätigt, wenn sie funktionieren. Bob sendet eine Anfrage an Larkfells Admin-API und übergibt den Schlüssel aus der Historie in einem Authorization-Header. Nach dem Lösch-Commit wurde der Schlüssel nie rotiert. Der alte Wert ist daher weiterhin gültig.

7. Die Kundenliste ist zugänglich

   Der Server hat dem Schlüssel vertraut und geantwortet. Bob liest Larkfells interne Kundenliste über eine öffentliche API aus — ganz ohne eigenes Konto.

8. Wissenscheck

9. Die Warnung trifft ein

   Sie verantworten Larkfells Backend-Repo. Über Nacht meldete der Secret-Scanning-Dienst für öffentliche Repositorys einen Fund und schickte Ihnen eine E-Mail. In der öffentlichen Commit-Historie liegt ein gültiger Produktions-API-Schlüssel. Im aktuellen Code steht er nicht mehr; der Scanner fand ihn in einem früheren Commit.

10. Aus HEAD verschwunden, in der Historie lebendig

    Zuerst prüfen Sie den aktuellen Code: Aus HEAD ist der Schlüssel tatsächlich entfernt worden. Jemand hat die Zeile in einem späteren Commit gelöscht. Das reichte nicht. Sie zeigen den früheren Commit an und sehen den gültigen Schlüssel sofort im Klartext. Alle noch vorhandenen Commits mit diesem Wert bleiben lesbar — auch nachdem die Zeile aus der aktuellen Version entfernt wurde.