How to remediate – Apache Tomcat 8.0.0.RC1 < 8.0.32 Multiple Vulnerabilities

1. Introduction

The Apache Tomcat 8.0.0.RC1 < 8.0.32 Multiple Vulnerabilities affect versions of Apache Tomcat prior to 8.0.32. These vulnerabilities could allow attackers to hijack user sessions, gain access to sensitive information like XSRF tokens and deployed application lists, or even execute arbitrary code on the server. Systems running vulnerable versions of Tomcat are at risk. This poses a high impact to confidentiality, integrity, and availability.

2. Technical Explanation

Multiple vulnerabilities exist within Apache Tomcat 8.0.x prior to version 8.0.32 due to flaws in session management, web application handling, and security manager implementations. An attacker could exploit these issues through crafted requests or by leveraging the Manager and Host Manager web applications. CVE-2015-5346 allows session fixation via the requestedSessionSSL field. CVE-2015-5351 discloses information in redirect responses. CVE-2016-0706 exposes deployed application lists, while CVE-2016-0714 and CVE-2016-0763 allow remote code execution and malicious global context injection respectively.

• Root cause: Flaws in session ID validation, insecure redirects, improper access controls to the StatusManagerServlet, and insufficient security checks within the StandardManager and PersistentManager.
• Exploit mechanism: Attackers can exploit these vulnerabilities by sending crafted HTTP requests to vulnerable Tomcat instances, accessing unprotected web application endpoints, or injecting malicious objects into sessions. For example, an attacker could fixate a session ID using CVE-2015-5346 to hijack a user’s authenticated session.
• Scope: Apache Tomcat 8.0.x versions prior to 8.0.32 are affected.

3. Detection and Assessment

Confirming vulnerability requires checking the installed version of Apache Tomcat. A quick check can be done via the Tomcat manager interface, while a thorough assessment involves examining logs for exploitation attempts.

• Quick checks: Access the Tomcat Manager web application and check the server information page to determine the running version.
• Scanning: Nessus vulnerability scan ID 6906ceb2 can detect vulnerable versions of Apache Tomcat based on self-reported version numbers.
• Logs and evidence: Examine Tomcat logs (typically located in the `logs` directory) for suspicious activity related to session management, redirects, or access attempts to sensitive endpoints like `/manager`.

tomcat/bin/version.sh

4. Solution / Remediation Steps

The recommended solution is to upgrade Apache Tomcat to version 8.0.32 or later. While version 8.0.31 addresses some issues, it was not officially released and upgrading to 8.0.32 is advised.

4.1 Preparation

• Ensure sufficient disk space is available for the new version of Tomcat. Coordinate with stakeholders to schedule a maintenance window for the upgrade.

4.2 Implementation

1. Step 1: Download the Apache Tomcat 8.0.32 or later distribution from the official Apache website (https://tomcat.apache.org/download-80.html).
2. Step 2: Stop the existing Tomcat service using the appropriate command for your operating system (e.g., `systemctl stop tomcat`).
3. Step 3: Extract the downloaded Tomcat distribution to a new location.
4. Step 4: Copy the contents of the old configuration directory (`conf`) to the new Tomcat’s `conf` directory, overwriting existing files.
5. Step 5: Copy the web application deployment directory (`webapps`) from the old installation to the new Tomcat’s `webapps` directory.
6. Step 6: Start the upgraded Tomcat service using the appropriate command (e.g., `systemctl start tomcat`).

4.3 Config or Code Example

Before

# No specific configuration changes are required, but ensure you're running an older version.
# Check Tomcat Manager interface for version information.

After

# Verify the upgraded version using the Tomcat Manager interface or command line.
tomcat/bin/version.sh # Should output 8.0.32 or later.

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help mitigate risks associated with this vulnerability type. Least privilege reduces the impact of successful exploitation by limiting attacker access. Input validation prevents malicious data from being processed, and a regular patch cadence ensures timely application of security updates.

• Practice 1: Implement least privilege principles to restrict user and service account permissions.
• Practice 2: Enforce input validation on all user-supplied data to prevent injection attacks.

4.5 Automation (Optional)

# Example Ansible playbook snippet for upgrading Tomcat (use with caution):
- name: Stop Tomcat service
  service: name=tomcat state=stopped
- name: Download Tomcat 8.0.32
  get_url: url={{ tomcat_download_url }} dest=/tmp/tomcat.tar.gz
- name: Extract Tomcat
  unarchive: src=/tmp/tomcat.tar.gz dest=/opt/tomcat
# Add further tasks to copy config and webapps, then restart the service.

5. Verification / Validation

Confirming the fix involves verifying the upgraded version of Tomcat and re-testing for vulnerabilities. A simple smoke test should ensure core functionality remains operational.

• Post-fix check: Access the Tomcat Manager web application and confirm that the server information page displays version 8.0.32 or later.
• Re-test: Run a vulnerability scan using Nessus (ID 6906ceb2) to verify that the vulnerability is no longer detected.
• Smoke test: Verify that key web applications deployed on Tomcat are accessible and functioning as expected.
• Monitoring: Monitor Tomcat logs for any errors or suspicious activity related to session management, redirects, or access attempts to sensitive endpoints.

tomcat/bin/version.sh # Expected output: Apache Tomcat 8.0.32 (or later)

6. Preventive Measures and Monitoring

Update security baselines to include the latest Tomcat version requirements. Implement checks in CI/CD pipelines to prevent deployment of vulnerable versions. Establish a regular patch or configuration review cycle to ensure timely application of security updates.

• Baselines: Update your organization’s security baseline to require Apache Tomcat 8.0.32 or later.
• Asset and patch process: Implement a quarterly patch review cycle for all critical systems, including Apache Tomcat.

7. Risks, Side Effects, and Roll Back

Upgrading Tomcat may introduce compatibility issues with existing web applications or custom configurations. A roll back plan involves restoring the previous configuration and web application deployment directories.

• Risk or side effect 1