8

On one of my web applications, I accidentally left the .git directory readable by the web server for the last few weeks. Index listing was disabled. Visiting the website.com/.git URL would result in a 404 error that was indistinguishable from any other 404 error, but browsing to website.com/.git/config for example would download the file.

What kind of risks are there with my applications? Is it possible that enough information is exposed that someone could have downloaded the entire application's source code?

Thomas Hunter
  • 811
  • 1
  • 9
  • 15
  • Did you try a `git clone http://website.com/.git`? That is the major risk (being able to clone the full repo). – VonC Aug 24 '11 at 14:28
  • I'll have to test it on my dev server... I just realized the vulnerability while daydreaming and fixed the bug ASAP. – Thomas Hunter Aug 24 '11 at 14:45

2 Answers2

4

Yes, it's possible to download the entire repository contents (including history) – a simple git clone would do it. However, this assumes someone knew about the existence of that .git directory...it's more likely that nobody has even noticed it. You can always check your web server's logs to be sure.

u1686_grawity
  • 426,297
  • 64
  • 894
  • 966
  • 1
    except if you have some "auto-testing" folks around there which `curl $URL/.git/config` all day long for every url they see ... :) – akira Aug 24 '11 at 14:30
  • With the .git folder being in the root, someone only would have needed to run git clone http://domainname.com? And it would have worked with the directory listing disabled? – Thomas Hunter Aug 24 '11 at 14:41
  • @Thomas: Git does not use directory listings, since their format varies greatly between web servers. All required information is in `refs` and `packed-refs`. – u1686_grawity Aug 24 '11 at 15:05
  • Thanks for the advice. I checked my lighttpd access logs and didn't see any requests to the git directory (other than my own panicked checking today). – Thomas Hunter Aug 24 '11 at 15:19
  • These comments are not true. Git fetches the name of the various pack files by reading the directory entries, so if the webserver dir listings are disabled, you can only fetch the unstaged entries by parsing .git/index – Willem May 02 '15 at 22:31
  • 1
    @Willem: I'm curious where in the source code it performs the directory list parsing and how it deals with the dozen different formats. – u1686_grawity May 02 '15 at 23:45
  • @grawity: sorry, let me rephrase that. In almost any case of erroneously publishing a .git folder through http /without/ directory index, ```git clone``` doesn't work as it requires ```info/refs``` and ```objects/info/packs```, which don't exist by default. See http://git-scm.com/docs/git-update-server-info and @SaltwaterC's answer. So your answer is only true in very rare cases. – Willem May 03 '15 at 08:18
  • I just installed a new computer with apache2 and one of the first errors I got was from IP address `192.40.88.73` trying to get `/.git/config`. I would say, you should update your answer clearly saying that it did make it 100% public. Then finish by saying, but maybe no one found it, check your logs. – Alexis Wilke Sep 25 '16 at 23:33
  • At best I could recover few pointers about the structure of the repository with either DVCS-pillage or dvcs-ripper on a server with no directory listing (which is a catastrophically bad idea). DVCS-pillage recovered the directory structure of the repository with no actual data. For an attacker, it may be interesting as it may leak information about the nature of the application. dvcs-ripper recovered some history bits like the names of the branches and tags which may or may not be helpful. Still, very far away from being able to do a full `git clone`. – SaltwaterC Aug 31 '17 at 09:31
3

A simple git clone on the document root is not entirely accurate. Cloning an exposed GIT repository is not possible with "dumb" servers, such as an accidental exposure of .git via HTTP, unless git update-server-info is executed on the server. While some of the metadata is available, obtaining the contents of the .git/objects directory (aka the juicy stuff) is not always possible. It is possible to recover objects that aren't packed. Should not be the case with a working copy/repository on a production server.

It's a different story for a development machine with committed changes that aren't pushed to a remote. In this case, the garbage collector is not usually called, unless you invoke git gc, hence the files aren't part of packfiles, yet. You may recover via HTTP the files which are committed since the last push.

update-server-info basically creates a map of the refs (.git/info/refs) and of the packfiles (.git/objects/info/packs). While .git/packed-refs may be used to substitute the first, obtaining the packfiles isn't possible without having the directory index enabled or actually brute-forcing SHA-1's (which is a bad idea from the start).

SaltwaterC
  • 181
  • 4
  • 1
    See also PoC scripts to fetch the .git/index refs: https://github.com/evilpacket/DVCS-Pillage and https://k0st.wordpress.com/2012/10/23/rip-or-pillage-dvcs-story-about-git/ and https://github.com/kost/dvcs-ripper – Willem May 03 '15 at 08:28