1. Introduction
A Mercurial repository metadata directory has been detected on a web server. This means files relating to a version control system are accessible via the web, potentially exposing source code and project history that should be private. Confidentiality is most at risk, but integrity could also be affected if an attacker modifies the repository. The issue typically affects systems running web servers with inadvertently exposed Mercurial repositories.
2. Technical Explanation
The vulnerability occurs when a web server’s configuration allows public access to the .hg directory of a Mercurial repository. This is usually due to incorrect permissions or missing restrictions on directory listing. An attacker can then browse the contents of the .hg directory, downloading files containing source code and commit history. The CWE associated with this issue is 538: Insufficient Access Control.
- Root cause: Incorrect web server configuration allowing access to the .hg directory.
- Exploit mechanism: An attacker simply accesses the .hg directory via a web browser or using tools like `curl`. For example, accessing
- Scope: Web servers running any operating system (Linux, Windows) that host Mercurial repositories are affected.
3. Detection and Assessment
You can confirm the vulnerability by checking for public accessibility of the .hg directory. A thorough assessment involves listing all files within the directory to determine the extent of exposed information.
- Quick checks: Use a web browser to access
- Scanning: Nessus plugin 16825 and OpenVAS scanner ID 93470 can detect this issue as examples only.
- Logs and evidence: Web server access logs may show requests for files within the .hg directory from external sources. Look for GET requests to paths containing /.hg/.
curl -I http://your-server-address/.hg/ 4. Solution / Remediation Steps
The solution is to restrict access to the .hg directory or remove it entirely if no longer needed. Follow these steps carefully to avoid disrupting web server functionality.
4.1 Preparation
- Stopping services is not usually required for this fix, but consider a maintenance window if you are unsure. A roll back plan involves restoring the backed-up configuration.
- Changes should be approved by a senior administrator or security team member.
4.2 Implementation
- Step 1: Edit your web server’s configuration file (e.g., Apache’s httpd.conf, Nginx’s nginx.conf).
- Step 2: Add a rule to deny access to the .hg directory. For example, in Apache, add `
Require all denied `. - Step 3: Restart your web server to apply the changes.
4.3 Config or Code Example
Before
# Apache configuration - no restriction on .hg directory
<Directory "/path/to/your/repository">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>After
# Apache configuration - restricting access to .hg directory
<Directory "/path/to/your/repository">
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
<Directory "/path/to/your/repository/.hg">
Require all denied
</Directory>4.4 Security Practices Relevant to This Vulnerability
Several security practices can help prevent this issue. Least privilege is important, as it limits the impact of an exploit. Secure configuration management ensures that web servers are configured correctly and consistently.
- Practice 1: Implement least privilege by granting only necessary permissions to users and services.
- Practice 2: Regularly review and harden your web server’s configuration, following security best practices.
4.5 Automation (Optional)
If using infrastructure-as-code tools like Ansible, you can automate the configuration change.
# Example Ansible task to deny access to .hg directory in Apache
- name: Deny access to .hg directory
lineinfile:
path: /etc/apache2/sites-available/your_site.conf
regexp: '^<Directory "/path/to/your/repository/.hg">'
insertafter: '^<Directory "/path/to/your/repository">'
line: '<Directory "/path/to/your/repository/.hg">n Require all deniedn</Directory>'
notify: Restart Apache5. Verification / Validation
Confirm the fix by checking that access to the .hg directory is now blocked. A negative test involves attempting to download files from the directory.
- Post-fix check: Use a web browser or `curl` to access
- Re-test: Repeat the quick check from Section 3; you should no longer see a directory listing or Mercurial metadata.
- Monitoring: Monitor web server access logs for any attempts to access files within the .hg directory.
curl -I http://your-server-address/.hg/ 6. Preventive Measures and Monitoring
Update your security baselines to include restrictions on accessing version control metadata directories. Implement CI/CD pipeline checks to prevent accidental exposure of sensitive files.
- Baselines: Update your web server hardening baseline or CIS benchmark to explicitly deny access to .hg directories.
- Pipelines: Add static code analysis (SAST) tools to your CI/CD pipeline to scan for exposed credentials and sensitive data in repositories.
- Asset and patch process: Review web server configurations regularly as part of a vulnerability management program, at least quarterly.
7. Risks, Side Effects, and Roll Back
- Risk or side effect 2: Restarting the web server may cause a brief service interruption. Schedule changes during off-peak hours if possible.
- Roll back: Restore your backed-up web server configuration file. If using infrastructure-as-code, revert to the previous commit in your repository.
8. References and Resources
- Vendor advisory or bulletin: No specific vendor advisory available, as this is a configuration issue.
- NVD or CVE entry: CWE-538
- Product or platform documentation relevant to the fix: Refer to your web server’s official documentation for configuration instructions (e.g., Apache,