Nytro Posted March 22, 2020 Report Posted March 22, 2020 Busting Ghostcat: An Analysis of the Apache Tomcat Vulnerability (CVE-2020-1938 and CNVD-2020-10487) Posted on:March 10, 2020 at 7:02 am Posted in:Vulnerabilities Author: Trend Micro By Magno Logan (Information Security Specialist) Discussions surrounding the Ghostcat vulnerability (CVE-2020-1938 and CNVD-2020-10487) found in Apache Tomcat puts it in the spotlight as researchers looked into its security impact, specifically its potential use for remote code execution (RCE). Apache Tomcat is a popular open-source Java servlet container, so the discovery of Ghostcat understandably set off some alarms. This blog entry seeks to put the most feared Ghostcat-related scenario into perspective by delving into the unlikely circumstances that would make it possible to allow an RCE through the vulnerability. The AJP Protocol Ghostcat was discovered on Feb. 20 by Chaitin Tech security researchers, who reported that the vulnerability exists in the Apache JServ Protocol (AJP). The AJP is a binary protocol used by the Apache Tomcat webserver to communicate with the servlet container that sits behind the webserver using TCP connections. It is mainly used in a cluster or reverse proxy scenario where web servers communicate with application servers or servlet containers. In simple terms, this means that the HTTP Connector is exposed to clients, while the AJP is used internally between the webserver (e.g., Apache HTTPD) and the Apache Tomcat server (illustrated in Figure 1). AJP is implemented as a module in the Apache HTTP Server, represented as mod_jk or mod_proxy_ajp. The bottom line is that AJP is not, by nature, exposed externally. This is important to point out, as it’s one of the prerequisites for the RCE scenario that we will discuss in the next section. Figure 1. Apache JServ Protocol illustration The Ghostcat Vulnerability Ghostcat in itself is a Local File Include/Read vulnerability and not an Arbitrary File Upload/Write vulnerability. On the Apache Tomcat Security Advisory page, Ghostcat is described as “AJP Request Injection and potential Remote Code Execution.” The keyword “potential” serves to emphasize that Ghostcat is not an RCE vulnerability by default. The advisory further detailed the circumstances necessary for an RCE to take place: The web application needs to allow file upload and storage of these uploaded files within the web application itself, or an attacker would have to gain control over the content of the web application somehow. This scenario, combined with the ability to process a file as a JSP (as made possible through the vulnerability), would make an RCE feasible. In summary, Ghostcat can cause issues to organizations if they have Tomcat AJP Connector exposed externally, which is not a recommended configuration in the first place. However, aside from an exposed AJP, it would require several other prerequisites for an RCE to happen. These are requirements that, when combined, are hard to find in a real-world scenario. João Matos, a well-known security researcher from Brazil, identified the prerequisites needed for Ghostcat to become an RCE. Figure 2. Post identifying the prerequisites for an RCE to take place We looked into these further, as elaborated below: Upload files via an APP feature. This first prerequisite means that an application with a file upload feature should already be installed in the system for the RCE to be possible. If this is the case, it would be more convenient for a potential attacker to use the web application itself with a file upload vulnerability to upload a malicious web shell file. The need to interpret the file as JSP would only arise in cases where the upload vulnerability restricts certain file extensions such as JPG or TXT. These files are saved inside the document root. Once an attacker has compromised the application and was able to upload the malicious file, the files would need to be saved inside the application root folder. This prerequisite by itself is unlikely or difficult to orchestrate for two reasons: 1) It is uncommon in Java applications to save files in its application root folder; and 2) the application root folder is transitory, so this folder is completely overwritten whenever a new version of the application is deployed. In addition, from a developer perspective, it makes little sense for a file upload feature to upload files inside the root folder since most of the Apache Tomcat applications are deployed as a .WAR file, which is basically a zip file. Reach the AJP port directly. Lastly, after these two prerequisites are met, a potential attacker would have to be able to reach the Tomcat AJP Connector (default port 8009) directly from the internet through the reverse-proxy, which is an externally exposed AJP. As mentioned, this is not a recommended or common configuration. Even if the AJP Connector is exposed and an attacker tried to communicate with it, they would receive a 400 Bad Request response from the web server since AJP is a binary protocol. How serious is Ghostcat? What adds to the notoriety of Ghostcat is the fact that it has been around for over thirteen years and affects all major versions of Apache Tomcat. In this blog entry, we try to help manage the alarm brought about by the discovery of the vulnerability. Given all the requirements described above, it is unlikely for these requirements to happen in a real-world scenario that would turn Ghostcat into an RCE vulnerability. An attacker would need to actively make these requirements happen, as there is unlikely a legitimate reason for them to exist in a real-world setting. Most PoCs demonstrating the issue already had a webshell.txt file inside the webapps/ROOT of the Apache Tomcat, thus enabling the RCE prior to exploiting Ghostcat. In a real-world scenario, an attacker already inside a network may be able to leverage this vulnerability to perform lateral movement because they would be able to reach the AJP Connector directly. However, for them to reach this stage of their attack, they would still need to upload a malicious file such as a webshell inside the webapps/folder to use the Ghostcat LFI vulnerability, and then force the file to be interpreted as JSP regardless of the extension, which would be difficult to do. A Fix for Ghostcat The fixes done by the Apache Tomcat team to address Ghostcat should also provide further clarity on its true limitations. In this section, we detail the fixes in the code from version 9.0.31, which mostly shares the same code with other versions. Ghostcat relies on a misconfiguration (as seen below) of the AJP Connector where it is enabled by default on the /conf/server.xml file: <Connector port=”8009″ protocol=”AJP/1.3″ redirectPort=”8443″ /> The Apache Tomcat team commented out this line from the file, thus disabling the AJP connector by default on the commit 4c933d8, as seen in figure 3. Figure 3. Image showing Commit 4c933d8, which disables the AJP connector by default On its own, the code fix above is enough to stop Ghostcat from happening since it disables AJP by default. This should only be done if the AJP is not being used. We detail a second fix that does not necessarily disable AJP but limits it to only listen to the loopback interface by default (figure 4). The Apache Tomcat team made other changes to improve the overall usage of the AJP Protocol, such as enforcing a secret to be defined when the secretRequired attribute is set to true (figure 5). They also made sure that any requests to the AJP Connector that contains arbitrary and unrecognized attributes receive a 403 (Forbidden) response (figure 6). Figure 4. Image showing Commit 0e8a50f0, which forces the AJP protocol to listen to the loopback address by default instead of 0.0.0.0. Figure 5. Image showing Commit 9ac90532, which checks if the parameter secretRequired is set to “true” and there is a defined “secret” Figure 6. Image showing Commit 64fa5b99, which blocks requests to the AJP Connector with a 403 Forbidden message response if it contains any arbitrary and unrecognized attributes Conclusion Given all that has been discussed in this post, it is still important for users to recognize that Ghostcat still poses risks even if it’s not an RCE by default. The fact that there are already many publicly available exploits for this vulnerability should push users to update their Tomcat to the latest version as soon as possible to reduce the risk of being exploited. Apache Tomcat has released fixes for the following versions of Tomcat: Tomcat 7 (version 7.0.1000) Tomcat 8 (version 5.51) Tomcat 9 (version 0.31) If updating is not an immediate option, users who are not using the AJP Connector Service should instead disable it by commenting or completely removing it from the $CATALINA_HOME/conf/server.xml and restarting Tomcat, similar to the actions taken by the Apache Tomcat team described above. Aside from upgrading Tomcat to the latest version, if the AJP Connector service is being used, set the “secret” attribute to defined AJP protocol authentication credentials as recommended by Chaitin, as set below: <Connector protocol=”AJP/1.3″ address=”::1″ port=”8009″ redirectPort=”8443″ secretRequired=”true” secret=”YOUR_SECRET_HERE” /> Snyk also mentions that applications using the Spring Boot framework may also be affected by this vulnerability since they use an embedded version of Tomcat by default. Users of those applications should also look into this further, to make sure they are not affected by Ghostcat. Trend Micro Solutions Developers, programmers, and system administrators using Apache Tomcat can also consider multilayered security technology such as Trend Micro™ Deep Discovery™. These solutions provide in-depth analysis and proactive response to attacks using exploits and other similar threats through specialized engines, custom sandboxing, and seamless correlation across the entire attack lifecycle, allowing it to detect these attacks even without any engine or pattern updates. Trend Micro™ Deep Discovery Inspector™ protects customers from this attack via this DDI rule: Rule 4354 – CVE-2020-1938 – TOMCAT AJP LFI Exploit – TCP (Request) Trend Micro™ Deep Security™ solution also protects systems from threats that may exploit CVE-2020-1938: 1010184 – Identified Apache JServ Protocol (AJP) Traffic CVE-2020-1938 Trend Micro™ TippingPoint® customers are protected from threats and attacks that may exploit Ghostcat via the following MainlineDV filter: 37236- AJP: Apache Tomcat AJP File Request Sursa: https://blog.trendmicro.com/trendlabs-security-intelligence/busting-ghostcat-an-analysis-of-the-apache-tomcat-vulnerability-cve-2020-1938-and-cnvd-2020-10487/ Quote
