For this month's Sonatype Intelligence Insights, let's dive into the popular Ghostcat vulnerability making headlines.
This vulnerability deserves attention, as it impacts the widely used Apache Tomcat web server, has at least five 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 Ghostcat 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 can 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.
Ghostcat Vulnerability Identifier(s): CVE-2020-1938 (aka CNVD-2020-10487)
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 Apache Tomcat shipped all these years have had a simple one-liner configuration keeping it open:
Image credit: Vulnerable code in Tomcat (GitHub)
What this means is, an attacker could send crafted AJP requests to port 8009, which the server would treat with greater trust than an ordinary HTTP request. The malicious request could then cause the server to expose the contents of a local file, such as /etc/passwd. This is just one of the many examples.
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
By running just one line, the script is able to pull local configuration file "web.xml" from a web server running on a particular IP address (loopback address 127.0.0.1 is an example, of course) when its AJP connector is enabled and listening on port 8009.
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)
Customers and users of Sonatype Lifecycle were notified of this Ghostcat 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.
Ghostcat 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. Sonatype customers 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 Sonatype Vulnerability Scanner to quickly find out.
Visit the Sonatype Intelligence Insights page for a deep dive into other vulnerabilities like this one. Or subscribe to automatically receive Sonatype Intelligence Insights hot off the press.
