Adventure with .git folder

This post outlines my experiments when i found a .git folder was publicly exposed during one of the pentests and realized all known methods and articles were not helping.

During my recent pentest i found one interesting entry in nikto scan logs :

Now “.git” being exposed online and issues around it are pretty much discussed at multiple places already, I will not go into the details of that. For those interested check here and here.

However as with most of the pen-testing works every scenario is a new scenarios. so here is what i encountered.

1. .git was present and if you call specific file you do get it.
2. Directory indexing was disabled.
3. Not all objects were present on server. and it was a time bound test.
4. All automated tools failed to reconstruct the files for me although they did downloaded .git folder with some success.

Now these tools claim to retrieve all .git folder and then restore the code from it by doing a hard reset of git repository brining back the git content from objects / changelogs, however that soon turned into a nightmare for me.

Most sucessfull tool for me was  “dvcs-ripper” and it did its job quite well till it started getting into endless list of 404’s and this being time restricted i was forced to stop it after running it for 2hrs or so.

and most importantly a git reset on this folder gave me following.

Now as automated tools failed the next option was to get your hands dirty. First thought was to understand the .git folder structure so some quick google search pointed me to this and this 

Now this pointed that I was suppose to look inside .git/objects, so being a linux command-line effectionate : i fired up my command line and first thing that came to my mind was to check what the hell is object files and the results surprized me.

That lead nowhere, and i was clueless what VAX COFF is, so back to google and after first searches lead me to  :

Link : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509942

This cleared the doubts and hence the result was that the files are actually zlib compressed without the zlib header.

The zib decompression options are available with openssl >=1.0.0 (Refer this)

Now considering the files at hand were far more then i can do sanely (>800) Hence i started looking for more options. That’s when i was reminded of a git gui, it kind of solved my problem instantaneously

now this tool clearly showed me the tree structure and allowed me to retrieve specific files by reverting the changes. (Reverting of change as we only had .git and not other files hence repository was considering all files as removed / deleted)

Although as not all objects were downloaded this was not possible to revert entire tree structure but this tool provided a simpler way to restore specific files if there objects were present.

And Hence the journey ends from mere file paths / directory listing disclosed => downloading the whole source => corrupt .git folder => extracting useful content out of broken .git repository.