Redgate’s new SQL Monitor now ensures that DevOps teams can monitor and track deployments at all times.
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:
1. More performant than any HTTP exchange.
2. Integrated with broadly used reverse-proxying modules (i.e. mod_jk, mod_proxy).
3. 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
and bound to IP address
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 BinaryEdgebased search indicates that there are over 1MM tomcat servers online.
Credit: BinaryEdge based search
As per a Onyphescan 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
■ 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
■ Verify your firewall and reverse proxy config to identify if AJP conduit is exposed
1. Upgrade to latest version of Apache Tomcat 9.0.31, 8.5.51, and 7.0.100 to fix this vulnerability
2. For Tomcat based deployments, If your service is not using AJP connecter then disable by it out from the
3. 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 requiredSecret="YOUR_AJP_SECRET" /> 4. 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, ha, full-ha profiles in domain.xml 5. For JBoss based deployments, if AJP connector is a requirement and cannot be deactivated, then add credential to AJP conduit
4. 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, ha, full-ha
5. For JBoss based deployments, if AJP connector is a requirement and cannot be deactivated, then add credential to AJP conduit
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.