Spring4Shell – What You Need to Know

Code in a colorful environment

By: Ofri Ouzan, Security Researcher, Rezilion

Since the release of a proof-of-concept (PoC) exploit for a Remote Code Execution (RCE) in the Spring Framework by a Chinese security researcher (later removed from on GitHub due to Chinese legal issues) there has been a lot of conflicting information running around. CVE-2022-22965, AKA Spring4Shell was immediately associated to Log4Shell due to the similarity in the method of exploitation. As time went by, it became evident that the Spring4Shell vulnerability requires quite a few preconditions to be in place for a successful exploitation. That has spurred a debate among security researchers around how likely it is that real-world applications are affected by the vulnerability and how common those vulnerable applications are.

The fact that several other Spring Related vulnerabilities were also published around the time of the Sprin4Shell publication has added to the confusion. Some misconfussed it with the Spring Cloud vulnerability (CVE-2022-22963) and the Spring Expression DoS vulnerability (CVE-2022-22950).

An older similar issue was exploited and patched in the past (CVE-2010-1622), however, Spring became vulnerable again when used by JDK9+.

In this blog post we will try to lay out the facts we know now and highlight the important aspects security practitioners and leaders should know in order to address the vulnerability.

CVE-2022-22965

Spring4Shell is a zero-day Remote Code Execution (RCE) vulnerability caused by an error in the mechanism which uses client-provided data to update the properties of an object in the Spring MVC or Spring WebFlux application. The vulnerability can be exploited remotely only if a Spring application is deployed as a WAR on the Apache Tomcat server and run on JDK 9 and higher, it can not be exploited in other mechanisms of Spring applications, for example; Spring applications that use embedded Tomcat or Spring boot executable jar files.

Comparison to Log4Shell

In contrast to Log4Shell, in order to exploit the Spring4Shell vulnerability:

  • The attacker needs to know the address and the application’s endpoint.
  • The attacker will not be able to exploit systems which are not connected to the internet.
  • Log4Shell required no preconditions or specific configuration in order for it to be exploited. That is not the case with Spring4Shell.

What is Tomcat?

The Apache Tomcat software is one of the most popular web server and Java Servlet Containers. According to the jrebel-2022-java-developer-productivity-report, Apache Tomcat was far and away the most popular Java application server at 48% of all responses:

The Apache Tomcat software is developed in an open and participatory environment and released under the Apache License version 2.

What is Spring?

The Spring Framework is an open-source application framework that provides infrastructure support for developing Java applications.

Spring helps developers create high performing applications using plain old Java objects (POJOs).

Controller Class

In Spring Boot, the controller class is responsible for processing incoming REST API requests, preparing a model, and returning the view to be rendered as a response.

The controller classes in Spring are annotated either by the @Controller or the @RestController annotation.

Exploit

In this exploit example, the  `run_exploit` function makes a HTTP POST request that uses the “Classloader Manipulation” attack vector to achieve a Remote Code Execution (RCE) on a Spring application which is deployed on an Apache Tomcat server.

The url variable should contain the following string ‘<domain_name>:<port_number>/<application_name>’.

The data variable contains the ClassLoader fields which are filled with the payload information:

  • log_pattern – contains the payload code which will be stored in a file.
  • log_file_suffix – contains the file suffix.
  • log_file_dir – contains the directory containing the payload.
  • log_file_prefix – contains the payloads file name.

After running the HTTP POST request, the attacker receive a shell on the Apache Tomcat server by requesting the following:
http://localhost:8080/shell.jsp 
With a cmd parameter that can be any command!

For example: 
http://localhost:8080/shell.jsp?cmd=whoami 
Will print the username.

Validation

In order to successfully exploit the vulnerability these Conditions have to be met:

  • JDK 9 or higher
  • Apache Tomcat as the Servlet container (Note there is currently a debate whether this is mandatory, we will update this section in case there will be conclusive results)
  • Packaged as WAR (in contrast to a Spring Boot executable jar)
  • spring-webmvc or spring-webflux dependency
  • Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and lower  versions
  • Spring Boot versions 2.6.0 to 2.6.5,  2.5.0 to  2.5.12, and lower versions.
  • Tomcat versions 10.0.0 to 10.0.20, 9.0.0 to 9.0.62, 8.5.0 to 8.5.78, and lower versions..
  • The application needs to be connected to the internet
  • The attacker needs to know the address and the application’s endpoint.

A few open source tools have been released aimed at detecting vulnerable Spring4Shell components. See for example here and here.

Remediation

Upgrade to the following patch releases:

  • Spring 5.3.x users upgrade to 5.3.18+
  • Spring 5.2.x users upgrade to 5.2.20+
  • Spring Boot 2.6.x users upgrade to 2.6.6+
  • Spring Boot 2.5.x users upgrade to 2.5.12+
  • Tomcat 10.0.x users upgrade to 10.0.20
  • Tomcat 9.0.x users upgrade to 9.0.62
  • Tomcat 8.5.x users upgrade to 8.5.78

Mitigation

The spring Framework engineering team has issued several recommendations for workarounds.

These mitigations can help reduce the probability of exploits, however, it should be considered as a temporary solution until you are able to upgrade Spring to a non-vulnerable version. 

  • Inject code to the @Controller or the @RestController components (or create them) in order to disallow dangerous patterns that can perform the “ClassLoader Manipulation” attack vector:

  • A more secure solution is to extend the RequestMappingHandlerAdapter class to update the WebDataBinder at the end of each initialization:
  • If you cannot update to a newer version of Spring, consider checking whether it is feasible for you to downgrade your Java version to Java 8.

We will update this post as we continue to analyze the potential attack surface and exploitability of the vulnerability. The Dutch National Cyber Security Center (NCSC) has also published a resource list that should update over time with information about vulnerable applications and detection tools.

Reduce your patching efforts by
85% or more in less than 10 minutes