The Dangers of Open Git Folders

Finnish computer scientist, Linus Torvalds, changed the world twice in his lifetime. The first time was roughly 25 years ago when he wrote the Linux kernel; the second was when he developed the revolutionary Git – the open source, distributed version control system (VCS). Git is a great system. However, if you mistakenly deploy the version control system files of your web application in a mode that makes them publicly available, along with your entire website, that could mean game over! In this imaginary scenario, your website’s source code, API tokens, database access passwords would be retrieved by attackers before you take them down. Vladimir Smitka is a Czech security researcher who released his research notes in open Git version control system files. His goal was to identify how common it is to find easily retrievable websites' open Git repositories. In this article, we will take a look at the security risks posed by version control system files, and the solutions in light of Smitka’s research.

How Prevalent Are Open Git Folders?

Let’s begin by analyzing the statistics in Smitka’s research notes:

• After a two-day long scan of Czech websites, he discovered that 1950 out of 1.5 million websites with their Git folder open to public.
• Smitka then conducted a scan of Slovakian websites, uncovered 930 websites with their Git folder open to public

Smitka then enlarged his scope:

• He scanned 230 million domains over four weeks, with a cost of only $250 – surprisingly inexpensive, considering the potential financial impact of just one breach
• This global research resulted in a further list of 390 thousand domains which had their Git directories exposed
• He compiled a detailed list of the specifications of the scanned domains at risk, which included a staggering 189,472 .com domains, followed by 85,202 .top domains

Smitka further enhanced his research by categorizing the results by the technology they used. He reported that vulnerable websites mostly used PHP and Apache servers – not surprising, given the prevalence of these technologies.

The Structure of Git

Let's now look at the structure of Git directories and folders.

This is an xkcd comic, supplied on their website under a Creative Commons license. When you generate a Git repository (repo) using the git init command, a hidden directory with the name '.git' is created in the Git folder. Similarly when you clone a repo, you’ll see that a '.git' directory is also cloned in the repo folder. The .git directory should not be changed if you're not familiar with Git. It’s a sensitive directory that has all the necessary information and files for Git to work, such as the commit history and previous and current versions of the files. This is a sample .git directory.

├── HEAD
├── branches
├── config
├── description
├── hooks
│ ├── pre-commit.sample
│ ├── pre-push.sample
│ └── ...
├── info
│ └── exclude
├── objects
│ ├── info
│ └── pack
└── refs
├── heads
└── tags

In this example, the attacker would have access to all the source code for the website if they could reach the Git repository – including the current and previous versions of the code. Simply put, the .git folder should never be deployed, and if it is, it should never be open to public access.

How to Check if Your Git is Open to the Public

There are several ways to find out whether the .git folder is accessible to the public.

• One of the easiest ways to do this is by trying to access it by navigating to it via the browser (www.example.com/.git/).
  • If the git folder is left in the server by mistake, and directory listing is enabled on your server, this URL will display a list of the contents of the directory.
  • If directory listing is disabled, you might get the 403 error, since the default visible files index.php or index.html are missing in the git directory. But this does not mean that everything is OK.
• Another way to find out whether the folder is open or not is by accessing the URLs www.example.com/.git/HEAD or www.example.com/.git/config.

Since information on the folder structure of Git is widely available, the attacker won’t have any difficulty in finding the code once he’s in the directory. There are also many automated tools to help the attacker. Once the existence of the Git folder is confirmed and directory listing is enabled, it is simply a matter of downloading it using wget in recursive mode:

wget -r http://www.example.com/.git/

If directory listing is disabled you can use one of the readily available tools that allow you to download the folder.

How to Protect Git Folders From Attackers

• Don't leave your .git folder in the production environment! If you can’t do that, you should at least move it out of the root directory, because the web servers are programmed to provide the files in the web root directory only.
• Another method is to block access to all directories that begin with '.' However, the “.well-known” directory is the exception. This directory is defined by RFC 5785 and is used to hold the metadata of the website, such as DNT, Let’s Encrypt validation, and security.txt files. Therefore when you’re setting a rule to block access to files and folders that begin with “.” you should take the following exceptions into consideration:

Nginx:

location ~ /\.(?!well-known\/) {
deny all;
}
 
Apache:
<Directory ~ "/\.(?!well-known\/)">
Order deny,allow
Deny from all
</Directory>

Caddy Server:

status 403 /blockdot
rewrite {
r /\.(?!well-known\/)
to /blockdot
}

Conclusion

In light of Smitka's research, it appears that open Git folders remain a glaring global web application security problem that has not yet been seriously addressed. For now, applying the proper restrictions regarding files that begin with a dot character, as suggested above, will help protect the sensitive .git directory, preventing a large scale takeover of your website. It is important to be sure that you know where your website's folders and files are and whether they can or cannot be accessed by malicious hackers. If you'd like to find out more about the research that inspired this blog post, see Global scan - exposed .git repos.