Apache Tomcat Vulnerability “Ghostcat” Attracting Threat Actor Attention

By Cheng Lu and Steven Ouellette

Flashpoint analysts observed that a vulnerability identified as CVE-2020-1938 has been attracting threat actor attention since its public disclosure on February 20, 2020. Originally discovered by Chinese security firm Chaitin Technologies, the vulnerability was reported to the Chinese National Vulnerability Database (CNVD) on January 6, 2020, over a month prior to its public disclosure. Identified by the Chinese National Vulnerability Database as CNVD-2020-10487 and known as the “Ghostcat,” the vulnerability is also identified as CVE-2020-1938. It affects a large range of Tomcat versions from its 7.0, 8.5, and 9.0 branches.

The vulnerability is described as having the capability for remote code execution on a popular web server without authentication and user interaction, which means it may be an ideal target for exploitation. Flashpoint analysts have analyzed the vulnerability and verified the publicly available proof-of-concept (PoC) code.

Tactics, Techniques, and Procedures (TTPs)

Apache Tomcat is a lightweight HTTP web server that supports a variety of Java-based web technologies, such as Java Servlet and JavaServer Pages. Originally released in 1999, Tomcat has been part of the open-source Apache Software Foundation collection since 2002 in its 4.1 release.

By default, Apache Tomcat implements and exposes the Apache JServ Protocol (AJP) interface. The AJP binary protocol was originally developed in 1997 and was part of Tomcat when it was donated to the Apache Software Foundation. With one of two connectors, it allows Tomcat servlet container Catalina to communicate and interact through a network connection. Similar to Tomcat’s HTTP connector, the AJP connector handles inbound requests and passes to Catalina. Catalina then passes the request to the proper web application and receives the dynamically generated content. This content is then sent back over the network by the AJP connector as the response to the request. Unlike the HTTP connector, the AJP connector is a highly trusted protocol connector that allows for extended functionalities. It should not be exposed over an untrusted network, as it may be leveraged to gain complete access to the application server.

Under a default Tomcat installation on Windows 10, multiple ports are exposed. Among them are Tomcat’s HTTP port, on 8080, as well as the AJP port, on 8009. The vulnerability is caused by the default exposure of the AJP connector port.

The vulnerability is caused by the improper exposure of the AJP connector. The AJP connector is considered to have a higher trust level and is intended to be used between servers, such as communications between HTTP and Tomcat, so it is expected to be exposed only internally. For communications over the external network with untrusted users, the HTTP connector, which has lower trust, is exposed.

However, on default installations, the AJP connector is enabled and exposed to the external network through TCP port 8009. This allows arbitrary users to interact with the Tomcat server through the AJP connector and gain additional access to the server. Through the AJP connector, an attacker can retrieve arbitrary files from Tomcat’s web root, including the files residing within the “WEB-INF” and “META-INF” directories through the “ServletContext.getResourceAsStream()” function. Additionally, arbitrary files within the web application on the vulnerable Tomcat server can be processed as a JSP page through the AJP connector. On vulnerable Tomcat servers that allow file uploads, if an attacker uploads a file and then forces the Tomcat server to process the file via the AJP connector, this can lead to arbitrary code execution under the privileged context of the vulnerable process.

At the time of this writing, multiple PoC code has been made public via various GitHub repositories. The PoC code, mostly written in Python or in the form of Java jar containers, is capable of leveraging the vulnerability to retrieve arbitrary files from a vulnerable Tomcat server.

Flashpoint analysts have obtained the publicly available PoC code and verified them against Tomcat 8.5.32 running on Windows 10. The verified PoC code, written in Python, is capable of creating and sending a well-formed AJP request to a specified IP address. When the request is sent with a valid file path and name, the vulnerable server returns the file as a stream back to the PoC code and the file is displayed on the attacker’s screen, as the result of the PoC execution. Testing has shown that the PoC code can retrieve arbitrary files, including JSP source files that are inaccessible via the HTTP connector, with high reliability. Where the requested file is not a plaintext file, the output stream needs to be saved and opened with the appropriate application.

Flashpoint analysts have not tested other branches and versions of Tomcat, but they expect the PoC code should function without any issues against other vulnerable Tomcat versions. This is because the implementation of the AJP connector within the AbstractAjpProtocol.java code shares a high degree of similarity across versions.

The Entry.java JSP source code as shown on the Tomcat server. This code should not be accessible over the network under normal operating conditions.

Although under certain circumstances remote code execution is achievable, it is not easy. To accomplish remote code execution, an attacker would need to find a web application that accepts file uploads that is running on a vulnerable Tomcat server. Further, as of this writing, the publicly available PoC code is not implemented to support execution of JSP files on a vulnerable server. However, such capability can be implemented on the basis of the PoC code with relative ease.

Impact

Flashpoint analysts assess with high confidence that this vulnerability is likely to pose a high impact potential. Due to the nature of the vulnerability, it can be leveraged without any user interactions and with high reliability, with low chance of causing the vulnerable server to crash. Under certain circumstances, where a web application allows for file upload, the vulnerability may be leveraged to execute arbitrary code under the privileged context of the vulnerable Tomcat process. However, as of this writing, the publicly available PoC code can only be leveraged to retrieve files on a vulnerable server. Although implementing code execution exploit from the PoC code should be relatively straightforward, the file upload requirement can only be implemented by the web application developer, rather than the attacker. For this reason, only a portion of the vulnerable Tomcat servers may suffer the code execution impact from this vulnerability.

Publicly available PoC and exploit code make the exploitation of this vulnerability more accessible to threat actors of all skill levels. The mass
scan activities could identify internet-facing instances of Tomcat susceptible to attacks. Therefore, Flashpoint analysts assess with moderate confidence that this vulnerability may see active exploitation attempts in the coming days in a more targeted fashion.

Mitigation

The Apache Software Foundation released Tomcat versions 7.0.100, 8.5.51, and 9.0.31 on February 14, 2020, to address this vulnerability and two lower-impact vulnerabilities. Flashpoint has tested the publicly available PoC code against Tomcat version 8.5.51 and found that the new version can fully mitigate against exploitation attempts.

Alternatively, Tomcat instances that do not require the use of AJP connectors can completely mitigate against all exploitation attempts by disabling the AJP connector. This can be accomplished by modifying Tomcat’s configurations. In cases where AJP connectors are in use, users should consider exposing the connector only in the trusted network segment, rather than exposing it to the entire network, to reduce attack surface.

The file upload requirement is a mitigating factor against this vulnerability, as this feature is not available by default. Only Tomcat-running web applications that allow for file upload are susceptible to remote code execution attacks. Further, to retrieve files from the vulnerable server, an attacker would need to know the file names, which can complicate the exploitation process.