How to remediate – Web Server Configuration File Detected

1. Introduction

A web server configuration file has been detected on a target host. This means files containing sensitive settings are accessible, potentially allowing attackers to gain privileged information and compromise system security. These vulnerabilities commonly affect systems running Apache, Nginx, IIS and other web servers. A successful exploit could lead to data breaches, service disruption or complete system takeover.

2. Technical Explanation

The vulnerability occurs when web server configuration files are not adequately protected from unauthorised access. An attacker can remotely retrieve these files, exposing credentials, internal paths and other sensitive information. The primary exploit path is direct request to the file location via HTTP or HTTPS. Predictable resource locations make this easier for attackers.

• Root cause: Insufficient restrictions on file system permissions allowing public access to configuration files.
• Exploit mechanism: An attacker sends an HTTP request to a known or guessed configuration file path (e.g., /apache2/httpd.conf).
• Scope: Affected platforms include web servers running Apache, Nginx, IIS and similar software on any operating system.

3. Detection and Assessment

Confirming the vulnerability involves checking for publicly accessible configuration files. A quick check can identify obvious exposures, while a thorough scan will reveal less common locations.

• Quick checks: Use `curl` or a web browser to request known configuration file paths (e.g., curl http://targethost/apache2/httpd.conf).
• Scanning: Nessus plugin ID 10438 can identify exposed Apache configuration files as an example.
• Logs and evidence: Web server access logs may show requests for configuration file paths. Look for HTTP status codes 200 (OK) when accessing these files.

curl http://targethost/nginx/nginx.conf

4. Solution / Remediation Steps

Fixing this issue requires restricting access to web server configuration files or removing them if they are not required. Follow the steps below for a safe and effective remediation.

4.1 Preparation

• Change window: A standard change window may be required depending on your organisation’s policies. Approval from a senior IT administrator is recommended.

4.2 Implementation

1. Step 1: Modify the web server configuration to restrict access to configuration files using appropriate directory permissions or access controls.
2. Step 2: Ensure that only authorised users have read access to these files.
3. Step 3: Restart the web server service to apply the changes.

4.3 Config or Code Example

Before

<Directory /etc/apache2/>
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

After

<Directory /etc/apache2/>
    Options -Indexes FollowSymLinks
    AllowOverride None
    Require local
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of vulnerability. Least privilege is key, limiting the impact if a file is exposed. Input validation and secure defaults also play a role.

• Practice 1: Implement least privilege access control – grant only necessary permissions to users and services.
• Practice 2: Regularly review web server configurations for insecure settings or default values.

4.5 Automation (Optional)

# Example Bash script to restrict access to Apache config files
sudo chmod 600 /etc/apache2/httpd.conf
sudo chown root:root /etc/apache2/httpd.conf

5. Verification / Validation

Confirm the fix by checking that configuration files are no longer accessible via HTTP or HTTPS. A negative test will confirm access is denied.

• Post-fix check: Use `curl` to request a known configuration file path (e.g., curl http://targethost/apache2/httpd.conf). Expected output should be an error message (e.g., 403 Forbidden).
• Re-test: Repeat the initial detection steps and confirm that no configuration files are accessible.
• Monitoring: Monitor web server logs for failed requests to configuration file paths as an example of a regression.

curl http://targethost/apache2/httpd.conf - should return 403 Forbidden

6. Preventive Measures and Monitoring

Regular security baselines, pipeline checks, and asset management can prevent this issue. For example, update a CIS control or policy to enforce file permissions.

• Baselines: Update your web server security baseline to include restrictions on configuration file access.
• Asset and patch process: Implement a regular review cycle for web server configurations, including automated checks for exposed files.

7. Risks, Side Effects, and Roll Back

Incorrectly restricting access can disrupt web server functionality. Ensure you have a clear roll back plan in place.

• Risk or side effect 2: Incorrect permissions can prevent authorised users from modifying configurations. Mitigation: Document all changes and maintain a backup of original files.
• Roll back: Restore the configuration files from your backup. Restart the web server service to apply the previous settings.

8. References and Resources

• Vendor advisory or bulletin: Apache Security Advisories
• NVD or CVE entry: CWE-538
• Product or platform documentation relevant to the fix: Nginx Server Configuration Security