Das Löschen eines durchgesickerten Schlüssels aus Ihrem Repo schützt Sie nicht

tl;dr: Wenn du ein Geheimnis preisgibst, ändere es sofort. Das Löschen einer Datei, das Umschreiben des Git-Commit-Verlaufs oder das Löschen deines Repositorys schützt dich nicht. Angreifer durchsuchen regelmäßig das Internet nach secrets – gehe also davon aus, dass sie bereits eine Kopie haben. Verwende Betterleaks oder Aikido Secrets Detection , um durchgesickerte „ secrets “ in deinen Repos zu finden, und nutze Aikido „Device Protection“ , um sie auf Entwicklerrechnern zu finden.

Im Mai haben die Entwickler von LiteLLM versehentlich einen Administratorschlüssel in ein öffentliches GitHub-Repository hochgeladen. Monate später nutzten Angreifer diese Zugangsdaten, um die Infrastruktur des Unternehmens zu kompromittieren.

Der Nachbericht von LiteLLM dokumentiert den zeitlichen Ablauf der Maßnahmen, die zur Behebung der Sicherheitslücke ergriffen wurden. Ein Satz aus dem Bericht ist mir besonders aufgefallen:

„Etwa drei Stunden später wurde die Datei [die das Geheimnis preisgab] durch einen nachfolgenden Commit gelöscht, und die Schlüssel wurden als widerrufspflichtig gekennzeichnet, doch der ursprüngliche Commit blieb bis zum 22. Oktober im öffentlichen Verlauf des Repositorys erhalten.“

LiteLLM entdeckte die Sicherheitslücke innerhalb von drei Stunden. Als erste Korrekturmaßnahme reichte dieser Pull Request ein, mit dem die Datei einfach gelöscht wurde. Monate später, am 22. Oktober, schrieben sie den Git-Verlauf um, um die Commits zu entfernen, durch die die Anmeldedaten offengelegt worden waren.

Diese beiden Maßnahmen sind zwar weit verbreitet, spiegeln jedoch allgemeine Fehlvorstellungen unter Entwicklern hinsichtlich der Offenlegung vertraulicher Daten in der Git-Historie wider. Keiner der beiden Schritte, die LiteLLM unternommen hat, verhindert tatsächlich, dass jemand die offengelegten Daten einsehen kann. Tatsächlich ist der Commit, durch den die Anmeldedaten offengelegt wurden, bis heute sichtbar (keine Sorge, sie haben die Anmeldedaten inzwischen geändert!).

Die einzige Möglichkeit, ein Problem mit durchgesickerten Zugangsdaten vollständig zu beheben, besteht darin, diese Zugangsdaten zu ändern. Sobald sie öffentlich bekannt sind, sind sie kein Geheimnis mehr und werden es auch nie wieder sein.

Häufige Missverständnisse bezüglich der in Git durchgesickerten „ Secrets “

In den folgenden Experimenten wird jeweils eine gängige „Abhilfe“ für das Durchsickern von „ secrets “ in Git-Repositories getestet:

• Die Datei löschen
• Git-Historie neu schreiben
• Das Repo löschen

Keine dieser Maßnahmen schützt Sie vollständig davor, dass Angreifer ein von Ihnen preisgegebenes Geheimnis entdecken und ausnutzen. Selbst wenn es nur für wenige Minuten öffentlich zugänglich ist.

Irrtum Nr. 1: Die Datei löschen

LiteLLM verfolgte diesen Ansatz unmittelbar nach der Entdeckung der Sicherheitslücke, und dies ist wahrscheinlich die häufigste Reaktion. Der Entwickler erkannte einen Fehler in seinem Code und „behob“ ihn, indem er die betreffende Datei in einem neuen Commit löschte. Wie wir weiter unten sehen werden, analysieren Secret-Scanner die Git-Historie und durchsuchen gelöschte Dateien.

1. Erstelle ein neues lokales Git-Repo. Führe ein Commit für eine README-Datei durch. Führe anschließend ein Commit für eine Datei durch, die ein Geheimnis enthält.

mkdir tmp_repo
cd tmp_repo
git init
echo "# README" > README.md
git add README.md
git commit -m „erster Commit“
# gefälschter, durchgesickerter Schlüssel
echo "secret_token=ZQ5Cl16U8kmc4uOxS581xDWr" > file.txt
git add file.txt
git commit -m „Offenlegung des Geheimnisses in file.txt“

2. Lösche diese Datei. Führe erneut ein Commit durch.

rm file.txt
git add .
git commit -m „offengelegtes Geheimnis in file.txt entfernt“

3. Führen Sie einen Scan mit Betterleaks durch. Sie werden sehen, dass ein Geheimnis in der Git-Historie erkannt wird. (Eine Anleitung zur Einrichtung von Betterleaks finden Sie auf der GitHub-Seite.)

