Secrets in der Git-Historie

Was ist Secrets in der Git-Historie?

Durch das Löschen fest codierter Anmeldeinformationen in einem neuen Commit werden diese nicht entfernt. Git behält jede Version jeder Datei, sodass der Wert vor der Bereinigung noch im Commit verbleibt. Der aktuelle Code sieht sauber aus, weshalb diese Lecks jahrelang bestehen bleiben. Sie finden den Commit, der behauptet, einen Produktions-API-Schlüssel entfernt zu haben, lesen ihn aus dem vorherigen Commit und spielen ihn mit der Live-Administrator-API ab. Dann bereinigen Sie den Verlauf mit git filter-repo, absichtlich in der falschen Reihenfolge, und erfahren, warum die Rotation an erster Stelle steht.

Was Sie lernen in Secrets in der Git-Historie

• Erkennen, dass das Löschen eines hartcodierten Secrets in einem neuen Commit es nicht entfernt: git behält den Wert in jedem früheren Commit und im Reflog, sodass jeder ihn lesen kann, der das Repo klont
• Den Weg eines Angreifers nachvollziehen — vom Klonen eines öffentlichen Repos über das Auflisten der Commit-Historie einer Datei und das Anzeigen des Commits vor der Löschung bis zum erneuten Abspielen eines gültigen API-Schlüssels, der nie rotiert wurde
• 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

   Heute hat Bob es auf Larkfell abgesehen, einen Anbieter von Entwicklerplattformen, der einen großen Teil seiner Arbeit offen betreibt. Er beginnt dort, wo jeder beginnen würde: beim öffentlichen Repository. Erst verschafft er sich einen Überblick darüber, was das Unternehmen ausliefert, bevor er nach einem Weg hinein sucht. Ein Open-Source-Repo ist für jemanden wie Bob ein Geschenk: das komplette Projekt, jede Datei und jede Version jeder Datei — alles zum Herunterladen.

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 gräbt, macht Bob das, was auch ein sorgfältiger Reviewer täte: Er öffnet die aktuelle Produktionskonfiguration und sieht nach, ob dort etwas Offensichtliches liegen geblieben ist. Sie ist sauber. Der Admin-Schlüssel wird aus einer Umgebungsvariablen gelesen und steht nicht in der Datei — hier ist nichts hartcodiert. Ein flüchtiger Blick würde genau hier aufhören.

4. Die Historie durchgehen

   Eine saubere Datei in HEAD sagt nichts über die Vergangenheit aus. Aus dem aktuellen Code ist der Schlüssel verschwunden, doch git hat jede frühere Version dieser Datei behalten. Bob weiß das und lässt sich die Commit-Historie der Konfiguration ausgeben — ihn interessiert nicht nur, was heute darin steht, sondern was früher darin stand.

5. Der Schlüssel ist noch da

   Bob lässt sich den Commit anzeigen, der die Konfiguration hinzugefügt hat — den direkt vor dem Aufräumen. Der Lösch-Commit hat die Zeile aus dem aktuellen Code entfernt, dieser frühere Commit trägt sie jedoch weiterhin. Der Admin-API-Schlüssel der Produktion steht im Klartext im Diff, genau so, wie er dort stand, bevor jemand ihn herausnehmen wollte.

6. Der Schlüssel funktioniert noch

   Ein geleakter Schlüssel bleibt Theorie, solange er nichts öffnet. Bob richtet den aus der Historie geholten Schlüssel auf Larkfells Admin-API und schickt ihn im Authorization-Header mit, so wie es ein echter Client täte. Nach dem Aufräum-Commit wurde der Schlüssel nie rotiert — der Wert aus jenem alten Commit ist also weiterhin gültig.

7. Die Kundenliste liegt offen

   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

   Sie haben gerade erlebt, wie ein gelöschtes Secret trotzdem eine Produktions-API geöffnet hat. Prägen Sie sich ein, warum.

9. Der Alarm trifft ein

   Sie verantworten Larkfells Backend-Repo. Über Nacht hat der Secret-Scanning-Dienst, der Ihre öffentlichen Repositorys überwacht, Alarm geschlagen und Ihnen eine E-Mail geschickt. Der Befund ist unmissverständlich: In der öffentlichen Commit-Historie liegt ein gültiger Produktions-API-Schlüssel. Im aktuellen Code steht er nicht, aber der Scanner ist die Historie durchgegangen und hat ihn in einem früheren Commit gefunden.

10. Aus HEAD verschwunden, in der Historie lebendig

    Ihr erster Reflex ist ein Blick in den aktuellen Code — und tatsächlich, aus HEAD ist der Schlüssel verschwunden. Jemand hat die Zeile bereits in einem späteren Commit gelöscht. Geholfen hat das nicht. Sie lassen sich den früheren Commit selbst anzeigen, und der gültige Schlüssel steht sofort wieder auf dem Bildschirm. Er überlebt in jedem Commit, der ihn noch enthält: Die Zeile aus der neuesten Version zu löschen, hat daran nichts geändert — für jeden, der das Repo geklont hat, blieben die Zugangsdaten vollständig lesbar.