‘GhostCat’? What’s in a name anyway?

When a security vulnerability researcher finds a new web application vulnerability, their first priority is to write a script or snippet of code to act as a simple, reproducible test that can be used to find out if a given web server is vulnerable. Their second priority, though, is to throw out the official CVE reference and come up with a really awesome name for it (personal favourite: Dirty Cow)

What’s a GhostCat?

Aside from being a – by all accounts truly terrible – direct-to-TV movie about a recently deceased cat who comes back from the dead to try and stop scammers and wealthy businessmen from making unnecessary land-development deals, “Ghostcat” is also the fond nickname for vulnerability CVE-2020-1938. Its discoverers have lovingly furnished it with its own logo (complete with notched ear; Ghostcat is clearly a brawler), and website. T-shirts will surely follow.

Why is this vulnerability called ‘GhostCat’?

GhostCat (the vulnerability) affects the Tomcat application/middleware server produced by the Apache Foundation and commonly used across many business and other organizations to execute Java application code.

How serious is it?

About as bad as it gets. It rates a CVSS score of 9.8 out of 10. The vulnerability allows  an attacker to read any files in the webapp directories of Tomcat. For example, an attacker can read the webapp configuration files or source code. Worse, in instances where the vulnerable server allows file uploads, an attacker could upload malicious JavaServer Pages (JSP) code and trigger this vulnerability to gain remote code execution (RCE) on the server.

Technical Details

GhostCat is a flaw in the Tomcat AJP (Apache JServ) protocol. AJP is a proprietary version of the HTTP protocol in binary format and is used by Tomcat to exchange data with Apache HTTPD web servers or other Tomcat instances. AJP’s primary intended function is the use within Tomcat cluster environments for inter-host communication and C&C (command and control).

Exposure

Tomcat’s AJP Connector is enabled by default on all Tomcat instances, so if you’ve not specifically disabled it, there’s a good chance that its currently enabled on your Tomcat server. The service is bound to the “0.0.0.0” (“all interfaces”) IP address by default, on port 8009. That means that if your server has a routeable IP address, or serves port 8009 via NAT, then it may be vulnerable to attacks directly from the internet.

Estimates of how many servers are exposed varies – there’s millions of Tomcat installs, but some are screened by firewalls and so are (relatively) better protected. According to various cyber-security search engines, the number of vulnerable instances exposing an AJP Connector to everyone through the Internet ranges from 170,000 (onyphe) to around 1million (Shodan and BinaryEdge).

Who discovered the flaw?

GhostCat was discovered by researchers at Chinese cyber-security firm Chaitin Tech, who reported their findings to the Apache Software Foundation on January 3, 2020. Its not known how long they spent perfecting the logo first.

What versions of Tomcat server are affected?

Virtually all Tomcat versions are affected, including proprietary products built on top of Tomcat. These include:

• Apache Tomcat 9.x versions less than 9.0.31
• Apache Tomcat 8.x versions less than 8.5.51
• Apache Tomcat 7.x versions less than 7.0.100
• Apache Tomcat 6.x versions (End of life, not patched)
• Red Hat JBoss Web Server (JWS) versions 3.1.7 and 5.2.0
• Red Hat JBoss Enterprise Application Platform (EAP) versions 6.x and 7.x
• Red Hat Enterprise Linux (RHEL) versions 5.x ELS, 6.x, 7.x, and 8.x (as pki-servlet-container, pki-servlet-engine in pki-deps module)
• Any apps that include Tomcat server

Is the vulnerability currently exploitable, or just theoretical?

The danger is very real. Proof-of-concept exploits have already been shared by multiple parties on GitHub so exploits are “in the wild”.

How should I fix this?

By far the preferred approach is to update to the latest version of Apache Tomcat. Apache has released versions 9.0.31, 8.5.51, and 7.0.100 of Tomcat to fix this vulnerability.

If you can’t immediately update or upgrade your server to a patched Tomcat version, then you should focus on immediately disabling access to the AJP port if it is not actively used within your environment (such as in a clustering arrangement). You could do this by either:

• Firewalling off access to the AJP port, since port 8009 should almost never need to be exposed on the internet for its intended function without strict access-control lists; or
• Disabling the AJP connector in Tomcat configuration (typically found at <CATALINA_BASE>/conf/server.xml); or
• Binding AJP to the localhost IP address “127.0.0.1” rather than the global “0.0.0.0” used by default.

GhostCat Vulnerability Scan?

The AppCheck Scanner has been updated in response to GhostCat. The scanner now includes a module which detects remotely accessible Apache JServe Protocol (AJP) services and attempts to safely exploit them to retrieve a file.

Further Information

If you’d like any further information or would like to see what other vulnerabilities we can pick up in your web applications then feel free to email us at info@appcheck-ng.com where an AppCheck representative can set up your free vulnerability assessment.