How to remediate – Tomcat /status Information Disclosure

1. Introduction

The Tomcat /status Information Disclosure vulnerability allows anyone to view details about a running Apache Tomcat web server instance, and reset its statistics. This can provide attackers with information useful for further attacks against the system. Affected systems are typically those running Apache Tomcat web servers exposed to the internet or internal networks. A successful exploit could lead to loss of confidentiality through data disclosure, potential integrity compromise via manipulation of statistics, and limited availability impact if exploited as part of a larger attack.

2. Technical Explanation

The vulnerability occurs because Tomcat’s status page is accessible by default without authentication. Requesting the ‘/status’ URI reveals server information and allows resetting statistics. An attacker can use this to gather details about the Tomcat version, deployed applications, and potentially identify other weaknesses.

• Root cause: Missing or weak access controls on the /status endpoint.
• Exploit mechanism: An attacker sends a simple HTTP GET request to the ‘/status’ URI of the Tomcat server. For example, using a web browser or curl.
• Scope: Apache Tomcat versions 7.0.0 through 10.1 are known to be affected if default configurations remain in place.

3. Detection and Assessment

You can confirm the vulnerability by checking for access to the status page, or scanning with a web application scanner.

• Quick checks: Use a web browser to navigate to http://your-tomcat-server/status. If you see a statistics page, the server is likely vulnerable.
• Scanning: Nessus plugin ID 16384 and OpenVAS scanner family “Web Application Attacks – Tomcat Status Page Information Disclosure” may detect this issue. These are examples only; results should be verified.
• Logs and evidence: Check Tomcat access logs for requests to the ‘/status’ URI. Look for HTTP status codes of 200 OK in response to these requests. The log file is typically located at /tomcat/logs/access_log.*.

curl http://your-tomcat-server/status

4. Solution / Remediation Steps

The best way to fix this issue is to disable the status page if it isn’t needed, or restrict access to trusted users only.

4.1 Preparation

• Ensure you have access to the server.xml configuration file and understand its structure. A roll back plan is to restore from the snapshot or revert the changes made to server.xml.
• A change window may be required depending on your organisation’s policies, and approval from a system owner might be needed.

4.2 Implementation

1. Step 1: Edit the server.xml file. Locate the <Host> element for your web application.
2. Step 2: Add or modify the following attribute to disable access to /status: access="restricted" within the <Context> tag.
3. Step 3: Restart the Tomcat service to apply the changes.

4.3 Config or Code Example

Before

<Context path="/example" docBase="example" reloadable="true">

After

<Context path="/example" docBase="example" reloadable="true" access="restricted">

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this type of issue. Least privilege is important, limiting the impact if an attacker gains access. Input validation can block malicious requests. Safe defaults reduce the attack surface by disabling unnecessary features.

• Practice 1: Implement least privilege principles to restrict access to sensitive resources like the Tomcat status page.
• Practice 2: Regularly review and harden default configurations, disabling unused features or services.

4.5 Automation (Optional)

# Example Ansible task to modify server.xml
- name: Restrict access to Tomcat status page
  lineinfile:
    path: /opt/tomcat/conf/server.xml
    regexp: '<Context path="/example" docBase="example"'
    line: '<Context path="/example" docBase="example" reloadable="true" access="restricted">'
  notify: Restart Tomcat

5. Verification / Validation

Confirm the fix by checking that you can no longer access the status page without authentication, or re-running the earlier detection method.

• Post-fix check: Use a web browser to navigate to http://your-tomcat-server/status. You should receive an HTTP 403 Forbidden error.
• Re-test: Re-run the curl command from step 3 of Detection and Assessment. It should now return an HTTP 403 Forbidden error.
• Monitoring: Check Tomcat access logs for continued attempts to access /status. An alert could be created if requests to this URI exceed a defined threshold.

curl http://your-tomcat-server/status

6. Preventive Measures and Monitoring

• Baselines: Update your server hardening baseline to require restricted access to the /status endpoint by default.
• Asset and patch process: Review and apply security patches for Tomcat on a regular basis, at least quarterly or when critical vulnerabilities are announced.

7. Risks, Side Effects, and Roll Back

Restricting access to the status page may impact monitoring tools that rely on it. If you encounter issues, revert the changes made to server.xml.

• Risk or side effect 1: Monitoring tools relying on the /status page may stop receiving data. Mitigate by configuring alternative monitoring methods.
• Risk or side effect 2: Incorrectly modifying server.xml could prevent Tomcat from starting. Mitigate by taking a snapshot before making changes and having a backup of the original file.
• Roll back: 1) Stop the Tomcat service. 2) Restore the original server.xml file. 3) Restart the Tomcat service.

8. References and Resources

• Vendor advisory or bulletin: https://security.apache.org/advisories/
• NVD or CVE entry: https://nvd.nist.gov/vuln/detail/CVE-2019-17571
• Product or platform documentation relevant to the fix: https://tomcat.apache.org/whichversion.html