Today I am going to take a look on a well-known malpractice. During development of any websites and tools the developers often use revision control systems like Git, Bazaar, Mercurial and Subversion. I don’t I need to further explain what these tools are, but I feel like I need to elaborate software deployment and the routines involved.

At a certain point in software development, we deploy the project. There are many tools out there for deploying content in a swift and safe way. These often cost big bucks, so the developers must find other ways to deploy their product. Spinning on the idea of revision control systems, many developers find ways of pushing their code from A to B using said tools. Some developers just copies the source over FTP, while others just updates the source code using, say, Git on the targeted environment. And this is a huge malpractice since these tools leaves traces for us to exploit.

A note on revision control

The reason this is a malpractice is because the tools leaves critical metadata behind. I’ve written this post with Git, Bazaar, Mercurial and Subversion in mind. All of these tools leave behind a “hidden” folder inside the source code structure containing vital information. By hidden I mean folders and files prefixed with a dot (.). In UNIX theory a file or folder prefixed with a dot implies hidden content. This means the content is not revealed using the “ls” command. You will need a special switch for “ls” to show them (“-a”). On Windows this is not an issue. Windows will show anything when listing content. So – the reason I mention this is that developers of today are using Macs, which is UNIX based. So they easily forget these folders and they often tend to end up on production server, as we will see in a later paragraph.

For this attack we will keep an eye on the following “hidden” folders:

  • GIT: .git
  • Mercurial: .hg
  • Bazaar: .bzr
  • Subversion: .svn

It is worth mentioning that Git, Mercurial and Bazaar only uses one folder commonly found at the root of the source folder. Subversion is more greedy and places a .svn folder in each sub-folder present in the structure.

We will be focusing mostly on Git in this attack. This attack can easily be tailored to target the others with minimum customization.


This attack is kind of straight forward and does not need many tools to complete. In essence, we need these tools:

  • A browser. Preferably Google Chrome
  • A downloading tool: Curl or WGet
  • Revision Control Software: Git, Mercurial, Bazaar, Subversion
  • Notepad++ for reviewing content


Finding targets

When finding targets we can go three ways. We can either attack the target if we know the revision control tool used, we can target directly simply guessing  or we could find some random targets. I’ll be covering this latter part.

Finding a random target is easy. We just go searching for them using a Googledork, for instance we can use the following:

inurl:.git “intitle:index.of

By using this dork we instruct Google to return any websites having .git in its URL, and a site title containing “index.of”. By now Google should have presented you with a lot of targets. Technically, you could go on reading the robots.txt file to see if the desired folder is disallowed. But who does that (cough, cough).

Downloading repository information

Make a note of the URL for the target containing the string .git. We now have to choices. We could browse the .git folder directly in our web-browser. But this is time-consuming. Or we could download the entire content of said folder. And that’s what we’ll do.

On UNIX or Cygwin change into a directory of choice and issue the following:

$ wget -r --no-parent target_url_here

Extracting information

Now that we have downloaded the “hidden” folder we can investigate further by using the corresponding source revision tool.

Helpful hints:

  • command: git status
  • command: git log
  • take a look at .git/config

Sometimes looking at the .git/config file I can find information about who’s in charge of the repository, whose account used for deployment and the address to the source repository itself. Most often you’ll find a reference to either Github or Bitbucket – this isn’t exciting. But sometimes I get really lucky finding a reference to an internal IP address which I can use in, say, a penetration test.


I strongly recommend investing time and effort in planning out a deployment routine. I don’t mean to push you into buying an expensive tool for handling deployments. No – I want to push you into learning how the source revision tools works. Often you can find an export method baked into the tool which will strip out these “hidden” folders. You’ll be safer that way. Heck, you can still use, say, Git on your production server. But make sure to add one step. Make Git pull the changes and then copy over the source without the “hidden” folders.