How to remediate – Web Server Detection (HTTP/1.1)

1. Introduction

A web server is running on a port and responding to HTTP/1.1 requests while ignoring HTTP/1.0 requests. This is an unusual configuration that may indicate older, less secure protocols are still enabled. Affected systems typically include any device hosting a web service, such as application servers, load balancers, or proxy servers. A successful exploit could allow attackers to bypass security checks and potentially gain access to sensitive information. Confidentiality, integrity, and availability may all be impacted.

2. Technical Explanation

The issue occurs when a web server is configured to only accept HTTP/1.1 requests, effectively disabling support for the older HTTP/1.0 protocol. While not directly exploitable as a vulnerability in itself, this configuration can mask other underlying weaknesses or indicate outdated software versions. Attackers may attempt to exploit vulnerabilities specific to HTTP/1.0 if they believe it is supported. There are no known CVEs associated with this detection alone. An attacker could attempt to send an HTTP/1.0 request expecting a response and then probe for further vulnerabilities based on the server’s behaviour.

• Root cause: The web server configuration prioritises HTTP/1.1, ignoring or rejecting HTTP/1.0 requests.
• Exploit mechanism: An attacker sends an HTTP/1.0 request to determine if the server responds. If no response is received, they may assume other protocols are also disabled and move on. However, a misconfigured server might reveal information in error messages or unexpected behaviour.
• Scope: Any web server software (Apache, Nginx, IIS) can be affected depending on its configuration.

3. Detection and Assessment

Confirming this issue involves checking how the web server responds to different HTTP protocol versions. A quick check is to use `curl` with specific headers. Thorough assessment requires a network scan that probes for both protocols.

• Quick checks: Use `curl -I –http1.0 http://:` and `curl -I –http1.1 http://:`. A successful response only with HTTP/1.1 indicates the issue.
• Scanning: Nessus plugin ID 34897 can identify web servers responding to HTTP/1.1 but not HTTP/1.0 (example only).
• Logs and evidence: Web server access logs may show requests using HTTP/1.0 being rejected or ignored. Check log files in standard locations for the specific web server software.

curl -I --http1.0 http://192.168.1.100:80

4. Solution / Remediation Steps

The solution involves ensuring the web server is configured to handle both HTTP/1.0 and HTTP/1.1 requests, or upgrading to a modern protocol like HTTP/2 or HTTP/3. The following steps outline how to address this issue.

4.1 Preparation

• Ensure you have access to modify the web server configuration files. A roll back plan involves restoring the original configuration file.
• A standard change window may be required for production systems, with approval from relevant IT teams.

4.2 Implementation

1. Step 1: Open the web server’s main configuration file (e.g., `httpd.conf` for Apache, `nginx.conf` for Nginx).
2. Step 2: Locate the section defining listener ports and protocol handling.
3. Step 3: Ensure that both HTTP/1.0 and HTTP/1.1 are enabled or upgrade to a newer protocol like HTTP/2. This may involve removing any explicit restrictions on supported protocols.
4. Step 4: Save the configuration file.
5. Step 5: Restart the web server service for the changes to take effect.

4.3 Config or Code Example

Before

Listen 80
<VirtualHost *:80>
  ServerName example.com
  Protocol h2 http/1.1
</VirtualHost>

After

Listen 80
<VirtualHost *:80>
  ServerName example.com
  Protocol h2 http/1.1 http/1.0
</VirtualHost>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue and related vulnerabilities. Least privilege reduces the impact if a server is compromised. Input validation prevents attackers from sending malicious requests. Safe defaults ensure secure configurations are used by default.

• Practice 1: Implement least privilege to limit the damage caused by potential exploits.
• Practice 2: Use input validation to block unsafe data and prevent attacks targeting web server vulnerabilities.

4.5 Automation (Optional)

# Example Ansible playbook snippet to update nginx configuration
- name: Ensure HTTP/1.0 is enabled in Nginx config
  lineinfile:
    path: /etc/nginx/nginx.conf
    regexp: 'Protocol h2 http/1.1'
    line: 'Protocol h2 http/1.1 http/1.0'
  notify: Restart Nginx

5. Verification / Validation

Confirm the fix by checking that the web server now responds to both HTTP/1.0 and HTTP/1.1 requests. Re-run the earlier detection method to verify the issue is resolved.

• Post-fix check: Run `curl -I –http1.0 http://:`. A successful response (status code 200) indicates the fix worked.
• Re-test: Re-run the initial `curl` commands to confirm both HTTP/1.0 and HTTP/1.1 requests are now accepted.
• Smoke test: Verify that basic web functionality, such as accessing the homepage, continues to work as expected.
• Monitoring: Monitor web server access logs for any unexpected errors or rejected requests (example only).

curl -I --http1.0 http://192.168.1.100:80

6. Preventive Measures and Monitoring

• Baselines: Update your security baseline or policy (for example, CIS control 5) to require support for both HTTP versions.
• Pipelines: Include static analysis tools in your CI pipeline to check for insecure web server configurations during development.
• Asset and patch process: Implement a regular patch review cycle to ensure web servers are running the latest security updates.

7. Risks, Side Effects, and Roll Back

Changing the web server configuration could potentially introduce compatibility issues with older clients or applications. A roll back plan involves restoring the original configuration file.

• Risk or side effect 1: Compatibility issues with very old browsers that only support HTTP/1.0 (mitigation: monitor logs for errors).
• Risk or side effect 2: Service interruption if the configuration is incorrect (mitigation: test changes in a non-