What is .git?

.git

• Current branch state
• Repository description
• History of pretty much everything you've commited, reverted...
• Repository remote address

As you have probably already noticed, those are all things you would want to keep strictly for either yourself, or an authorised personnel.

Attack vector

The attack vector is extremely simple - get the .git directory. If someone grabs your /.git/, he'll also be able to pretty much pull out anything that anyone has put there. And that's the end of your story - your application nearly entirely, or entirely in hands of third party, either to be reverse-engineered and therefore exploited, or sold to whoever would want it. So, how would the attacker do it? The first stage, recon, can be done silently and pretty much invisibly (unless you're actively monitoring for such breach, explained later). All it takes, is internet browser - Chrome, Firefox, whatever - and a simple extension for one of those.

That means trouble.

Keep in mind, that the fact your /.git/ has been discovered, doesn't mean you'll be instantly ripped. You've just been added to the list of found vulnerabilities. The strike may come today, tomorrow, a week later...

The list persists.

Fast-forward a little bit, the attacker knows that you're vulnerable, and has decided on the move - time to actually attack. In the the worst case scenario, he is able to download the whole .git directory using #tools/wget or #tools/curl.

wget --np -r --mirror  --convert-links --adjust-extension http://TARGET/.git/

This command does recursively mirrors .git directory into local computer. Now, each file tracked in .git can be easily restored, at any stage of its existence.

$ cd /tmp/test
$$ ls -la
total 64
drwxr-xr-x  8 core core 4096 Jan 27 16:53 ./
drwxr-xr-x  4 core core 4096 Oct 15 22:13 ../
drwxr-xr-x  2 core core 4096 Oct 15 16:12 branches/
-rw-r--r--  1 core core  109 Oct 15 18:28 COMMIT_EDITMSG
-rw-r--r--  1 core core  487 Oct 15 18:30 config
-rw-r--r--  1 core core   73 Oct 15 16:12 description
-rw-r--r--  1 core core  221 Oct 15 18:30 FETCH_HEAD
-rw-r--r--  1 core core   39 Oct 15 18:30 HEAD
drwxr-xr-x  2 core core 4096 Oct 15 16:12 hooks/
-rw-r--r--  1 core core  449 Oct 15 18:30 index
drwxr-xr-x  2 core core 4096 Oct 15 16:12 info/
drwxr-xr-x  3 core core 4096 Oct 15 16:12 logs/
drwxr-xr-x 11 core core 4096 Oct 15 18:30 objects/
-rw-r--r--  1 core core   41 Oct 15 18:30 ORIG_HEAD
-rw-r--r--  1 core core   46 Oct 15 17:06 packed-refs
drwxr-xr-x  5 core core 4096 Oct 15 16:12 refs/
..
$

$ git status -n
On branch dummy-branch-name
Your branch is up to date with 'origin/dummy-branch-name'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   .gitignore
        deleted:    dummy.cfg

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        dummy-file/

no changes added to commit (use "git add" and/or "git commit -a")

$ git checkout -- .
~/tmp/test on dummy-branch-name ⨯

Done - the source code has been restored, and you just got pwn3d! If tracked files contain secrets, passwords, certificates or private keys, the antagonist of this article, B4dR4lph the hacking doggo, just gained direct access to all of them. If it doesn't contain any sensitive information, he's got the project logic and source code at least. This makes finding weaknesses in the web application way easier, because he don't have to blindly guess, or look for developers' mistakes.

To make things even less palatable, "Not-the-worse-case" scenarios aren't really much better for you - the attacker can still gain valuable insights. It is a little bit more problematic, if he cannot mirror the whole .git directory, but a tiny bit of .git structure know-how

• gitjacker
  [4]
• gittools
  [5]

Detection

There is a simple way to detect, if someone has accessed your .git - normally, your web server shouldn't respond with status code 200, to a request with .git/config path in the request resource identifier. If you see such entry in logs, someone is sniffin' around. There may also be additional entries, refering to other files - basically, if you'll find a log entry with anything .git/ related, it's bad news.

Depending on the costs/budget, we'd also recommend you setting up any monitoring solution you see fit - New Relic, Datadog... Any of them should allow you to set up alerts, in the case of request heading towards unsafe path being logged.

Mitigation

Luckily, Ralph is actually a good boy, despite his nickname. He would never do such mean things to you. Instead, he will teach you how to defend yourself against this threat.

The Dog of Wisdom

This can be achieved in many ways. For instance, if you're using Docker, you can configure the .dockerignore file appropriately:

An example of .dockerignore

.git

On the other hand, you should also block the very specific request patterns on your web server, probably nginx or apache2 - like this:

Snippet of apache2 config

<DirectoryMatch "^/.*/\.git/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

Snippet of nginx config

location ~ /.git/ {
    deny all;
}

As always, it is better to be safe than sorry. Security almost always means redudancy, so we highly recommend you to combine all the mitigation methods described above.