betterleaks git .

Irrtum Nr. 2: Die Git-Historie umschreiben

Der nächste Reflex ist in der Regel, den Leak aus der Git-Historie zu „löschen“. LiteLLM hat dies am 22. Oktober versucht, indem es eine umgeschriebene Historie per Force-Push hochgeladen hat, in der die betreffenden Commits nicht enthalten sind. Oberflächlich betrachtet scheint dies zu funktionieren, da diese Commits von keinem Zweig aus erreichbar sind. Leider stellt GitHub „gelöschte“ Commits weiterhin jedem zur Verfügung, der über deren SHA-1-Hash verfügt.

1. Notieren Sie sich den SHA-1-Hash des Commits, in dem Sie das Geheimnis offengelegt haben.

git log --format=%H --grep="Offenlegung eines Geheimnisses in der Datei file.txt" -1

Hinweis: SHA-1-Hashes sind 40 Zeichen lang, was viel zu lang ist, um sie zu erraten. GitHub ermöglicht es Nutzern jedoch, in der Benutzeroberfläche eine Kurzversion anzugeben, die auf die vollständigen 40 Zeichen verweist. Die Kurzversion kann aus nur 4 Zeichen (0–9a–f) bestehen, wodurch diese Hashes leichter zu finden sind.

2. Übertrage das oben genannte lokale Repo auf GitHub. (Erstelle das Repo auf der GitHub-Website, falls der erste Befehl nicht funktioniert.)

git remote add origin https://github.com/<github-username>/tmp_repo.git
git branch -M main
git push -u origin main

3. Setzen Sie Ihren Git-Head auf den ersten Commit zurück. Führen Sie einen Force-Push auf GitHub durch.

git reset HEAD~2 --hard
git push --force

Hinweis: Es gibt verschiedene Möglichkeiten, den Commit-Verlauf neu zu schreiben. Da es sich hierbei um eine einfache Demo handelt, setzen wir unser Repository lediglich auf den allerersten Commit zurück und führen anschließend einen Force-Push durch.

4. Lösche dein lokales Repo.

cd ..
# rm -r tmp_repo # Überprüfen Sie den Namen des Verzeichnisses noch einmal, bevor Sie den Befehl ausführen dieses

5. Kopiere die Fernbedienung.

git clone https://github.com/<user>/tmp_repo.git
cd tmp_repo

6. Überprüfen Sie den Git-Verlauf in der geklonten Version. Dort wird nur ein Commit angezeigt.

git log

7. Lade deinen „gelöschten“ Commit direkt von GitHub herunter. Zeige die „gelöschte“ Datei an.

git fetch origin <sha1_hash_from_step_1>
git checkout <sha1_hash_from_step_1>
cat file.txt

Wenn du den „gelöschten“ Commit im Browser aufrufst, wird oben ein Banner angezeigt, auf dem steht: „Dieser Commit gehört zu keinem Branch in diesem Repository…“, dennoch können wir ihn weiterhin sehen.

https://github.com/<user>/tmp_repo/commit/<sha1_hash_from_step_1>

Irrtum Nr. 3: Das Repo löschen

Als letzten Ausweg löschen Entwickler oft das gesamte Repository. Leider reicht auch das nicht aus. Erstens hast du keinerlei Einblick darin, wer dein Repository geklont hat. Zweitens: Falls jemand dein Repository geforkt hat, behält GitHub eine Kopie deines „gelöschten“ Commits auf unbestimmte Zeit.

1. Bitte einen Freund, das oben erstellte Repository zu forken.
2. Lösche dein Repository.
3. Rufe den gelöschten Commit (über den Hash) in der Fork-Version deines Freundes auf.

https://github.com/<friend>/tmp_repo/commit/<sha1_hash_from_step_1>

Der Commit, der Ihre durchgesickerten Daten enthält, bleibt auf GitHub auf unbestimmte Zeit bestehen, bis der letzte Fork gelöscht wird.

Was wäre, wenn es niemand gesehen hätte?

Falls diese Experimente nicht ausreichen, um Sie davon zu überzeugen, dass Sie öffentlich zugängliche Anmeldedaten regelmäßig ändern müssen, sehen Sie sich an, wie unser Kollege Mackenzie auf einer Konferenz live einen Schlüssel preisgibt, und prüfen Sie anschließend, wie viele Akteure seinen Schlüssel innerhalb weniger Minuten gescannt haben. Forscher, SaaS-/Cloud -Plattformen und Angreifer suchen ständig nach secrets . Gehen Sie davon aus, dass jemand den Schlüssel gesehen hat, sobald er öffentlich ist.

Drehen Sie Ihre freiliegenden Schlüssel

