Öffentlich zugängliches .git-Verzeichnis

Was ist Öffentlich zugängliches .git-Verzeichnis?

Ein Deployment, das den Working Tree in den Web-Root kopiert, kopiert auch .git mit. Dieses Verzeichnis enthält jeden Commit und jede Version der Dateien, nicht nur den aktuellen Stand. Wer es öffentlich abrufen kann, kann den gesamten Quellcode samt Historie rekonstruieren — einschließlich Secrets, die in späteren Commits entfernt wurden. In dieser Übung rufen Sie /.git/ auf einer produktiven Website auf, rekonstruieren den Quellcode mit git-dumper und finden darin ein Datenbankpasswort. Danach sperren Sie den Pfad am Webserver, deployen Build-Artefakte statt des Repositorys und rotieren die offengelegten Zugangsdaten.

Was Sie lernen in Öffentlich zugängliches .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

Öffentlich zugängliches .git-Verzeichnis — Trainingsschritte

1. Das Ziel auskundschaften

   Bob hat heute Verlune im Visier, einen Anbieter von Produktanalytik, dessen Dashboard unter app.verlune.io läuft. Zuerst sieht er sich die öffentliche App an, um zu verstehen, was das Unternehmen betreibt. Danach sucht er nach einem Einstieg. Die App selbst verrät wenig. Interessanter sind Pfade, die der Server eigentlich nie ausliefern sollte.

2. Ein Pfad, der nicht erreichbar sein sollte

   Bob ruft auf demselben Host direkt /.git/ auf — einen Pfad, den ein richtig konfigurierter Server niemals ausliefern sollte. Statt eines 404-Fehlers erhält er eine durchsuchbare Verzeichnisliste. Die internen Dateien eines Git-Repositorys — HEAD , config und objects — liegen im Web-Root und werden wie gewöhnliche Seiten ausgeliefert.

3. Ein echtes Repository

   Bob öffnet in der Verzeichnisliste die Datei config . Sie enthält eine normale Git-Konfiguration: das Remote-Repository origin, den Standard-Branch und Benutzereinstellungen. Das ist keine versehentlich liegen gelassene Einzeldatei. Das gesamte Arbeits-Repository wurde in die Produktion deployt — mitsamt seiner Historie.

4. Den Quellcode rekonstruieren

   Bob klickt die Verzeichnisliste nicht einzeln durch. Er richtet ein Dump-Tool auf den offenen Ordner. Es lädt die ausgelieferten Git-Objekte herunter und stellt den Working Tree des Repositories wieder her. Wenige Sekunden später liegen Verlunes Quellcode und Commit-Historie auf seinem Rechner.

5. Zugangsdaten im Quellcode

   Nachdem Bob den Quellcode wiederhergestellt hat, öffnet er die Datenbankkonfiguration. Oft sind die mit dem Code eingecheckten Secrets für einen Angreifer wertvoller als der Code selbst. Er muss nicht lange suchen.

6. Ein Passwort und ein Schlüssel

   Die wiederhergestellte Datei enthält zwei aktive Secrets im Klartext: den Connection String der Produktionsdatenbank samt Passwort und einen API-Schlüssel für die Admin-API. Beide wurden direkt im Quellcode eingecheckt. Deshalb legt das offene Repository sie ebenfalls offen.

7. Mit den geleakten Zugangsdaten verbinden

   Offengelegte Zugangsdaten sind erst dann als Angriffsweg bestätigt, wenn sie tatsächlich funktionieren. Die wiederhergestellte Konfiguration enthält den vollständigen Connection String der Datenbank mit Host, Name, Benutzer und Passwort. Bob öffnet einen SQL-Client und stellt damit eine direkte Verbindung zu Verlunes Produktionsdatenbank her. Er braucht weder einen Exploit noch eine gestohlene Sitzung: Die Datenbank akzeptiert das Passwort aus dem Repository.

8. Die Kundentabelle ist zugänglich

   Die Verbindung steht. Bob führt eine Abfrage aus und erhält die gesamte Kundentabelle der Produktionsdatenbank: Namen, E-Mail-Adressen, Tarife und Abrechnungsdaten. Er liest Verlunes aktuelle Kundendatensätze direkt aus der Datenbank, ohne ein eigenes Konto.

9. Wissenscheck

10. Der Monitoring-Alarm

    Sie verantworten Verlunes Web-Deploy-Pipeline. Über Nacht schlug das Monitoring für sensible Pfade in der Produktionsumgebung an: Der Abruf von .git/config auf app.verlune.io lieferte Status 200. Das Security-Operations-Team schickte Ihnen den Befund per E-Mail.