Www/.git/config

Key Takeaways

• Critical Vulnerability: An exposed /.git/config file is a high-severity information disclosure vulnerability that can lead to full source code theft.
• Data Leakage: The file often contains remote repository URLs, which may include embedded credentials (usernames/passwords) or internal server addresses.
• Exploitation Chain: Attackers use .git/config to map the repository structure and then use tools like git-dumper to reconstruct the entire project.
• Root Cause: The issue is almost always a misconfigured web server (Nginx, Apache, or IIS) that fails to deny access to "dot-files" in the web root.
• Best Practice: Never deploy the .git directory to a production server; instead, deploy only the build artifacts.
• Immediate Fix: Implement server-level blocks (deny all) for any directory starting with a dot (.).

Introduction

In the modern DevOps lifecycle, version control systems like Git are the backbone of software development. Developers rely on the .git directory to manage history, branches, and remote connections. However, a catastrophic error frequently occurs when the entire project directory—including the hidden .git metadata folder—is uploaded to the web server's public root (often denoted as /var/www/html or www/).

When a web server is configured to serve files blindly, the /.git/config file becomes a public asset. This is not merely a minor privacy leak; it is a gateway for attackers. According to various cybersecurity intelligence reports, automated bots scan millions of IP addresses daily specifically looking for the /.git/config path. Finding this file is often the "reconnaissance" phase that precedes a full-scale data breach. In the context of the OWASP Top 10, this falls under Security Misconfiguration and Broken Access Control, both of which remain critical threats to web application security in 2024.

Deep Analysis

The Anatomy of .git/config

The config file within the .git directory is a plain-text file used to store repository-specific settings. While it does not contain the actual source code, it contains the blueprint of the development environment. A typical configuration file includes several critical sections:

• [core]: Contains settings like repositoryformatversion and filemode.
• [remote "origin"]: This is the most dangerous section. It defines the URL of the remote repository (e.g., GitHub, GitLab, or a private Bitbucket instance).
• [branch]: Details about the default branch and tracking information.
• [user]: While less common in the config file itself, environment variables or helper scripts referenced here can leak identity.

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
[remote "origin"]
    url = https://developer_user:P@ssw0rd123!@github.com/company/private-repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*
[branch "main"]
    remote = origin
    merge = refs/heads/main

The Exploit Mechanism: From Config to Code

An attacker does not stop at reading the config file. The exposure of .git/config serves as the primary indicator that the .git directory is accessible. Once an attacker confirms this, they initiate a multi-step exploitation process:

1. Reconnaissance: The attacker requests /path/to/site/.git/config. They extract the remote URL. If the URL contains https://username:password@host, they have immediate access to the remote repository.
2. Directory Mapping: Even if credentials are not in the URL, the attacker knows they can request other files within the .git directory, such as .git/index, .git/HEAD, and .git/refs/heads/main.
3. Automated Reconstruction: Using specialized tools like git-dumper or custom Python scripts, the attacker sends thousands of HTTP requests to download the Git "objects." Git stores file contents in a compressed, hashed format within the .git/objects directory. By downloading these objects and the index file, the attacker can reconstruct the entire source code tree locally on their machine.
4. Secret Extraction: Once the source code is reconstructed, the attacker performs a "grep" search for high-value targets: .env files, config.php, settings.py, API keys, AWS credentials, and database connection strings.

Statistical Context and Risk Assessment

The risk is quantifiable. In a standard enterprise environment, a single repository might contain 500,000 lines of code. If the .git folder is exposed, the "Time to Compromise" (TTC) for an automated bot is often measured in seconds. Unlike a SQL injection, which requires bypassing a WAF (Web Application Firewall) or finding a specific entry point, accessing /.git/config is a direct request to a static file. Unless specifically blocked, the server will return a 200 OK status code, effectively handing the keys to the kingdom to the attacker.

Furthermore, the exposure of internal repository URLs can lead to Lateral Movement. If the URL points to an internal GitLab instance (e.g., git.internal-corp.com), the attacker now has a target for internal network scanning and further exploitation within the corporate intranet.

Comparison / Alternatives

Understanding how different web servers handle these requests by default is crucial for administrators. Below is a comparison of default behaviors and the necessary hardening steps.

Common Mistakes / Misconceptions

Another common mistake is relying solely on .gitignore. Many developers believe that because they added certain files to .gitignore, those files are safe. However, .gitignore only prevents files from being tracked by Git; it does nothing to prevent the .git directory itself from being served by a web server. If the .git folder exists in your web root, the entire history of everything ever tracked in that repository is potentially available.

Finally, there is the misconception that "we don't use passwords in our Git URLs, so we are safe." Even without credentials, the exposure of the repository structure, branch names, and commit history provides enough intelligence for a sophisticated attacker to find vulnerabilities in your application logic.

Expert Tips