How to remediate – Apache Tomcat Default Files

1. Introduction

The Apache Tomcat Default Files vulnerability refers to the presence of default error pages, index pages, example JSPs, and servlets installed on an Apache Tomcat server. These files can expose information about the Tomcat installation and potentially allow attackers to gain insights into the host system. This affects systems running Apache Tomcat web servers. A successful exploit could lead to information disclosure.

2. Technical Explanation

The vulnerability stems from not removing or modifying default components during initial server setup. An attacker can access these files via a standard HTTP request, revealing version numbers and internal paths. The main risk is information gathering which can aid in further attacks.

• Root cause: Unremoved default Tomcat files.
• Exploit mechanism: An attacker sends an HTTP GET request to the location of the default files (e.g., /manager/html, /examples).
• Scope: Apache Tomcat servers that have not had their default files removed or modified.

3. Detection and Assessment

You can confirm vulnerability by attempting to access the default Tomcat pages. A thorough method involves scanning for known file signatures.

• Quick checks: Accessing http://{target_ip}:8080/manager/html or http://{target_ip}:8080/examples in a web browser. If the default pages are displayed, the system is vulnerable.
• Scanning: Nessus plugin ID 10429 can identify this vulnerability.
• Logs and evidence: Check Tomcat access logs for requests to /manager/html or /examples directories.

curl -I http://{target_ip}:8080/manager/html

4. Solution / Remediation Steps

Remove the default index page and example JSP and servlets to mitigate this vulnerability. Follow Tomcat or OWASP instructions for modifying the error page.

4.1 Preparation

• Ensure you have access to the Tomcat server’s file system. A rollback plan is to restore the backed-up configuration files.
• Changes should be made during a scheduled maintenance window with appropriate approval.

4.2 Implementation

1. Step 1: Delete the default index page (e.g., /webapps/ROOT/index.html).
2. Step 2: Remove the example servlets and JSPs from the /webapps directory.
3. Step 3: Replace or modify the default error page according to Tomcat documentation.

4.3 Config or Code Example

Before

ls /webapps/ROOT

After

ls /webapps/ROOT # Should show only your application files, not index.html

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of exploitation and secure defaults reduce attack surface.

• Practice 1: Implement least privilege principles, limiting access to Tomcat configuration files.
• Practice 2: Enforce secure default configurations during server setup, removing unnecessary components.

4.5 Automation (Optional)

# Example Bash script to remove default files (use with caution!)
#!/bin/bash
TOMCAT_HOME="/opt/tomcat" # Adjust as needed
find "$TOMCAT_HOME/webapps/ROOT" -name "index.html" -delete
find "$TOMCAT_HOME/webapps/" -type d -name "examples" -delete
# Restart Tomcat service after changes
systemctl restart tomcat

5. Verification / Validation

Confirm the fix by attempting to access the default pages again. A negative test should show a 404 error.

• Post-fix check: Accessing http://{target_ip}:8080/manager/html or http://{target_ip}:8080/examples should return a 404 Not Found error.
• Re-test: Repeat the quick checks from Section 3; default pages should no longer be accessible.
• Monitoring: Monitor Tomcat access logs for any unexpected requests to /manager/html or /examples directories.

curl -I http://{target_ip}:8080/manager/html # Expected output: HTTP/1.1 404 Not Found

6. Preventive Measures and Monitoring

Update security baselines to include removing default Tomcat files. Implement checks in CI/CD pipelines to prevent deployment of vulnerable configurations.

• Baselines: Update your server hardening baseline or CIS benchmark to require removal of default Tomcat files.
• Pipelines: Add a static analysis check to your CI/CD pipeline that flags the presence of default Tomcat files in deployments.
• Asset and patch process: Review configurations regularly during patching or asset updates.

7. Risks, Side Effects, and Roll Back

Removing default files could potentially break custom applications relying on them (unlikely). Service interruption is possible if the Tomcat service fails to restart.

• Roll back: Restore the backed-up Tomcat configuration directory and restart the service.

8. References and Resources

• Vendor advisory or bulletin: https://wiki.apache.org/tomcat/FAQ/Miscellaneous#Q6
• NVD or CVE entry: Not applicable, as this is a configuration issue rather than a specific vulnerability with a CVE.
• Product or platform documentation relevant to the fix: https://www.owasp.org/index.php/Securing_tomcat