How to remediate – OS Identification : HTML

1. Introduction

The vulnerability OS Identification : HTML means a remote web server reveals information about the operating system it’s running on. This allows attackers to fingerprint systems, aiding in targeted attacks. Web servers are commonly affected, particularly those hosting public-facing websites or applications. A successful identification could lead to further reconnaissance and exploitation of known OS vulnerabilities, impacting confidentiality, integrity, and availability.

2. Technical Explanation

Nessus identifies the operating system by analysing the HTML headers and content returned when making HTTP requests to the web server. The specific characteristics of this output can indicate which OS is in use. No prior authentication is needed for exploitation, only network access to port 80 or 443. An attacker could use a tool like Nessus or manually inspect responses using `curl` or similar utilities.

• Root cause: The web server’s response includes OS-specific information in the HTML content or headers.
• Exploit mechanism: An attacker sends HTTP requests to the server and analyses the returned HTML for clues about the operating system. For example, specific header fields or comments might reveal details like Windows Server version.
• Scope: Web servers running on various platforms including Linux, Windows, and macOS are potentially affected.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking the web server’s configuration and inspecting HTTP responses. A quick check involves examining the `Server` header. A thorough method uses a vulnerability scanner.

• Quick checks: Use `curl -I ` to view the headers returned by the web server. Look for clues in the `Server` header or HTML source code.
• Scanning: Nessus plugin ID 64381 can identify this vulnerability. Other scanners may have similar checks.
• Logs and evidence: Web server access logs might show requests that trigger the identification, but won’t directly confirm exposure.

curl -I https://example.com

4. Solution / Remediation Steps

The best way to fix this is to configure the web server to hide OS-specific information in its responses.

4.1 Preparation

• Ensure you have appropriate permissions 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 service criticality, with approval from the system owner.

4.2 Implementation

1. Step 1: Modify the web server’s configuration to remove or mask the `Server` header.
2. Step 2: Restart the web server service to apply the changes.

4.3 Config or Code Example

Before

# Apache example (httpd.conf)
ServerSignature On

After

# Apache example (httpd.conf)
ServerSignature Off
ServerTokens Prod

4.4 Security Practices Relevant to This Vulnerability

Practices that reduce the attack surface and limit information disclosure are relevant here.

• Practice 1: Least privilege – configure web server processes with only necessary permissions, reducing potential impact if exploited.
• Practice 2: Secure headers – implement secure HTTP headers to control browser behaviour and hide sensitive information.

4.5 Automation (Optional)

# Example Ansible task for Apache
- name: Disable Server Signature in Apache
  lineinfile:
    path: /etc/httpd/conf/httpd.conf
    regexp: '^ServerSignature On'
    line: 'ServerSignature Off'
  notify: Restart Apache

5. Verification / Validation

Confirm the fix by checking that the `Server` header no longer reveals OS information. Re-run the earlier detection method to verify the issue is resolved.

• Post-fix check: Use `curl -I ` and confirm the `Server` header does not contain OS details or shows only minimal information (e.g., “Apache”).
• Re-test: Run Nessus plugin ID 64381 again; it should no longer report the vulnerability.
• Monitoring: Check web server access logs for unexpected errors following the change.

curl -I https://example.com

6. Preventive Measures and Monitoring

Regular security baselines and configuration management can prevent this issue.

• Baselines: Update your web server security baseline to include a requirement for hiding OS information in responses.
• Pipelines: Include checks in CI/CD pipelines to ensure new deployments adhere to the security baseline, preventing insecure configurations from reaching production.
• Asset and patch process: Review web server configurations regularly as part of an asset management or vulnerability review cycle.

7. Risks, Side Effects, and Roll Back

Changing the `Server` header might cause compatibility issues with some older clients. A roll back involves restoring the original configuration file.

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

8. References and Resources

• Vendor advisory or bulletin: Check your web server vendor’s documentation for specific guidance on hiding OS information (e.g., Apache, Nginx).
• NVD or CVE entry: This is an informational issue so a direct CVE may not exist. Search the NVD database for related OS fingerprinting vulnerabilities.
• Product or platform documentation relevant to the fix: Refer to your web server’s official documentation for configuration options (e.g., Apache httpd documentation).