Patch your Tomcat and JBoss instances to protect from GhostCat vulnerability (CVE-2020–1938 and CNVD-2020–10487)
Identified as “GhostCat” and tracked as CVE-2020–1938 / CNVD-2020–10487, the flaw could let remote attackers (without authentication) read the content of any file on a vulnerable web server (or servlet container) and obtain sensitive configuration files or source code, or execute arbitrary code if the server allows file upload.
This means that they can create backdoors, read config files with hardcoded credentials, take over password and tokens to laterally move across other hosted services , or even read or write on any file on a server. It is one of the most serious vulnerabilities detected on Apache Tomcat so far.
Discovered by Chinese cybersecurity company Chaitin Tech, the vulnerability resides in the AJP protocol in Apache Tomcat servlet container. AJP is a highly trusted protocol and should never be exposed to untrusted clients.
AJP (Apache Jserv Protocol) is basically a binary protocol that allows to reverse proxying requests from a FrontEnd Web Server to a BackEnd Application Server, effectively propagating all the needed information to make the Request/Response flow continuing successfully. Often, AJP is used to load balance using sticky-session policies.
Benefits of AJP are
- More performant than any HTTP exchange,
- Integrated with broadly used reverse-proxying modules (i.e. mod_jk, mod_proxy),
- Tomcat’s implementation provides a rich set of APIs that is protocol transversal: HTTP(s) data is seamlessly propagated, and can be retrieved with simple API calls, so it’s like working with HTTP at a higher speed.
The AJP protocol is enabled by default, with the AJP connector listening in TCP port 8009 and bond to IP address 0.0.0.0. A remote, unauthenticated/untrusted attacker could exploit this AJP configuration to read web application files from a server exposing the AJP port to untrusted clients. In instances where a poorly configured server allows file uploads, an attacker could upload malicious JavaServer Pages (JSP) code within a variety of file types to gain remote code execution (RCE).
A BinaryEdge based search indicates that there are over 1MM tomcat servers online.
As per a Onyphe scan there are more than 170,000 devices exposing an AJP Connector responding to an AJP13 requests
Shodan indicates that there are approximately 198,290 servers with exposed AJP port (8009) in USA.
Are you vulnerable?
If your infrastructure encompasses any component built using or deployed upon
- Apache Tomcat (6.x , 7.x < 7.0.100, 8.x < 8.5.51, and 9.x < 9.0.31)
- Spring Boot Java framework that is bundled with pre-included Tomcat server
- JBossWeb Server (3.1.7 / 5.2.0)
- JBoss EAP (6.x / 7.x)
- Red Hat Enterprise Linux (5.x ELS, 6.x, 7.x, 8.x with pki-servlet-container, pki-servlet-engine in pki-deps module
- Verify your firewall and reverse proxy config to identify if AJP conduit is exposed
- Upgrade to latest version of Apache Tomcat 9.0.31, 8.5.51, and 7.0.100 to fix this vulnerability
- For Tomcat based deployments, If your service is not using AJP connecter then disable by it out from the <TOMCAT_HOME>/conf/server.xml
<!– <Connector port = "8009" protocol = "AJP / 1.x" redirectPort = "8443" /> –>
- For Tomcat based deployments ,if AJP connector is required and cannot be deactivated, then upgrade and to set a secret password for the AJP conduit. Edit conf/server.xml
<Connector port="8009" protocol="AJP / 1.3" redirectPort="8443" address="YOUR_TOMCAT_IP_ADDRESS" requiredSecret="YOUR_AJP_SECRET" />
- For JBoss based deployments, verify and edit the default AJP connector which is enabled by default only in standalone-full-ha.xml, standalone-ha.xml and ha and full-ha profiles in domain.xml
<connector name="AJP" protocol="AJP/1.3" scheme="http" socket-binding="ajp" enabled="false"/>
- For JBoss based deployments, if AJP connector is a requirement and cannot be deactivated, then add credential to AJP conduit
<property name="org.apache.coyote.ajp.DEFAULT_REQUIRED_SECRET" value="YOUR_AJP_SECRET"/>
You may be confident that your perimeter defenses are robust enough to pick up on most such threats. However adversaries have long known how reactive cybersecurity tools work — and they make it their mission to circumvent them.
Besides scanning your configurations and OSS dependencies, it is critical to understand how your application’s logic uses its OSS dependencies and frameworks that it is deployed upon.
Use ShiftLeft’s Inspect for free to proactively stay on top of your application security posture.
Patch your Tomcat and JBoss instances to protect from GhostCat vulnerability (CVE-2020–1938 and… was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Chetan Conikee. Read the original post at: https://blog.shiftleft.io/patch-your-tomcat-and-jboss-instances-to-protect-from-ghostcat-vulnerability-cve-2020-1938-and-6e9597cc407e?source=rss----86a4f941c7da---4