Offenes .git-Verzeichnis

Was ist Offenes .git-Verzeichnis?

Eine Bereitstellung, die den Arbeitsbaum in ein Webstammverzeichnis kopiert, kopiert .git mit. Dieser Ordner enthält jedes Commit und jede Version jeder Datei, nicht nur das, was live ist. Jeder, der dies anfordern kann, kann den gesamten Quellbaum neu erstellen, einschließlich der in späteren Commits entfernten Geheimnisse. Sie fordern /.git/ auf einer Live-Site an, führen git-dumper aus, um die Quelle zu rekonstruieren, und lesen daraus ein Datenbankkennwort. Dann blockieren Sie den Pfad auf dem Webserver, stellen erstellte Artefakte anstelle des Repositorys bereit und rotieren, was durchgesickert ist.

Was Sie lernen in Offenes .git-Verzeichnis

• Ein offenes .git-Verzeichnis erkennen: Ein Deployment, das das gesamte Repository ins Web-Root ausliefert, macht aus einer öffentlichen URL die vollständige Offenlegung von Quellcode und Historie
• Den Angriff nachvollziehen: von einer einsehbaren Auflistung unter /.git/ und einer lesbaren .git/config über einen git-dumper-Lauf, der den Quellcode-Baum rekonstruiert, bis zu den Secrets aus der eingecheckten Konfiguration
• Verstehen, dass in .git die gesamte Commit-Historie steckt — Zugangsdaten, die in späteren Commits geändert oder gelöscht wurden, lassen sich aus einem offenen Repository weiterhin wiederherstellen
• Die dauerhafte Lösung anwenden: Build-Artefakte statt des Repositorys deployen, damit .git nie in die Produktion gelangt, und alle Zugangsdaten rotieren, die dabei offengelegt wurden
• Unterscheiden zwischen einem Repository, das der Server über das Web offenlegt, und Secrets, die in der Commit-Historie eines gehosteten Repositorys stecken — und das Sperren der /.git-URL als Sofortmaßnahme begreifen, nicht als vollständige Lösung

Offenes .git-Verzeichnis — Trainingsschritte

1. Das Ziel auskundschaften

   Bobs Ziel heute ist Verlune, ein Anbieter von Produktanalytik, dessen Dashboard unter app.verlune.io läuft. Er beginnt dort, wo jeder beginnen würde: auf der öffentlichen Seite, um ein Gefühl dafür zu bekommen, was die Firma ausliefert, bevor er nach einem Weg hinein sucht. Die App selbst gibt wenig preis. Die interessanten Fehler stecken meist in den Pfaden, die eine Seite nie beantworten sollte.

2. Ein Pfad, der nicht antworten dürfte

   Bob ruft auf demselben Host direkt /.git/ auf — einen Pfad, den ein sauber konfigurierter Server niemals ausliefern würde. Statt eines 404 antwortet der Server mit einer einsehbaren Verzeichnisauflistung. Die internen Dateien eines Git-Repositorys — HEAD , config , objects — liegen allesamt im Web-Root und werden ausgeliefert wie jede andere Seite.

3. Ein echtes Repository

   Bob klickt in der Auflistung die Datei config an. Zurück kommt eine ganz gewöhnliche Git-Konfiguration: das Remote origin, der Default-Branch, die Benutzereinstellungen. Das ist keine vergessene Einzeldatei. Das komplette Arbeits-Repository ist in die Produktion gewandert — seine gesamte Historie ist damit nur einen Download entfernt.

4. Den Quellcode rekonstruieren

   Bob klickt sich nicht von Hand durch die Auflistung. Er setzt ein Dump-Tool auf den offenen Ordner an: Es läuft die ausgelieferten Objekte durch und baut den Working Tree exakt so wieder auf, wie er im Repo liegt. Sekunden später liegt der komplette Quellcode von Verlunes App auf seinem eigenen Rechner — samt Historie.

5. Zugangsdaten im Quellcode

   Der Quellcode steht wieder — Bob öffnet die wiederhergestellte Datenbankkonfiguration. Das Wertvollste an einem geleakten Repo ist selten der Code selbst; es sind die Secrets, die nebenher eingecheckt wurden. Lange suchen muss er nicht.

6. Ein Passwort und ein Schlüssel

   Die wiederhergestellte Datei liefert Bob zwei gültige Secrets im Klartext: den Connection String der Produktionsdatenbank, Passwort inklusive, und einen API-Schlüssel für die Admin-API. Beide wurden direkt in den Quellcode eingecheckt — genau deshalb gibt ein offenes Repository sie preis.

7. Mit den geleakten Zugangsdaten verbinden

   Geleakte Zugangsdaten sind Theorie, solange sie nichts öffnen. Die wiederhergestellte Konfiguration liefert Bob einen vollständigen Connection String — Host, Datenbankname, Benutzer und Passwort. Also öffnet er einen SQL-Client und verbindet sich damit direkt mit Verlunes Produktionsdatenbank. Kein Exploit, keine gestohlene Sitzung: Die Datenbank vertraut dem Passwort, das das Repository verschenkt hat.

8. Die Kundentabelle liegt offen

   Verbunden. Bob setzt die naheliegende Abfrage ab, und die Kundentabelle der Produktionsdatenbank kommt vollständig zurück: Namen, E-Mail-Adressen, Tarife, Abrechnungsdaten. Er liest Verlunes echte Kundendatensätze direkt aus der Datenbank — ganz ohne eigenes Konto.

9. Wissenscheck

   Sie haben gerade gesehen, wie eine einzige öffentliche URL den kompletten Quellcode-Baum und seine Secrets herausgibt. Prägen Sie sich ein, warum das so ist.

10. Der Monitoring-Alarm

    Sie verantworten Verlunes Deploy-Pipeline für das Web. Über Nacht hat der Monitoring-Check angeschlagen, der die Produktion auf sensible Pfade prüft: Er hat .git/config auf app.verlune.io abgerufen und ein 200 zurückbekommen. Security Operations hat Ihnen den Befund per E-Mail geschickt.