Das Löschen einer Datei, das Überschreiben des Verlaufs und das Löschen eines Repos führen dazu, dass ein durchgesickertes Geheimnis weiterhin zugänglich bleibt. Die einzige Maßnahme, die Ihr Konto vollständig schützt, ist die regelmäßige Änderung Ihrer Anmeldedaten:

• die durchgesickerte Version widerrufen
• ein neues ausstellen
• Überall dort, wo die alte Version verwendet wurde, aktualisieren

Zwar verhindert die Rotation von Anmeldedaten künftigen Missbrauch, doch gegen bereits erfolgten Missbrauch hilft sie nicht, und ein durchgesickerter Schlüssel kann monatelang unentdeckt bleiben, bevor ihn jemand findet. Der Schlüssel von LiteLLM war über vier Monate lang aktiv, bevor ein Angreifer ihn nutzte, um ein GitHub-Token abzurufen und eine bösartige Version zu veröffentlichen.

Überprüfen Sie nach dem Drehen, ob Anzeichen dafür vorliegen, dass der alte Schlüssel bereits verwendet wurde:

• Die eigenen Nutzungs- und Zugriffsprotokolle des Schlüssels oder Tokens
• Aktuelle Commits in den Hauptzweig und alle geschützten Zweige
• Änderungen an CI und Workflow-Konfigurationen sowie die letzten Pipeline-Durchläufe

Wenn Sie einen Missbrauch nicht ausschließen können, behandeln Sie den Vorfall als solchen.

Wie „ Aikido “ hilft

Aikido hilft Ihnen dabei, zu überprüfen, ob bei Ihnen Datenlecks aufgetreten sind secrets. Kunden profitieren von der in die Aikido -Plattform integrierten Erkennung von secrets , und jeder kann „Betterleaks“ nutzen, die kostenlose Open-Source-Engine, auf der diese Funktion basiert.

Aikido Secrets Erkennung und Geräteschutz

Verbinden Sie Ihre GitHub-, GitLab-, Bitbucket- oder Azure DevOps-Repositorys – egal ob öffentlich oder privat – und Aikido Secrets Detection überprüft diese auf API-Schlüssel, Passwörter, Tokens und andere offengelegte Anmeldedaten. Standardmäßig wird der aktuelle Code überprüft; Sie können jedoch auch eine vollständige Überprüfung des Git-Verlaufs aktivieren, um „ secrets “ zu erkennen, die hinzugefügt und später wieder entfernt wurden, wie beispielsweise die gelöschte Datei aus Missverständnis Nr. 1.

Die Betterleaks-Engine kombiniert bekannte Muster von Anmeldedaten mit Techniken zur Erkennung generischer secrets. Bei unterstützten Anmeldedatentypen prüft die „Live Secret Detection“, ob ein durchgesickertes Geheimnis noch aktiv ist, und passt den Schweregrad des Problems entsprechend an. Secrets AutoTriage nutzt den Kontext, um echte Anmeldedaten von Beispiel- oder Testwerten zu unterscheiden.

Aikido Außerdem werden „ secrets “ bereits in einer frühen Entwicklungsphase markiert. IDE-Erweiterungen und ein Pre-Commit-Hook warnen Entwickler, bevor ein Geheimnis in einen Commit gelangt. In CI/CD kann „ Aikido “ einen Build oder einen PR blockieren, der ein solches Geheimnis enthält.

Aikido „Device Protection“ fügt auf Entwicklerrechnern eine zusätzliche Sicherheitsebene hinzu. Der Agent durchsucht lokale Dateien auf dem Gerät, wie beispielsweise den Shell-Verlauf, nach fest codierten „ secrets “. Der Inhalt der Dateien verbleibt auf dem Gerät. Wenn der Agent ein Geheimnis findet, erhält Aikido den Typ des Geheimnisses sowie einige Zeichen des Werts – genug, um den Fund zu erkennen.

Betterleaks

Jeder kann Betterleaks eigenständig betreiben. „ Aikido “ sponsert das Projekt, und es ist unter der MIT-Lizenz kostenlos verfügbar. Der ursprüngliche Autor von Gitleaks hat es als direkten Ersatz für Gitleaks entwickelt.

Zur Erinnerung: Unabhängig davon, welches Tool ein offengelegtes Geheimnis entdeckt, sollten Sie es rotieren. „ Aikido “ kennzeichnet aktive Zugangsdaten und empfiehlt, diese zu rotieren; widerrufen Sie die Zugangsdaten und ersetzen Sie sie beim Dienst, der sie ausgestellt hat. Das Löschen des Geheimnisses aus Ihrem letzten Commit führt dazu, dass es im Git-Verlauf verbleibt, wie die obigen Experimente zeigen.