How to remediate – Apache HTTP Server Error Page Detection

1. Introduction

The Apache HTTP Server Error Page Detection vulnerability allows attackers to obtain information about the remote web server’s version via a default error page. This can aid in identifying potential targets for further exploitation, leading to reconnaissance and potentially more serious attacks. Systems running Apache HTTP Server are usually affected. A successful exploit could lead to information disclosure.

2. Technical Explanation

The vulnerability occurs because the Apache HTTP Server displays a default error page that includes version details when an error happens. An attacker can simply request a non-existent resource on the server, triggering this error page and revealing sensitive information. There is no known CVE associated with this specific detection method, but it relates to insecure defaults in web server configuration. For example, an attacker could send a GET request to /nonexistentpage.

• Root cause: The Apache HTTP Server includes version details in default error pages.
• Exploit mechanism: An attacker sends a request for a non-existent resource to trigger the default error page and retrieve the server version information.
• Scope: Affected platforms are those running the Apache HTTP Server web server.

3. Detection and Assessment

To confirm if a system is vulnerable, you can check for the presence of the default error page containing version details. A quick check involves sending a request to a non-existent resource and examining the response.

• Quick checks: Use curl -I http://yourserver/nonexistentpage to view the headers and initial content, looking for server version information in the Server header or page body.
• Scanning: Nessus plugin ID 62387 can detect this issue as an example.
• Logs and evidence: Examine web server access logs for requests to non-existent resources that result in error responses (e.g., 404 Not Found).

curl -I http://yourserver/nonexistentpage

4. Solution / Remediation Steps

To fix this issue, you need to configure the Apache HTTP Server to hide version details in error pages.

4.1 Preparation

• Dependencies: Access to the Apache configuration files is required. Roll back plan: Restore the backed-up configuration files.
• Change window needs: A short downtime may be needed, depending on your server setup and restart requirements. Approval from system administrators might be necessary.

4.2 Implementation

1. Step 1: Edit the Apache main configuration file (e.g., httpd.conf or apache2.conf).
2. Step 2: Add or modify the ServerTokens Prod directive to hide version information.
3. Step 3: Restart the Apache service for the changes to take effect.

4.3 Config or Code Example

Before

ServerTokens OS

After

ServerTokens Prod

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue.

• Practice 1: Least privilege – limiting access to configuration files reduces the risk of unauthorized modifications.
• Practice 2: Secure defaults – configuring Apache with secure settings from the start minimizes potential vulnerabilities.

4.5 Automation (Optional)

# Example Ansible snippet - use with caution
- name: Set ServerTokens to Prod in Apache configuration
  lineinfile:
    path: /etc/apache2/apache2.conf # Adjust path as needed
    regexp: '^ServerTokens'
    line: 'ServerTokens Prod'
  notify: Restart Apache

5. Verification / Validation

To confirm the fix worked, check that version details are no longer displayed in error pages.

• Post-fix check: Use curl -I http://yourserver/nonexistentpage and verify that the Server header does not contain detailed version information. Expected output should show only “Server: Apache” without any specific version numbers.
• Re-test: Re-run the quick check from section 3 to confirm that the server version is no longer visible in error pages.
• Smoke test: Verify that basic website functionality still works, such as accessing valid web pages and submitting forms.
• Monitoring: Monitor Apache access logs for unexpected errors or changes in response patterns.

curl -I http://yourserver/nonexistentpage

6. Preventive Measures and Monitoring

Several preventive measures can help avoid this vulnerability.

• Baselines: Update your security baseline to include secure Apache configuration settings, such as ServerTokens Prod.
• Pipelines: Include checks in your CI/CD pipeline to ensure that Apache configurations adhere to the security baseline.
• Asset and patch process: Regularly review and update Apache configurations on all servers.

7. Risks, Side Effects, and Roll Back

Changing ServerTokens may affect compatibility with some monitoring tools or applications that rely on specific version information.

• Roll back: Restore the backed-up Apache configuration files to revert to the previous settings. Restart the Apache service.

8. References and Resources

Links only to sources that match this exact vulnerability.

• Vendor advisory or bulletin: https://httpd.apache.org/docs/2.4/mod_status.html#servertokens
• NVD or CVE entry: No specific CVE is associated with this detection method.
• Product or platform documentation relevant to the fix: https://httpd.apache.org/docs/2.4/