How to remediate – Apache ServerTokens Information Disclosure

1. Introduction

The Apache ServerTokens Information Disclosure vulnerability allows remote attackers to gain information about the web server’s configuration via HTTP headers. This can aid in reconnaissance and planning further attacks. Affected systems are typically public-facing web servers running Apache HTTP Server. A successful exploit could lead to a compromise of confidentiality, integrity, and availability through targeted attacks based on disclosed information.

2. Technical Explanation

The vulnerability occurs because the Apache HTTP server’s default configuration includes detailed version and module information in the Server header of its HTTP responses. This information can be easily obtained by an attacker using tools like curl or web browser developer tools. An attacker could use this information to identify known vulnerabilities within specific Apache versions or modules, increasing their chances of a successful attack.

• Root cause: The default configuration of the ServerTokens directive in Apache HTTP Server includes detailed server version and module information in the HTTP response headers.
• Exploit mechanism: An attacker sends an HTTP request to the target web server and examines the Server header for exposed information. This information is then used to identify potential vulnerabilities. For example, an attacker might discover they are running an older version of Apache with a known remote code execution vulnerability.
• Scope: Affected platforms include systems running Apache HTTP Server versions 2.4.0 and later.

3. Detection and Assessment

You can confirm whether your system is vulnerable by checking the HTTP headers returned by your web server. A thorough method involves using a network scanner to identify exposed information across all virtual hosts.

• Quick checks: Use curl -I and inspect the Server header in the output.
• Scanning: Nessus plugin ID 34891 or OpenVAS scanner family Apache HTTP Server Information Disclosure can be used as examples to detect this vulnerability.
• Logs and evidence: Examine web server access logs for requests made by attackers attempting to gather information about your server configuration.

curl -I https://example.com

4. Solution / Remediation Steps

The solution is to change the Apache ServerTokens configuration value to ‘Prod’ which will limit the amount of information disclosed in HTTP headers.

4.1 Preparation

• Ensure you have access to edit the Apache configuration file (typically httpd.conf or apache2.conf). A roll back plan is to restore the original configuration file from backup.
• A change window may be needed if this impacts production services, and approval should be sought from relevant stakeholders.

4.2 Implementation

1. Step 1: Open your Apache configuration file (e.g., /etc/httpd/conf/httpd.conf).
2. Step 2: Locate the ServerTokens directive. If it doesn’t exist, add it to the main configuration section.
3. Step 3: Change the value of ServerTokens to Prod.
4. Step 4: Save the changes to the Apache configuration file.
5. Step 5: Restart the Apache service (e.g., sudo systemctl restart apache2 or sudo service httpd restart).

4.3 Config or Code Example

Before

ServerTokens Full

After

ServerTokens Prod

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate this vulnerability type. Least privilege reduces the impact if exploited, and secure headers prevent information leakage.

• Practice 1: Implement least privilege principles for all server accounts and processes.
• Practice 2: Configure secure HTTP headers to minimize information disclosure.

4.5 Automation (Optional)

# Example Ansible snippet
- name: Set ServerTokens to Prod in Apache configuration
  lineinfile:
    path: /etc/httpd/conf/httpd.conf
    regexp: '^ServerTokens'
    line: 'ServerTokens Prod'
  notify: Restart Apache

5. Verification / Validation

Confirm the fix by checking the HTTP headers after applying the change. The Server header should no longer contain detailed version and module information.

• Post-fix check: Run curl -I again. The Server header should now show minimal information (e.g., just “Apache”).
• Re-test: Re-run the initial detection method to confirm that the detailed server information is no longer exposed.
• Monitoring: Monitor web server logs for any unexpected errors or changes in behavior following the configuration change.

curl -I https://example.com

6. Preventive Measures and Monitoring

Update security baselines to include secure Apache configurations, such as setting ServerTokens Prod. Add checks in your CI/CD pipelines to ensure that new deployments adhere to these standards.

• Baselines: Update a security baseline or policy (for example, CIS Benchmark for Apache) to enforce the use of ServerTokens Prod.
• Asset and patch process: Implement a regular patch review cycle for Apache HTTP Server to address known vulnerabilities promptly.

7. Risks, Side Effects, and Roll Back

Changing the ServerTokens directive may cause compatibility issues with some monitoring tools that rely on detailed server information. The roll back steps are to restore the original configuration file from backup.

• Risk or side effect 1: Some monitoring tools might require adjustments after changing ServerTokens.
• Risk or side effect 2: Incorrectly configuring Apache can lead to service disruptions.
• Roll back:
  1. Step 1: Stop the Apache service.
  2. Step 2: Restore the original configuration file from backup.
  3. Step 3: Restart the Apache service.

8. References and Resources

• Vendor advisory or bulletin: https://www.owasp.org/index.php/SCG_WS_Apache
• NVD or CVE entry: No specific CVE is associated with this configuration issue, but it’s a common information disclosure risk.
• Product or platform documentation relevant to the fix: https://httpd.apache.org/docs/2.4/mod_status.html#servertokens