How to remediate – Git Repository Served by Web Server

1. Introduction

The Git Repository Served by Web Server vulnerability means a web server is unintentionally exposing files from a Git repository. This can allow anyone to download source code, configuration details, and potentially sensitive information. Systems affected are typically those running a web server with direct access to a Git repository directory. A successful exploit could lead to the disclosure of confidential data.

2. Technical Explanation

The vulnerability occurs when a web server is configured to serve files directly from a Git repository without proper restrictions. This allows unauthenticated users to browse and download the contents of the repository using standard web requests. The main exploit path involves simply accessing the repository directory via a web browser or tools like git clone.

• Root cause: Incorrect web server configuration allowing access to Git repository files.
• Exploit mechanism: An attacker uses a web browser or git clone to download the contents of the exposed repository. For example, accessing http://example.com/.git/config could reveal sensitive information about the repository and its users.
• Scope: Web servers (e.g., Apache, Nginx) serving Git repositories directly.

3. Detection and Assessment

To confirm vulnerability, check if a Git repository is accessible via the web server. A thorough method involves attempting to clone the repository using git clone.

• Quick checks: Use a web browser to navigate to the suspected repository URL followed by /.git/config. If this file is displayed, the repository is likely exposed.
• Scanning: Nessus plugin ID b573eafc can identify this vulnerability. This should be used as an example only and may require configuration.
• Logs and evidence: Check web server access logs for requests to /.git/ directories.

# Example command placeholder:
# curl http://example.com/.git/config

4. Solution / Remediation Steps

Fix the issue by verifying that Git repositories are served intentionally and restricting access if they are not needed publicly.

4.1 Preparation

• Ensure you have a rollback plan in case of unexpected issues, such as restoring the previous configuration file.
• Changes should be made during a scheduled maintenance window with appropriate approval.

4.2 Implementation

1. Step 1: Review your web server configuration files (e.g., Apache’s httpd.conf or Nginx’s nginx.conf) for any directives that expose Git repository directories.
2. Step 2: If a directory is exposed unintentionally, add rules to deny access to the /.git/ directory and its contents.
3. Step 3: Restart your web server to apply the changes.

4.3 Config or Code Example

Before

# Apache example - no specific restriction on .git directory
<Directory /var/www/your-repo>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

After

# Apache example - denying access to .git directory
<Directory /var/www/your-repo>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
    <Location /.git/>
        Order deny,allow
        Deny from all
    </Location>
</Directory>

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Least Privilege: Restrict access to sensitive files and directories only to authorized users or services.
• Secure Defaults: Configure web servers with restrictive default settings that prevent unintended exposure of internal resources.

4.5 Automation (Optional)

# Example Bash script to check for .git directory access
#!/bin/bash
for url in $(cat urls.txt); do
  if curl -s "$url/.git/config" > /dev/null 2>&1; then
    echo "Warning: .git directory is accessible at $url"
  fi
done

5. Verification / Validation

Confirm the fix by attempting to access the /.git/config file again after applying the changes. A service smoke test should verify that legitimate web functionality remains operational.

• Post-fix check: Use a web browser or curl to attempt to access http://example.com/.git/config. You should receive a “403 Forbidden” error or similar, indicating access is denied.
• Re-test: Repeat the quick check from Section 3. The /.git/config file should no longer be accessible.
• Smoke test: Verify that other web pages and functionalities on the server are still working as expected.
• Monitoring: Monitor web server access logs for any attempts to access the /.git/ directory, which could indicate ongoing reconnaissance activity.

# Post-fix command and expected output
# curl http://example.com/.git/config
# Forbidden

6. Preventive Measures and Monitoring

Suggest only measures that are relevant to the vulnerability type. Use “for example” to keep advice conditional, not prescriptive.

• Baselines: Update security baselines or policies to include restrictions on exposing internal files and directories via web servers.
• Pipelines: Integrate static analysis tools into CI/CD pipelines to identify potential misconfigurations that could lead to unintended exposure of sensitive resources.
• Asset and patch process: Regularly review web server configurations and apply security patches promptly.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 2: Restarting the web server may cause a brief service interruption. Schedule maintenance during off-peak hours.

8. References and Resources

• Vendor advisory or bulletin: https://blog.skullsecurity.org/2012/using-git-clone-to-get-pwn3d
• NVD or CVE entry: http://www.nessus.org/u?b573eafc