Why the .git folder is dangerous (a showcase)

I came across a strong selling company that mainly sells products in the electric mobility and electric battery industries. I wanted to find out more about the online shop and its product range. In fact, the shop belonged to a company that also covers other product lines and operates several shops and brands.

So I checked which domains point to the server and found subdomains pointing to unprotected directories. I actually expected the HTTP status 403 (Forbidden), but got back 200 (OK). My interest was piqued.

Basically a process about how I discovered a vulnerability on a E-Commerce Shop which is basicly a multi shop instance for more than just one business under several domains.

I found a way to download private customer data which includes full names, e-mail adresses, payment information and delivery addresses. I got access to the full private source code which includes other sensitive configuration information and access data.

I had a detailed insight into the company's sales generated by all shops over the last 4 years. We're talking about millions of dollars and more than 500.000 customer data records.

As the title suggests, the starting point of the attack is an unprotected .git directory. Some of you might already know that a non protected .git directory is a "no go". It was only at the beginning of this year that the Chaos Computer Club published a report that more than 50 leaks with 6.4 million data sets were found and reported via the CCC in a few weeks alone. The "public .git folder vulnerability" (CWE-527) has also been listed as one of the common attack scenarios.

My article takes up the topic again precisely because it is (unfortunately) still a common problem which needs definitly more attention.

I think i don't have to mention why an enabled apache directory listning is never a good idea unless you really want to have that setting enabled. Well, in this case it was enabled and it was no problem to find the .git directory by bursting the url path.

Each line in this CSV file indicates an order. To get an idea of ​​how much personal data could have leaked here over the last few years, you can put this together by looking at the small distances between the dates and times in the first column. ?

Too bad, they were saving such data via version control. Its a good advice to use environment variables for that or just .gitignore it. Anyway, after having full access to the development, staging and production databases, I stopped my research. At this point I had almost full control over the entire system.

This mostly happens due to incorrect deployment. There are developers who deploy their app to production or unprotected development instances using the Git clone method. They clone their repository and keep the .git folder in the web root. As you see, it becomes a real problem if this folder is publicly accessible.

Some of you say at this point that a build process is basically missing here. npm etc. Correct because then the .git folder could (for example) remain outside the document root. However, this is not always given and depends on the choosen technology.

But note: Even a Git directory in the documtent root with a disabled directory listing can be read out. Since the structure of the stored files follows a known scheme, it is also possible here to turn on the dirbuster and find important files at random.

It is all the more important to ensure that a .git directory is subsequently deleted or made inaccessible if it's exist. One solution (in this case apache) could be done via .htaccess or VirtualHost configuration:

the webserver now returns a 404 (not found) when someone tries to expose the directory. If you are not using apache you can google how to set a rewrite rule for your specific webserver.