How to remediate – ModSecurity Version

1. Introduction

The ModSecurity Version vulnerability allows an attacker to determine the version number of a ModSecurity installation. This information can help attackers identify known weaknesses in specific versions and target systems more effectively. Web servers running ModSecurity are usually affected, potentially impacting confidentiality through targeted attacks. The likely impact is low on integrity and availability.

2. Technical Explanation

The vulnerability occurs because ModSecurity includes its version number in HTTP response headers when it handles requests. An attacker can simply send a request to the web server and inspect the header banner to read this information. No specific CVE or CVSS score is currently associated with simply reading the version, but knowing the version enables more targeted attacks.

• Root cause: ModSecurity includes its version number in HTTP response headers by default.
• Exploit mechanism: An attacker sends a standard HTTP request to the server and examines the ‘Server’ header for the ModSecurity version string. For example, using `curl -I https://example.com` might reveal a header like “Server: Apache/2.4.52 (Ubuntu) mod_security/3.6.9”.
• Scope: All web servers running ModSecurity are potentially affected, regardless of the underlying operating system or web server software.

3. Detection and Assessment

• Quick checks: Use `curl -I https://your-website.com` or inspect the HTTP headers in your browser’s developer tools. Look for a line containing “mod_security”.
• Scanning: Nessus plugin ID 163847 can identify ModSecurity installations and their versions, but results should be verified manually.
• Logs and evidence: Web server access logs will show all requests made to the system. These logs do not directly indicate vulnerability, but confirm traffic is reaching the WAF.

curl -I https://example.com

4. Solution / Remediation Steps

The following steps outline how to hide the ModSecurity version number from HTTP headers.

4.1 Preparation

• No specific dependencies exist, but ensure you have access to edit the ModSecurity configuration file. Change windows may be required depending on your organisation’s policies.

4.2 Implementation

1. Step 1: Edit the main ModSecurity configuration file (typically located at `/etc/modsecurity/modsecurity.conf` or `/etc/httpd/conf.d/mod_security.conf`).
2. Step 2: Add or modify the `SecServerSignature` directive to set it to “Off”.
3. Step 3: Save the configuration file and restart your web server service (e.g., `sudo systemctl restart apache2` or `sudo systemctl restart nginx`).

4.3 Config or Code Example

Before

SecServerSignature On

After

SecServerSignature Off

4.4 Security Practices Relevant to This Vulnerability

List only practices that directly address this vulnerability type. Use neutral wording and examples instead of fixed advice. For example: least privilege, input validation, safe defaults, secure headers, patch cadence. If a practice does not apply, do not include it.

• Practice 1: Secure Headers – configuring web server headers to remove unnecessary information like version numbers reduces the attack surface.

4.5 Automation (Optional)

# Example Bash script to modify modsecurity.conf
sudo sed -i 's/SecServerSignature On/SecServerSignature Off/' /etc/modsecurity/modsecurity.conf
sudo systemctl restart apache2 # Or nginx, depending on your server

5. Verification / Validation

• Post-fix check: Run `curl -I https://your-website.com`. The ‘Server’ header should not include “mod_security”.
• Re-test: Repeat the initial detection method (inspecting HTTP headers) to confirm that the ModSecurity version is no longer visible.
• Monitoring: Monitor web server logs for any unexpected errors or changes in behaviour following the configuration change.

curl -I https://example.com

6. Preventive Measures and Monitoring

For example, regularly review your web server configurations to ensure secure headers are properly set and unnecessary information is removed.

• Baselines: Update your security baseline or policy to include a requirement for disabling `SecServerSignature`.
• Pipelines: Incorporate SAST tools into your CI/CD pipeline to scan configuration files for insecure settings like `SecServerSignature On`.
• Asset and patch process: Implement a regular review cycle for web server configurations, at least quarterly.

7. Risks, Side Effects, and Roll Back

Disabling the `SecServerSignature` directive does not introduce significant risks. However, it may slightly reduce debugging information available in logs. The roll back steps are to restore the original configuration file.

• Risk or side effect 1: Reduced debugging information – disabling the server signature removes a potential source of information for troubleshooting.
• Roll back: Restore the original `modsecurity.conf` file and restart your web server service.

8. References and Resources

• Vendor advisory or bulletin: ModSecurity Reference Manual
• NVD or CVE entry: No specific CVE exists for simply reading the version, but information on ModSecurity vulnerabilities can be found at NIST NVD.
• Product or platform documentation relevant to the fix: Apache Security Documentation (if using Apache).