Ich habe mein .git-Verzeichnis für den Webserver lesbar hinterlassen. Welche Risiken habe ich?

4090
Thomas Hunter

Auf einer meiner Webanwendungen habe ich das .git-Verzeichnis aus Versehen für die letzten Wochen für den Webserver lesbar gelassen. Die Indexauflistung wurde deaktiviert. Der Besuch der URL "website.com/.git" würde zu einem 404-Fehler führen, der sich von keinem anderen 404-Fehler unterscheiden ließ. Wenn Sie beispielsweise die Website "website.com/.git/config" aufrufen, wird die Datei heruntergeladen.

Welche Risiken bestehen bei meinen Bewerbungen? Ist es möglich, dass genügend Informationen verfügbar sind, dass jemand den gesamten Quellcode der Anwendung heruntergeladen haben könnte?

7
Haben Sie einen `git clone http: // website.com / .git` ausprobiert? Das ist das größte Risiko (das vollständige Repo klonen zu können). VonC vor 13 Jahren 0
Ich muss es auf meinem Dev-Server testen ... Ich habe gerade die Schwachstelle während des Tagträumens erkannt und den Fehler so schnell wie möglich behoben. Thomas Hunter vor 13 Jahren 0

2 Antworten auf die Frage

4
grawity

Ja, es ist möglich, den gesamten Inhalt des Repositorys (einschließlich des Verlaufs) herunterzuladen - einfach git clonewäre das möglich. Dies setzt jedoch voraus, dass jemand über das Vorhandensein dieses .gitVerzeichnisses Bescheid wusste ... Wahrscheinlicher ist, dass es niemandem aufgefallen ist. Sie können jederzeit die Protokolle Ihres Webservers überprüfen, um sicherzugehen.

es sei denn, Sie haben einige "Auto-Testing" -Völker dort, die den ganzen Tag für jede URL, die sie sehen, "$ URL / .git / config" krümmen ... :) akira vor 13 Jahren 1
Da sich der .git-Ordner im Stammverzeichnis befindet, hätte nur jemand git clone http://domainname.com ausführen müssen. Und es hätte mit der deaktivierten Verzeichnisliste gearbeitet? Thomas Hunter vor 13 Jahren 0
@Thomas: Git verwendet keine Verzeichnislisten, da ihr Format zwischen den Webservern stark variiert. Alle erforderlichen Informationen sind in "Refs" und "Packed-Refs" enthalten. grawity vor 13 Jahren 0
Danke für den Hinweis. Ich überprüfte meine lighttpd-Zugriffsprotokolle und sah keine Anfragen an das git-Verzeichnis (abgesehen von meiner eigenen panischen Überprüfung heute). Thomas Hunter vor 13 Jahren 0
Diese Kommentare sind nicht wahr. Git ruft den Namen der verschiedenen Paketdateien ab, indem er die Verzeichniseinträge liest. Wenn die Verzeichnislisten des Webservers deaktiviert sind, können Sie die nicht bereitgestellten Einträge nur durch Analysieren von .git / index abrufen Willem vor 9 Jahren 0
@Willem: Ich bin gespannt, wo im Quellcode die Verzeichnisliste analysiert wird und wie mit den Dutzend verschiedenen Formaten umgegangen wird. grawity vor 9 Jahren 1
@grawity: Entschuldigung, lass mich das anders formulieren. In fast jedem Fall der fehlerhaften Veröffentlichung eines .git-Ordners über den http / without / -Verzeichnisindex funktioniert `` `git clone``` nicht, da` `info / refs``` und` `objects / info erforderlich sind / packs```, die standardmäßig nicht existieren. Siehe http://git-scm.com/docs/git-update-server-info und die Antwort von @ SaltwaterC. Ihre Antwort trifft also nur in sehr seltenen Fällen zu. Willem vor 9 Jahren 0
Ich habe gerade einen neuen Computer mit Apache2 installiert und einer der ersten Fehler war von der IP-Adresse `192.40.88.73`, die versucht,` / .git / config` zu erhalten. Ich würde sagen, Sie sollten Ihre Antwort klar aktualisieren und sagen, dass sie 100% öffentlich gemacht wurde. Beenden Sie dann mit den Worten, aber vielleicht hat es niemand gefunden, überprüfen Sie Ihre Protokolle. Alexis Wilke vor 8 Jahren 0
Im besten Fall konnte ich ein paar Hinweise zur Struktur des Repositorys mit DVCS-Pillage oder dvcs-ripper auf einem Server ohne Verzeichnisauflistung erholen (was eine katastrophale schlechte Idee ist). DVCS-pillage hat die Verzeichnisstruktur des Repositorys ohne tatsächliche Daten wiederhergestellt. Für einen Angreifer kann dies interessant sein, da Informationen über die Art der Anwendung verloren gehen können. dvcs-ripper hat einige historische Bits wie die Namen der Zweige und Tags wiederhergestellt, die möglicherweise hilfreich sind. Trotzdem sehr weit davon entfernt, einen vollständigen "Git-Klon" zu erstellen. SaltwaterC vor 7 Jahren 0
2
SaltwaterC

Eine einfache git clonein der Dokumentenwurzel ist nicht ganz genau. Das Klonen eines exponierten GIT-Repositorys ist bei " dummen " Servern nicht möglich, z. B. bei versehentlichem Freigeben von .git über HTTP, sofern dies nicht git update-server-infoauf dem Server ausgeführt wird. Während einige der Metadaten verfügbar sind, ist der Abruf des Inhalts des .git/objectsVerzeichnisses (auch als das saftige Zeug bezeichnet) nicht immer möglich. Objekte, die nicht gepackt sind, können wiederhergestellt werden . Sollte bei einer Arbeitskopie / einem Repository auf einem Produktionsserver nicht der Fall sein.

Dies ist eine andere Geschichte für einen Entwicklungscomputer mit festgeschriebenen Änderungen, die nicht auf eine Fernbedienung übertragen werden. In diesem Fall wird der Garbage Collector normalerweise nicht aufgerufen, es sei denn, Sie werden aufgerufen. git gcDaher sind die Dateien noch nicht Teil von Packfiles. Sie können die Dateien, die seit dem letzten Push festgeschrieben wurden, über HTTP wiederherstellen.

Update-Server-Info erstellt im Grunde eine Karte der Refs (.git / info / refs) und der Packdateien (.git / objects / info / packs). Während mit .git / package-refs die erste ersetzt werden kann, ist das Abrufen der Paketdateien nicht möglich, wenn der Verzeichnisindex nicht aktiviert ist oder die SHA-1 tatsächlich brutal erzwungen wird (was von Anfang an eine schlechte Idee ist).

Siehe auch PoC-Skripts zum Abrufen der .git / index-Refs: https://github.com/evilpacket/DVCS-Pillage und https://k0st.wordpress.com/2012/10/23/rip-or-pillage-dvcs -story-about-git / und https://github.com/kost/dvcs-ripper Willem vor 9 Jahren 1

Verwandte Probleme