Vulnerability in Apache Tomcat that allows substituting JSP code and getting web application files

Researchers from the Chinese company Chaitin Tech have identified vulnerability (CVE-2020-1938) In Apache Tomcat, an open source implementation of Java Servlet, JavaServer Pages, Java Expression Language, and Java WebSocket technologies. The vulnerability has been given the code name Ghostcat and a critical severity level (9.8 CVSS). The problem allows, in the default configuration, by sending a request to network port 8009, to read the contents of any files from the web application directory, including files with settings and application source codes.

The vulnerability also makes it possible to import other files into the application code, which allows organizing code execution on the server if the application allows files to be uploaded to the server (for example, an attacker can upload a JSP script under the guise of an image through the image upload form). An attack can be made by sending a request to a network port with an AJP handler. According to preliminary data, online found more than 1.2 million hosts accepting requests via the AJP protocol.

The vulnerability exists in the AJP protocol, and not called implementation error. In addition to accepting connections via HTTP (port 8080), Apache Tomcat by default allows access to a web application via the AJP protocol (Apache JServ Protocol, port 8009), which is a performance-optimized binary equivalent of HTTP, commonly used when creating a cluster of Tomcat servers or to speed up communication with Tomcat on a reverse proxy or load balancer.

AJP provides a standard function for accessing files on the server, which can be used, including obtaining files that are not subject to disclosure. AJP is supposed to be accessible only to trusted servers, but in fact Tomcat's default configuration was to run the handler on all network interfaces and accept requests without authentication. Access is possible to any web application files, including the contents of WEB-INF, META-INF, and any other directories given through the ServletContext.getResourceAsStream() call. AJP also allows you to use any file in the web application's accessible directories as a JSP script.

The problem has been manifesting since the branch of Tomcat 13.x released 6 years ago. Except directly Tomcat problem affects and products that use it, such as Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), as well as self-contained web applications that use Spring boot. Similar vulnerability (CVE-2020-1745) present in the web server Undertowused in the Wildfly application server. In JBoss and Wildfly, the AJP protocol is only enabled by default in standalone-full-ha.xml, standalone-ha.xml and ha/full-ha profiles in domain.xml. In Spring Boot, AJP support is disabled by default. More than a dozen working examples of exploits have been prepared by different groups (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

Vulnerability fixed in Tomcat releases 9.0.31, 8.5.51 и 7.0.100 (maintenance branch 6.x discontinued). You can follow the appearance of updates in distributions on these pages: Debian, Ubuntu, RHEL, Fedora, SUSE, FreeBSD. As a workaround, you can disable the Tomcat AJP Connector service (bind the listening socket to localhost or comment out the line with Connector port = "8009") if not needed, or tune authenticated access using the "secret" and "address" attributes, if the service is used to interact with other servers and proxies based on mod_jk and mod_proxy_ajp (mod_cluster does not support authentication).

Source: opennet.ru