On March 30, a pseudonymous security researcher posted a proof of concept of a remote code execution vulnerability in the Spring framework for Java. Early speculation likened this vulnerability to last year’s log4shell vulnerability. While subsequent proofs of concept have confirmed this vulnerability, due to the conditions necessary for the attack, we believe that this vulnerability — although serious — will not have the same widespread impact as log4shell.

Vulnerability Details

The vulnerability is a result of the Spring framework’s data binding capability. Data binding enables the creation or modification of Java objects from the parameters passed in an HTTP request. This feature simplifies the implementation of web application logic, but was also the basis of a prior vulnerability. This type of vulnerability is the result of an attacker being able to bind values to Java objects that should not be modified externally. The Spring documentation specifically advises that developers should proactively limit which objects can be manipulated through data binding.

To understand how this vulnerability works, we’ll step through a public proof-of-concept exploit from LunaSec. The exploit modifies a Java object in the Tomcat webserver that controls application logging and installs a webshell capable of executing arbitrary remote code. The attack inserts the following values into the logging object:

These values represent the attacker-defined location of the log file, as well as the formatting string used to write the logs. By setting directory to “webapps/ROOT” and filename to “shell”, the following request will modify the Tomcat logger to write to “webapps/ROOT/shell.jsp” using the format string in log_pattern.

Removing the HTML-safe encoding, we see that the new format string is the following:

The next step is to force the webserver to write the format string to the above location, inserting the following values in place of %{prefix}i, %{c}i, and %{suffix}i.

Installing the webshell is accomplished with a second HTTP request:

Once done, webapps/ROOT/shell.jsp will contain the following (reformatted for clarity):

The snippet of Java code in this Java Server Page will execute arbitrary code submitted via the cmd parameter in HTTP GET request to http://<server URL>/shell.jsp and display the output.

Vulnerable Configurations

Per Spring’s vulnerability information page, the known attacks require a web app with the following configuration:

• Running on JDK 9 or higher.
• Apache Tomcat as the Servlet container.
• Packaged as a traditional WAR and deployed in a standalone Tomcat instance. Typical Spring Boot deployments using an embedded Servlet container or reactive web server are not impacted.
• spring-webmvc or spring-webflux dependency.
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.

Attacks in the Wild

Juniper Threat Labs began seeing in-the-wild attempts to exploit this vulnerability starting on April 3. It is not yet known how many applications may be vulnerable to such an attack.

Mitigation and Detection

Affected applications should immediately update to the latest versions of both the Spring framework and the Tomcat webserver, which contain fixes and additional mitigations. Attacks exploiting this vulnerability are detected by Juniper IDP signature HTTP:CTS:VMWR-SPRING-CORE-RCE.