Why the .git folder is dangerous (a showcase)
In this blog article I will demonstrate how dangerous a public .git folder can be.
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.
Please note that the name of the company and the affected URLs are not mentioned in the following article. This was a decision as a result of the Responsible Disclosure procedure.
What is this blog article about?
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.
Please be assured that all screenshots shown personal data are censored. All data and files from this company have been removed from my Computer. No data has been leaked to public or otherwise published.
Let's start with a proof of concept.
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.
There are many ways to expose this directory. The easiest way might be to use tools like GitTools. It's also no problem to curl the directories/files and simply run local a git checkout -- . which tells Git to checkout files by name/path in the current directory. That command basically recreates the source code from existing git. Anyway, i used the extractor.sh to get the data:
Analyse the source code
After i got access to the full source code I could analyse it and search for credentials and other vulnerabilities. It didn't take 5 Minutes to find a file named inv-export.php. The really interesting part was that username and password were given in plaintext directly in the file ?. Ok, there are credentials but what is this file doing anyway? After reading the first few lines of code it was very obvious that a customer and sale model was used to collect data directly from the database after a succesfull login though this "authentication process".
Ok, let's try to call that file in the live enviroment. I just had to change the domain from dev to prod and keep the path. Bingo! The file was existing. I checked some other resources in this context and they were all last modified on Tue, 12 Jan 2021 08:51:06 GMT. The checked file i got from git was commited 2018. So, did they changed something? Well.. no. The login worked anyway which means they didn't changed that hardcoded credentials for 4 years. After logged in I was able to download data from customer orders of all shop instances.
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. ?
But there is more...
Let's check the given config files. As you can see they are using a relational database service from Amazon which is a cloud based database. They are using a Aurora MySQL DB cluster.
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.
How can this still happen today?
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:
RewriteRule ^.*\.git.* - [R=404]
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.
The Coordinated Vulnerability Disclosure process
Since this find was not just about a security vulnerability, but large amounts of personal data leaked out, I had to think carefully about how to report this to the operator.
I know from experience that direct contact with the operator is often not effective and there is a risk, too: As long as the hacker paragraph (202 StGB) in Germany is not abolished, the hacker has committed a crime, regardless of the motives or intentions. So, a white hat can get real problems like Lilith Wittmann last year. She noticed that a mobile app from CDU (a german political party) has some seriouse problems: She was able to read out member data via an public insufficiently protected API. After reporting the vulnerability to the party she received no thanks, but got a criminal complaint from LKA.
So what now? There is also the possibility to report security vulnerability anonymously. In Germany, this could be reliably done via the CCC or via the BSI (CERT Bund). There is an intersting blog article (in german language) about that. It titled "Deine Software, die Sicherheitslücken und ich" (Eng. "Your software, the security vulnerabilities and I") by ZERforschung. I really recommend reading this article which got me in the right direction.
In my case i reported the vulnerability to the BSI which was really unproblematic. They conteacted the company and the devs fixed the problem.