Vulnerability in Apache Tomcat that allows JSP code injection and access to web application files.

Researchers from the Chinese company Chaitin Tech have identified vulnerability (CVE-2020-1938) in Apache Tomcat, an open implementation of Java Servlet, JavaServer Pages, Java Expression Language, and Java WebSocket technologies. The vulnerability is codenamed Ghostcat and assigned a critical severity level (9.8 CVSS). The issue allows, in the default configuration, reading the contents of any files from the web application's directory by sending a request to network port 8009, including configuration files and the application's source code.

The vulnerability also allows importing other files into the application code, which can enable code execution on the server if the application allows file uploads (for example, an attacker could upload a JSP script disguised as an image through the image upload form). The attack can be carried out if it is possible to send a request to the network port with the AJP handler. Preliminary data suggests that there are four minor issues were found (enabling debugging messages, lack of backup blocking using the ADB utility, encrypting settings with a hard-coded key, absence of SSL certificate binding) and one medium severity vulnerability (incomplete session termination allowing for session token reuse). over 1.2 million hosts accepting requests over the AJP protocol.

The vulnerability exists in the AJP protocol and is not caused by a flaw in implementation. In addition to accepting connections over HTTP (port 8080), Apache Tomcat by default allows access to web applications through the AJP protocol (Apache Jserv Protocol, port 8009), which is a binary analog of HTTP optimized for higher performance, commonly used when creating a cluster of Tomcat servers or for speeding up interactions with Tomcat on a reverse proxy or load balancer.

AJP provides a built-in function for accessing files on the server, which can be used to obtain files that should not be disclosed. It is assumed that access to AJP is only open to trusted servers; however, in practice, in the default configuration, Tomcat was configured to run the handler on all network interfaces, and requests were accepted without authentication. Access is possible to any files within the web application, including the contents of WEB-INF, META-INF, and any other directories served through the ServletContext.getResourceAsStream() call. AJP also allows using any file in the directories accessible to the web application as a JSP script.

The issue has been present since the release of the Tomcat 6.x branch 13 years ago. Besides Tomcat, the issue affects and the products that utilize it, such as Red Hat JBoss Web Server (JWS), JBoss Enterprise Application Platform (EAP), as well as standalone web applications that use Spring Boot. A similar vulnerability (CVE-2020-1745) has been present in the web server Undertow, used in the Wildfly application server. In JBoss and Wildfly, the AJP protocol is enabled by default only 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. Currently, over a dozen working exploit examples have been prepared by different groups (
1,
2,
3,
4,
5,
6,
7,
8,
9,
10,
11).

The vulnerability has been fixed in Tomcat releases 9.0.31, 8.5.51 and 7.0.100 (6.x branch maintenance has been put into operation.). You can track updates in the distributions on these pages: Debian, Ubuntu, SUSE/openSUSE, Alpine, openSUSE, FreeBSD. As a security 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 it is not needed, or configure use authenticated access with the "secret" and "address" attributes if the service is used for interaction with other servers and proxies based on mod_jk and mod_proxy_ajp (mod_cluster does not support authentication).

Source: opennet.ru