If you get a 403 error, that's normal. It means directory browsing is disabled, which is basic security. However, many files in the .git/ folder could be accessible, putting you at risk.
š·ļø A `.git` folder exploiting tool that is able to restore the entire Git repository, including stash, common branches and common tags.
GitHacker
Desciption
This is a multiple threads tool to exploit the .git folder leakage vulnerability. It is able to download the target .git folder almost completely. This tool also works when the DirectoryListings feature is disabled by brute forcing common .git folder files.
With GitHacker's help, you can view the developer's commit history, branches, ..., stashes, which makes a better understanding of the target repo, even to find security vulnerabilities.
PROCLAMATION (IMPORTANT)
Several VULNERABILITIES have been reported recently, if you are using
GitHacker <= 1.1.0, please update your tool as soon as possible.
The remote .git folder maybe malicious, so to prevent you from being attacked.
It's highly recommended that you SHOULD run this tool under a disposable jailed environment
(eg: Docker container).
Requirments
git >= 2.11.0
Python 3
Usage in Docker (Recommended)
# print help info
docker run wangyihang/githacker --help
# quick start
docker run -v $(pwd)
Anyone can use automated scripts such as the above repository to download your source code and view the entire git history. Git is also a filesystem that follows some conventions, so you can guess directories and files easily.
Most projects use master or main as master branch, so it's easy to guess "hidden" paths in the /.git/ folder. Note that the tool can even brute force branches and tags if that's necessary.
If the scan succeeds, you get a result folder on your local machine (you can customize the folder name with the --output-dir option).
A typical result is the equivalent of git checkout master for free!
Don't deploy the .git/ folder or, at least, forbid access
The .git/ folder can contain lots of information, including the source code itself but also names, mails, and, in the worst-case scenario, hard coded credentials (e.g. databases, tokens, keys).
For a hacker, it's like Christmas!
You should completely disable public access to such folder. Modern CI/CD and deployment solutions are relatively easy to configure and allow cleaning such directories that have nothing to do with the production environment.
Note that some web hosting providers disable access to the folder for security purpose, but it's not always the case and it's not the default configuration, so check it before deploying anything.
I recommend doing all hardenings available. While it might seem a bit overkill, it's often a good idea to take into account any misconfiguration that could occur in the future or a miscalculated migration, so:
Disable public access in the .git/ folder by default on your server
Add a rule to forbid access to the folder in your source code, for example, in the .htaccess file for Apache configurations
Don't even deploy such folder in public directories if that's possible
If you don't want to touch sensitive files such as the .htaccess, you can add a smaller .htaccess at the root of the .git/ folder on your server with just the following line inside:
Deny from all
However, it's even better to return a 404 for the .git/ folder in your server config or main .htaccess, so hackers won't be able to guess anything:
RedirectMatch 404 /\.git
Again, I recommend adding both rules if you can, as two layers of security. In case someone modifies the main .htaccess and delete the rule accidentally, there's still a fallback in the .git/ folder.
When migrating from one server to another, misconfigurations and oversights do happen.
spO0q š
