How to remediate – OS Identification : HTTP

1. Introduction

The vulnerability “OS Identification : HTTP” means that information about a server’s operating system can be found by looking at its responses to web requests. This is useful to attackers planning further attacks, as it helps them target the right exploits. Systems running any web server are usually affected. A successful identification could lead to easier exploitation of known OS vulnerabilities, impacting confidentiality, integrity and availability.

2. Technical Explanation

Nessus identified the operating system by examining data in the HTTP responses. This is often due to the server sending information about itself in headers or error pages. An attacker could use a tool like `curl` or `wget` to request various pages and analyse the response headers for clues about the OS type and version.

• Root cause: The remote HTTP server includes identifiable operating system details within its responses.
• Exploit mechanism: An attacker sends HTTP requests to the server, analyses the returned data (headers, error pages), and uses this information to determine the OS. For example, a request for `/` might reveal “Server: Apache/2.4.53 (Ubuntu)” in the header.
• Scope: Any system running an HTTP server is potentially affected, including Linux, Windows, and macOS servers. Specific versions depend on the web server software used.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking the HTTP response headers or using a vulnerability scanner. A quick check involves examining the `Server` header. More thorough methods use dedicated scanners to analyse all responses for OS-specific information.

• Quick checks: Use `curl -I ` and look at the `Server` header in the output.
• Scanning: Nessus plugin ID 64381 can detect this issue. Other scanners may have similar plugins.
• Logs and evidence: Examine web server access logs for requests that reveal OS information in headers or error messages.

curl -I https://example.com

4. Solution / Remediation Steps

To fix this issue, configure the HTTP server to hide operating system details from responses. This reduces the information available to potential attackers.

4.1 Preparation

• Ensure you have access to modify the web server configuration. A roll back plan is to restore the original configuration file.
• A change window may be needed, depending on your organisation’s policies. Approval from a system owner might be required.

4.2 Implementation

1. Step 1: Edit the web server configuration file (e.g., `httpd.conf` for Apache or `nginx.conf` for Nginx).
2. Step 2: Add or modify the `ServerTokens Prod` directive in Apache, or remove/comment out the `server_tokens on;` line in Nginx.
3. Step 3: Restart the web server to apply the changes.

4.3 Config or Code Example

Before

# Apache httpd.conf
ServerTokens Full

After

# Apache httpd.conf
ServerTokens Prod

4.4 Security Practices Relevant to This Vulnerability

Least privilege can reduce the impact if an attacker gains information about your system. Secure headers help control what information is exposed in HTTP responses. A regular patch cadence ensures you are running up-to-date software with known vulnerabilities fixed.

• Practice 1: Least privilege limits the damage from compromised systems.
• Practice 2: Input validation can prevent attackers from exploiting weaknesses revealed by OS identification.

4.5 Automation (Optional)

If using configuration management tools, you can automate the modification of web server configurations to set `ServerTokens Prod`.

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

5. Verification / Validation

• Post-fix check: Run `curl -I ` and verify that the `Server` header only shows “Apache” or “Nginx”, without version details.
• Re-test: Re-run Nessus plugin ID 64381 to confirm it no longer reports the vulnerability.
• Smoke test: Access your website’s homepage and verify that it loads correctly.
• Monitoring: Monitor web server logs for unexpected errors or changes in response headers.

curl -I https://example.com

6. Preventive Measures and Monitoring

• Baselines: Update your web server hardening baseline to require `ServerTokens Prod` (Apache) or removing `server_tokens on;` (Nginx).
• Pipelines: Add a check in your CI/CD pipeline that scans for exposed OS information in web server configurations.
• Asset and patch process: Review web server configurations regularly as part of your asset management process.

7. Risks, Side Effects, and Roll Back

Changing the `Server` header might cause compatibility issues with some older clients or monitoring tools that rely on specific version information. The roll back steps involve restoring the original web server configuration file and restarting the service.

• Roll back: Restore the original web server configuration file and restart the service.

8. References and Resources

• Vendor advisory or bulletin: Apache ServerTokens Documentation
• NVD or CVE entry: No specific CVE is associated with this information disclosure, but it contributes to overall attack surface.
• Product or platform documentation relevant to the fix: Nginx server_tokens Documentation