How to remediate – SAP Netweaver Application Server (AS) HTTP Server Detection

1. Introduction

The SAP Netweaver Application Server (AS) HTTP Server Detection vulnerability means the version number of a remote SAP system can be obtained. This allows attackers to identify systems running potentially vulnerable software, which is a first step in planning an attack. Affected systems are typically business-critical SAP installations. A successful exploit could lead to information disclosure.

2. Technical Explanation

This vulnerability occurs because the HTTP banner of the Netweaver Application Server exposes its version number. An attacker can simply connect to the server and read this banner. No authentication is required. This allows attackers to fingerprint the system, enabling them to target known vulnerabilities in specific versions.

• Root cause: The SAP Netweaver AS HTTP server includes the version number in its default HTTP response header.
• Exploit mechanism: An attacker uses a simple network connection (e.g., using `curl` or `telnet`) to connect to port 80 or 443 of the target system and reads the HTTP banner. For example, connecting to an SAP server on port 80 will often reveal the version in the ‘Server’ header.
• Scope: All systems running SAP Netweaver Application Server (AS) are potentially affected. Specific versions are not inherently vulnerable; however, knowing the version allows attackers to target known weaknesses within that version.

3. Detection and Assessment

You can confirm a system is vulnerable by checking the HTTP response headers. A thorough method involves using a network scanner.

• Quick checks: Use `curl` or `telnet` to connect to port 80 or 443 of the SAP server and examine the ‘Server’ header in the response.
• Scanning: Nessus plugin ID 16972 can detect this issue. OpenVAS also has relevant scans, but results may vary. These are examples only.
• Logs and evidence: HTTP access logs on the webserver will show connections from scanning tools or manual probes. Look for requests to standard SAP paths.

curl -I https://your-sap-server.example.com

4. Solution / Remediation Steps

The primary solution is to prevent the HTTP server from exposing its version number. This involves configuring the webserver settings.

4.1 Preparation

• Ensure you have access to the webserver configuration files and understand their structure. A roll back plan is to restore from the snapshot or backup.
• A change window should be planned with appropriate approvals from system owners.

4.2 Implementation

1. Step 1: Access the SAP Netweaver AS webserver configuration file (e.g., `httpd.conf` or similar, location varies by OS and installation).
2. Step 2: Locate the setting that controls the ‘Server’ header. This may be a directive like `ServerTokens Prod` or similar.
3. Step 3: Modify the setting to hide the version number. For example, set `ServerTokens Prod` to prevent the server version from being displayed.
4. Step 4: Restart the SAP Netweaver AS webserver for the changes to take effect.

4.3 Config or Code Example

Before

ServerTokens OS
Server: Apache/2.4.57 (Unix) PHP/8.1.10

After

ServerTokens Prod
Server: Apache

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of issue. Least privilege reduces the impact if exploited, and secure defaults minimise unnecessary information disclosure. Patch cadence ensures systems are up-to-date with the latest fixes.

• Practice 1: Least privilege – restrict access to SAP systems only to authorised users and services.
• Practice 2: Secure defaults – configure all services with minimal functionality enabled and unnecessary features disabled.

4.5 Automation (Optional)

# Example Ansible snippet - adjust paths for your environment
- name: Hide SAP Netweaver AS version in Apache config
  lineinfile:
    path: /etc/httpd/conf/httpd.conf # Adjust path as needed
    regexp: '^ServerTokens'
    line: 'ServerTokens Prod'
  notify: Restart Apache

5. Verification / Validation

• Post-fix check: Use `curl -I https://your-sap-server.example.com` and verify the ‘Server’ header only shows “Apache” or similar, without a specific version number.
• Re-test: Re-run the earlier detection method (e.g., `curl`) to confirm that the version number is no longer visible in the HTTP response headers.
• Monitoring: Monitor webserver logs for unexpected errors or changes in behaviour following the configuration update.

curl -I https://your-sap-server.example.com

6. Preventive Measures and Monitoring

Update security baselines to include this check, and add checks in CI/CD pipelines to prevent similar configurations. A regular patch or config review cycle is also sensible.

• Baselines: Update your security baseline or policy to require hiding the server version number in HTTP headers for all webservers.
• Pipelines: Add a static analysis check (SAST) to your CI/CD pipeline that flags any configuration files with exposed server versions.
• Asset and patch process: Implement a regular review cycle for system configurations, including SAP systems, to ensure compliance with security standards.

7. Risks, Side Effects, and Roll Back

Changing the webserver configuration could potentially cause compatibility issues with some applications. The roll back steps involve restoring the original configuration file or reverting the changes made in step 3.

• Risk or side effect 2: Some applications might rely on specific server version information, although this is rare. Mitigation is thorough testing of key functionality.
• Roll back: Restore the original `httpd.conf` file from backup. Restart the SAP Netweaver AS webserver to apply the changes.

8. References and Resources

• Vendor advisory or bulletin: https://www.sap.com/products/netweaver-platform.html
• NVD or CVE entry: No specific CVE is associated with this information disclosure, but it’s a common configuration issue in many web servers.
• Product or platform documentation relevant to the fix: https://help.sap.com/doc/aba/46c4d25708b81e2cecd10a3f96a8