Spring4Shell: Java vulnerabilities bounce back into the headlines

In late March 2022, a security researcher accidentally disclosed a zero-day vulnerability on Twitter that allowed for remote code execution in Java Spring web applications. The initial tweet was deleted, but researchers and others had already managed to copy and release the proof of concept (PoC).

This vulnerability quickly gained traction. Its aim was have as big an impression as Log4Shell, a massively impactful vulnerability in the ubiquitous logging library Log4j that was found just a few months before. Commonly referred to as Spring4Shell or SpringShell due to its similarity with Log4Shell, it was designated CVE-2022-22965.

A detailed analysis by PaloAlto identifies that the new vulnerability appears to be related to CVE-2010-1622, where a block list used to fix that bug can now be bypassed in Java versions 9 or later.

Let's take a closer look and see if it lives up to the hype.

Affected versions

The vulnerability was in spring-core and affects Spring on versions earlier than 5.3.18 or 5.2.20. However, there are also several required conditions that must be met to exploit this vulnerability:

• Running a vulnerable version of Spring
• Running Java version 9 or higher
• Running Apache Tomcat
• Deployed as a WAR, not a Spring Boot executable
• Using spring-mvc or spring-webflux

These are not typically part of default conditions for code deployed in production.

This list is likely to change as more researchers find ways to bypass the known mitigation or requirements. So even if your applications don't match the requirements, you should prioritize patching.

Remediation

At the time the PoC was released there were no patches available. At the time of writing, patches have been released for the Spring framework that resolves the vulnerability and prevents further exploitation in the following versions:

• 5.3.18
• 5.2.20

There are also new versions of Spring Boot for these, including dependency upgrades, bug fixes, and other improvements. These versions are:

• 2.6.6
• 2.5.12

Tomcat has also released a security patch to remediate the vulnerability from the server-side by updating to a version newer than:

• 9.0.62

Temporary remediation
It's not always possible to instantly update to a new version, and sometimes it can be useful to apply temporary mitigations until a patch is available. Praetorian has suggested additional mitigation to add an exclusion list to the Controller that prevents class types from being loaded.

import org.springframework.core.Ordered;

import org.springframework.core.annotation.Order;

import org.springframework.web.bind.WebDataBinder;

import org.springframework.web.bind.annotation.ControllerAdvice;

import org.springframework.web.bind.annotation.InitBinder;



@ControllerAdvice

@Order(10000)

public class BinderControllerAdvice {



@InitBinder

public void setAllowedFields(WebDataBinder dataBinder) {

String denylist = new String{"class.*", "Class.*", "*.class.*", "*.Class.*"};

dataBinder.setDisallowedFields(denylist);

}



}



Exploited in the wild

So far there have only been sporadic, unconfirmed reports of this vulnerability being exploited in the wild. Due to the non-standard configuration required to exploit this vulnerability, security researchers are struggling to find vulnerable real-world applications.

Detection

Spring is a modern web application so it's possible to identify exploit attempts by reviewing the web logs. Most PoCs use the vulnerability to write a JSP shell. The class data is sent in a POST request and the post-exploit activity uses GET requests where logs are more likely to reveal signs of exploitation.

You can check web server logs for the following examples:

• ?class.module
• &id=<command>
• cmd=<command>

Also, check any web servers for suspicious JSP files that aren’t part of the deployed web application. Examples include:

• 0xd0m7.jsp
• myshell.jsp
• shell.jsp
• tomcatwar.jsp
• wpz.jsp

Try it yourself

Hot on the heels of Log4Shell, this vulnerability helps highlight the importance of having dependency management tooling in place. For example, software composition analysis tools can help proactively alert you to issues like this in your applications.

We’ve developed a series of labs to help you understand this vulnerability and exploit.

• In the offensive/red team lab you learn about the exploit and use the PoC against a real vulnerable server
• In the defensive/blue team lab you analyze log files to discover information about how the vulnerable server was exploited

In the application security lab you’ll look in depth at the code and experiment with mitigations to protect your server and application from exploitation while waiting for the updated packages

Mat Rollings
Interim AppSec SME
@stealthcopter