Spring4Shell Vulnerability

5 min readApr 13, 2022

Spring is a popular enterprise-grade application framework in Java. A remote code execution vulnerability known as Spring4Shell was discovered around the end of March.

Synopsis

A sequence of Tweets (that are now deleted) from a Chinese Twitter account were posted on March 29th, 2022, displaying pictures of a new POC of a 0-day vulnerability in one of the most popular Java frameworks, known as Spring Core. Internet Users refer to it as the ‘Spring4Shell’ or ‘Spring Shell’ vulnerability.

What is the Spring4Shell vulnerability?

Spring is a popular enterprise-grade application framework in Java. A remote code execution vulnerability known as Spring4Shell was discovered around the end of March.

It was named Spring4Shell because Spring Core is a popular library, comparable to Log4j which spawned the infamous log4shell vulnerability.

This vulnerability allows a remote unauthenticated attacker to access exposed Java class objects which in turn can lead to Remote Code Execution (RCE). There has been a lot of hype and confusion in the tech press around this vulnerability. The confusion is mainly to do with CVE for Spring Cloud Function which was released at the same time as Spring4Shell vulnerability, but the two are unrelated.

The Spring4Shell vulnerability (CVE-2022–22965) impacts SpringMVC (Spring Web model-view-controller) and Spring WebFlux applications when running on Java JDK9 and subsequently on a Tomcat application server. The vulnerability can be exploited to write to an arbitrary file on the server, which can then be leveraged to achieve remote code execution.

How serious is the Spring4Shell vulnerability?

There appears to be confusion about the potential severity of Spring4Shell. While it was initially claimed that all versions of Spring Core with a JDK version greater than or equal to 9.0 were vulnerable, researchers later discovered that Spring Core requires a specific configuration to be vulnerable.

In this particular blog, Spring themselves commented that for the “specific exploit” i.e., the publicly released one, to work, an application must meet the following prerequisites:

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-web MVC or spring-webflux dependency.
Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.

Further on, the advisory reads:

… If the application is deployed as a Spring Boot executable jar, i.e., the default, it is not vulnerable to the exploit …

However, it did also say that:

… the nature of the vulnerability is more general, and there may be other ways to exploit it …

Exploit Scenario

The exploit code that has been made public specifically targets Apache Tomcat deployments. It only affects Spring Applications that are deployed as traditional WebArchive (WAR) files to the Apache Tomcat Servlet container.

The main issue occurs when we have a controller that has a request mapping loaded into memory. In the example below, the vulnerability lies in the function that uses the @PostMapping annotation. Here’s an example:

... 
 
@Controller 
public class HelloController { 
   ... 
 
   @PostMapping("/greeting") 
   public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) { 
       return "hello"; 
   } 
 
}

As can be seen above, we have a controller ‘HelloController’, that will handle HTTP requests from http://localhost:8080/helloWorld/greeting . The function that handles ‘postMapping’ is called ‘greetingSubmit’, and it takes a Plain Old Java Object (POJO) as input, which, in our case, is our ‘Greeting’ object. For more details on the ‘Greeting’ object, see the code block below:

public class Greeting { 
 
    private long id; 
    private String content; 
 
    public long getId() { 
        return id; 
    } 
 
    public void setId(long id) { 
        this.id = id; 
    } 
 
    public String getContent() { 
        return content; 
    } 
 
    public void setContent(String content) { 
        this.content = content; 
    } 
 
}

Next, we’ll compile the project and host it on a Tomcat server to exploit it. When we try calling our application, the input is transformed into a POJO i.e., the ‘Greeting’ object.

Behind the scenes, the framework uses serialization to transform this input, which makes it possible for external users (attackers) to set other values. For this, we can search for values that can be set using query parameters.

After a bit of research, it appears that we can set the properties of ‘class’. We can then find properties of ‘class’ that we can both write to and is also relevant to the program’s execution.

From the exploit code above, it can be seen that the following Tomcat logging properties can be set:

class.module.classLoader.resources.context.parent.pipeline.first.pattern 
class.module.classLoader.resources.context.parent.pipeline.first.suffix 
class.module.classLoader.resources.context.parent.pipeline.first.directory 
class.module.classLoader.resources.context.parent.pipeline.first.prefix 
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat

To show this in action, we’ll run the Python exploit.

When the final request is sent, the property values that have been set by the exploit code will be used to achieve a remote code execution (RCE). For this, visit the newly created web shell located at http://localhost:8080/shell.jsp and modify the GET parameter ‘cmd’.

Note: The payload from the ‘pattern’ property set above, will be written to the following file: ‘webapps/ROOT/shell.jsp’. The query parameter ‘cmd’ can be used to pass in an arbitrary command.

How to protect yourself from Spring4Shell?

Anyone that utilizes the Spring framework should upgrade to version 5.3.18 or 5.2.20 as soon as possible.
The Apache Software Foundation has also released patches for Apache Tomcat 10.0.20, 9.0.62, and 8.5.78, which close the attack vector on the Tomcat side.
Spring developers have also released corrected versions of the Spring Boot 2.5.12 and 2.6.6 extensions, which rely on Spring Framework 5.3.18.
If you can’t upgrade the aforementioned software for some reason, you can use one of the workarounds listed on the official Spring website.

References:

Check out our new blog, NGINX zero-day vulnerability, Hacking Electron Apps

“Join us on our journey of growth and development by signing up for our comprehensive courses, if you want to excel in the field of cybersecurity.”

Connect with us: Cyber Security Services, LinkedIn, Twitter, Facebook