In the twisted times of modern technology era it is often unsafe to assume, that you're safe. Today's topic is .git
- one of the primary examples, how you can accidentaly hack yourself by an extremely simple, even trivial, overlook.
We will explain, what is .git
directory, how it can be used by the attacker to run away with a copy of your code, how to spot such vulnerabilities in your infrastructure, and what should be done to keep the danger away.
What is .git
?
.git
.git
directory, to store everything it needs to keep - either files, or directories with files in them. For example:- 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
- gittools
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.
The end?
As you have probably noticed, this article has "How people hack themselves" in the title, yet we mentioned malicious actors, "hackers" et cetera, et cetera. Yes, that's true.
But, as you can also see, exposing .git
means doing most of the job for the attacker. Leaving such vulnerability open, is pretty much leading the enemy by hand into your secrets - therefore, i think we could agree on calling this unfortunate overlook "The (un)conscious act of hacking yourself"
Anyways, that would be all for today. Stay healthy, at least a tiny bit more secure, and have a good day ;)
References
- The .git directory explained - Toolsqa. (n. d.). https://www.toolsqa.com/git/dot-git-folder/ (accessed February 5, 2021).
- Git version control system - official website. (n. d.). https://git-scm.com/ (accessed February 5, 2021).
- Git Internals - How Git Works - Fear Not The SHA! on YouTube. (n. d.). https://www.youtube.com/watch?v=P6jD966jzlk (accessed February 5, 2021).
- liamg/gitjacker on GitHub. (n. d.). https://github.com/liamg/gitjacker (accessed February 5, 2021).
- internetwache/GitTools on GitHub. (n. d.). https://github.com/internetwache/GitTools (accessed February 5, 2021).