API-Schlüssel auf GitHub geleakt: finden und richtig reagieren

Ein Entwickler kopiert eine funktionierende .env-Datei in ein Testprojekt, pusht sie „nur kurz“ in ein öffentliches Repository und löscht sie am selben Nachmittag. Das Datenbankpasswort, der Zahlungsschlüssel und die SMTP-Zugangsdaten Ihres Unternehmens sind jetzt öffentlich, und sie bleiben es: im Verlauf des Repositorys, in jedem Fork und in den Archiven der Bots, die den öffentlichen Datenstrom von GitHub ununterbrochen mitlesen.

Das ist einer der häufigsten Wege, auf denen kleine Unternehmen angegriffen werden, und einer der am billigsten zu verhindernden.

Wie Geheimnisse in öffentlichen Code geraten

• Versehentlich eingecheckte Konfigurationsdateien: .env, config.yml, settings.py, wp-config.php, appsettings.json.
• Private Repositorys oder solche von Dienstleistern: Ein Freelancer veröffentlicht ein für Sie gebautes Projekt im Portfolio, mit Ihren echten Zugangsdaten.
• Im nächsten Commit gelöscht: Die Datei fehlt in der aktuellen Version, aber jeder kann den vorherigen Commit lesen.
• Testskripte und Notebooks: ein schnelles Skript zum Mailversand, mit dem SMTP-Passwort im Code.
• Verbindungszeichenfolgen: postgres://app:passwort@db.ihre-domain.de/app verrät Passwort und Ziel zugleich.

Wie schnell sie gefunden werden

Automatische Scanner beobachten jeden öffentlichen Push. Untersuchungen zu geleakten Cloud-Schlüsseln zeigen immer wieder Zugriffsversuche innerhalb von Minuten. GitHubs eigenes Secret Scanning prüft öffentliche Repositorys auf die Schlüssel Hunderter Anbieter und warnt einige davon, die den Schlüssel widerrufen können; Datenbankpasswörter, SMTP-Konten und Ihre eigenen internen Tokens deckt es nicht ab.

Suchen Sie nach Ihrer eigenen Domain

Angreifer suchen Ihr Unternehmen über seinen Domainnamen, weil Konfigurationsdateien die Server nennen, mit denen sie sich verbinden. Das können Sie auch. Suchen Sie im Code auf GitHub nach:

"ihre-domain.de" password
"ihre-domain.de" secret
"ihre-domain.de" filename:.env

Sehen Sie sich jedes Ergebnis außerhalb Ihrer eigenen Organisation an. Eine Datei, die Ihre Domain neben password= oder einem Schlüssel nennt, sollten Sie öffnen.

Wenn Sie eines finden: zuerst widerrufen

Die Reihenfolge zählt, und die meisten machen es umgekehrt.

1. Widerrufen oder ändern Sie das Geheimnis sofort. Neuen Schlüssel erzeugen, Passwort ändern, Token erneuern, im jeweiligen Dienst. Solange das nicht geschehen ist, zählt nichts anderes: Die Datei zu löschen macht das alte Geheimnis nicht wieder geheim.
2. Prüfen Sie, ob es benutzt wurde. Sehen Sie in die Protokolle des Dienstes: Anmeldungen, API-Aufrufe, versendete E-Mails, neue Benutzer, unerwartete Rechnungen, ab dem Datum des Commits.
3. Entfernen Sie es aus dem Code. Gehört das Repository Ihnen, schreiben Sie seinen Verlauf mit git filter-repo um (GitHub dokumentiert das unter „Removing sensitive data from a repository“) und bitten Sie den GitHub-Support, zwischengespeicherte Ansichten zu löschen. Gehört es jemand anderem, bitten Sie den Inhaber um Entfernung; antwortet er nicht, nimmt GitHub Anträge auf Entfernung sensibler Daten aus fremden Repositorys an.
4. Finden Sie heraus, wie es passiert ist, und verhindern Sie das nächste Mal: eine .gitignore für Umgebungsdateien, Secret Scanning mit Push-Schutz für Ihre eigenen Repositorys und Geheimnisse in einem Secret-Manager statt in Dateien.

Das nächste Leck verhindern

• Halten Sie Geheimnisse ganz aus dem Code heraus: Umgebungsvariablen, die beim Deployment gesetzt werden, oder ein Secret-Manager.
• Schalten Sie den Push-Schutz von GitHub für die Repositorys Ihrer Organisation ein: Er blockiert einen Push, der einen erkannten Schlüssel enthält.
• Lassen Sie einen Scanner wie gitleaks in Ihrer CI laufen, damit ein Geheimnis den Build scheitern lässt, bevor es gemergt wird.
• Geben Sie Dienstleistern eigene Zugangsdaten mit begrenzten Rechten und widerrufen Sie sie nach dem Auftrag.
• Bevorzugen Sie Schlüssel, die auf das Nötige beschränkt sind: eine Domain, ein Adressbereich, nur Lesen, wo es geht.

Wie Perimetry für Sie wacht

Jede Woche durchsucht Perimetry Cloud öffentlichen Code auf GitHub nach Dateien, die Ihre nachgewiesenen Domains nennen, liest sie und erkennt Passwörter und Schlüssel: Schlüssel von AWS, Stripe, GitHub, GitLab, Slack, SendGrid, OpenAI und Anthropic, private Schlüssel, Passwörter in Verbindungszeichenfolgen und in der Konfiguration neben Ihrer Domain. Das Geheimnis selbst wird nie gespeichert, nur seine Art, seine ersten Zeichen und sein Fundort, und Sie werden benachrichtigt, wenn ein neues schweres auftaucht. Dasselbe Audit sieht sich auch die Dateien an, die das Internet Archive von Ihren Websites aufbewahrt hat (alte Backups und Konfigurationsdateien), die auf dieselbe Weise lecken.