Nexus Intelligence Insights: What's in a Ghostcat? CVE-2020-1938 Apache Tomcat - Local File Inclusion Potentially Leads to RCE

For this month’s Nexus Intelligence Insights, let’s dive deep into the popular Ghostcat vulnerability making headlines recently.

This vulnerability deserves attention as it impacts the widely used Apache Tomcat web server, has at least 5 exploits publicly available on GitHub and ExploitDB, and has a rather simple, yet overlooked, root cause. In fact, no version of Tomcat released in the last 13 years is immune to Ghostcat, unless properly patched.

The vulnerability, left unresolved, could pave an easy way for attackers to access arbitrary files on the server. The files may very well divulge sensitive information such as proprietary source code, stored passwords, API tokens, etc. More advanced PoCs can let malicious actors cause even further damage by remotely executing code on the system and planting backdoors, if they are able to get their hands on juicy bits of information.

What’s more? “Mass scanning activity targeting this vulnerability has already begun,” according to Bad Packets and evident from Shodan, thereby prompting immediate attention and a speedy remediation of this issue.

Type of Vulnerability: CWE-20 / Improper Input Validation leading to Local File Inclusion.

Severity:

CVSS 3.1 Score: 9.8
CVSS 3.1 Metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Affected components

as present in Maven Central
org.apache.tomcat:tomcat
org.apache.tomcat:tomcat-coyote

Vulnerable version ranges:

[9.0.0.M1, 9.0.31),
[8.0.0-RC1, 8.5.51),
( , 7.0.100)

The Nitty Gritty and Attack Mechanics

Dubbed CVE-2020-1938, CNVD-2020-10487 and informally “Ghostcat,” the vulnerability occurs due to AJP protocol support in Tomcat being enabled by default.

As is standard practice, most web server programs provide for a variety of protocols to be supported and make this possible by keeping several ports open by default, and by constantly “listening” on them for incoming traffic. These of course include, port 80 for HTTP and 443 for HTTPS. Tomcat additionally supports Apache Jserv Protocol (AJP) and consequently “listens” on 8009 by default.

Unlike its sibling protocols however, AJP is a “highly trusted” protocol by design, and should never be exposed to untrusted clients. While common wisdom suggests keeping this port closed at all times unless a carefully vetted use-case provides otherwise, versions of Tomcat shipped all these years have had a simple one-liner configuration keeping it open:

Image credit: Vulnerable code in Tomcat (GitHub)

Such files could then help the attacker deduce classified information and escalate further attacks on a system’s security. For example, what if the attacker can get their hands on API keys and passwords stored in a local file? Or view the server-side security logic built into the source code? The possibilities are endless.

A simple PoC script trivializes this exploit even further for script-kiddies out there:

python poc.py -p 8009 -f "/WEB-INF/web.xml" 127.0.0.1

Imagine the potential for damage should an attacker decide to employ one of the PoCs to fetch your most guarded secrets!

The fix published by Apache is rather simple and mainly consists of commenting out this very line in the configuration file, server.xml. Doing so disables the AJP/1.3 protocol support by default, effectively resolving the flaw.

Image credit: Fix made by commenting out the vulnerable configuration (GitHub)

Sonatype customers and users of Nexus Lifecycle were notified of this vulnerability within hours of disclosure and received the following information:

Sonatype’s Explanation:

Apache Tomcat contains an arbitrary file read/inclusion vulnerability. The conf/server.xml file enables the Apache JServ Protocol (AJP) connector by default, which listens on port 8009. Additionally, the constructor and the createProcessor() method in the AbstractAjpProtocol class, the constructor in the AjpAprProtocol, AjpProtocol, and AjpNioProtocol classes, and the prepareRequest() method in the AbstractAjpProcessor, AjpProcessor, and AjpAprProcessor classes accept arbitrary request attributes and fail to enforce the requiredSecret for AJP connections. A remote attacker can leverage this behavior to read arbitrary files from the affected server via AJP connections, or to perform Remote Code Execution (RCE) by uploading files of certain types, such as JavaServer Pages (JSP), if the application allows users to upload files to the document root directory.

Remediation and Recommendation:

We recommend upgrading to a version of this component that is not vulnerable to this specific issue. The version-specific upgrade advice is as follows:

For 9.x, upgrade to 9.0.31
For 8.x, upgrade to 8.5.51
Users of Tomcat versions 7.x and earlier may upgrade to 7.0.100

Alternatively, if upgrading is not a viable option, this vulnerability can be mitigated by disabling the AJP connector via the conf/server.xml configuration file.

Note: If this component is included as a bundled/transitive dependency of another component, there may not be an upgrade path. In this instance, we recommend contacting the maintainers who included the vulnerable package. Alternatively, we recommend investigating alternative components or a potential mitigating control.

---

DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of the hackers. Customers of Sonatype Nexus were notified of CVE-2020-1938 within hours of the discovery. Their development teams automatically received instructions on how to remediate the risk.

If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to quickly find out.

Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one. Or subscribe to automatically receive Nexus Intelligence Insights hot off the press.