How to remediate – Git Repository Detected

1. Introduction

The vulnerability is a detected Git repository accessible via the web server. This means files from your project’s version control history may be readable by unauthenticated users, potentially exposing sensitive information like code, configuration details, and commit logs. This affects systems running web servers with publicly accessible Git repositories. Confidentiality of source code and other data could be compromised.

2. Technical Explanation

The root cause is improper access control on the .git directory within a web server’s document root. Attackers can directly request files from this directory to retrieve repository contents. Exploitation requires only network access to the affected web server and knowledge of the repository’s location. An attacker could, for example, download the entire project history by iterating through the .git/objects directory.

• Root cause: Missing or incorrect configuration preventing direct access to the .git directory.
• Exploit mechanism: An attacker requests files directly from the .git directory via HTTP(S). For example, https://example.com/.git/HEAD reveals the current branch.
• Scope: Web servers (Apache, Nginx, IIS) hosting Git repositories without proper access controls are affected.

3. Detection and Assessment

Confirming vulnerability involves checking for accessible .git directories. A quick check can be done via a web browser, while thorough assessment requires scanning the entire web application.

• Quick checks: Attempt to access https://example.com/.git/HEAD in a web browser. If you see repository information, it is vulnerable.
• Scanning: Use vulnerability scanners like OWASP ZAP or Burp Suite with active scanning enabled, looking for exposed .git directories.
• Logs and evidence: Web server access logs may show requests to the .git directory from suspicious IP addresses.

curl -I https://example.com/.git/HEAD

4. Solution / Remediation Steps

Fixing this issue requires restricting or removing access to the .git directory.

4.1 Preparation

• Ensure you have a rollback plan in case of unexpected issues, such as restoring from backup. A change window is recommended for production systems.

4.2 Implementation

1. Step 1: Configure your web server to deny access to the .git directory.
2. Step 2: If the repository is no longer needed, remove the .git directory entirely from the web server’s document root.

4.3 Config or Code Example

Before

# Apache .htaccess file (example)
<Directory /var/www/html>
    Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>

After

# Apache .htaccess file (example)
<Directory /var/www/html/.git>
    Require all denied
</Directory>
<Directory /var/www/html>
    Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices help prevent this issue.

• Least privilege: Restrict access to sensitive directories and files only to authorized users or processes.
• Secure configuration: Implement strong access controls on web servers and applications, preventing unintended exposure of internal resources.

4.5 Automation (Optional)

Configuration management tools can automate the denial rule.

# Ansible example task to deny access to .git directory in Apache config
- name: Deny access to .git directory
  lineinfile:
    path: /etc/apache2/sites-available/your_site.conf
    regexp: '^<Directory /var/www/html/.git>'
    insertafter: '^<Directory /var/www/html>'
    line: '<Directory /var/www/html/.git>n    Require all deniedn</Directory>'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Attempt to access https://example.com/.git/HEAD in a web browser. You should receive a 403 Forbidden error or similar.
• Re-test: Re-run the quick check from Section 3. The .git directory should no longer be accessible.
• Monitoring: Monitor web server access logs for any further attempts to access the .git directory, which could indicate ongoing attacks or misconfigurations.

curl -I https://example.com/.git/HEAD

6. Preventive Measures and Monitoring

Preventative measures include regular security baselines and pipeline checks.

• Baselines: Update your web server security baseline to explicitly deny access to .git directories.
• Asset and patch process: Regularly review web server configurations for misconfigurations, including unnecessary exposure of internal resources.

7. Risks, Side Effects, and Roll Back

Incorrect configuration may cause website errors. Restoring from backup is the primary rollback method.

• Risk or side effect 1: Incorrect web server configuration could lead to website downtime. Test changes in a staging environment first.
• Roll back: Restore your web server configuration from the pre-change backup. If you removed the .git directory, restore it from backup as well.

8. References and Resources

• Vendor advisory or bulletin: N/A – This is a common misconfiguration issue rather than a specific vendor vulnerability.
• NVD or CVE entry: CWE-538
• Product or platform documentation relevant to the fix: Refer to your web server’s documentation for access control configuration (e.g., Apache .htaccess, Nginx configuration files).