Spring4Shell

CVE-2022–22965, aka Spring4Shell, is a critical remote code execution (RCE) vulnerability in the Spring Framework (versions 5.3.0 to 3.5.17, 5.2.0 to 5.2.19, older unsupported versions). The Spring Framework is an open source framework for building web applications in Java and is widely used. Spring Boot simplifies the process to build stand-alone, production-grade Spring based Applications that you can "just run".

The Spring4Shell vulnerability was identified on March 29, 2022. Unfortunately, proof of concepts demonstrating the exploitation of the vulnerability were leaked online before the Spring team released a patch, resulting in Spring4Shell being a zero-day vulnerability.

The Spring maintainers released patches on March 31, 2022, mitigating the vulnerability.

In this lesson, you will learn how to exploit Spring4Shell, what it looks like under the hood, and how to secure your application. We'll begin by exploiting this bug in a vulnerable Java application. After that, we'll learn more about what the Spring4Shell bug looks like under the hood. Finally, we'll fix up the Java application to prevent any further exploitation of the Spring4shell bug.

Ready to learn? Get comfy and get ready! Let’s get started!

W1nt3r, the notorious hacker, was hacking away at their newest target secretgreetings.io, making little to no progress.

W1nt3r finds a page that allows the user to send a message. Hmm… there might be something interesting here. We can type any message in the message box and when we click submit, we’ll be taken to another page. But maybe this is an attack vector. More work needs to be done but all this hacking is making us tired.

It was time to take a break and see what's been happening on Twitter. "What is this?!"

"A vulnerability in Spring Core?! what are the chances my target is vulnerable?" After reading up on the Spring4Shell vulnerability (we'll get to this later), W1nt3r thinks this might be the way in. Let's see if we can help W1nt3r out.

First, let’s see if our target may be vulnerable by enumerating some of its technology stack. We’ll use a basic nmap scan:

Copy and paste the following into the terminal below and hit enter:

nmap -sV secretgreetings.io -p 80

Interesting... Tomcat is a Java applet server, and version 9.0.56 was prior to the Spring4Shell patch. It may be vulnerable!

Thinking that the target may be vulnerable, we can attempt an exploitation.

Let's write some exploit code that can be sent to the target using curl.

This exploit, if successful, will allow W1nt3r to run commands remotely on the target (called Remote Code Execution or RCE).

W1nt3r ran this in the terminal and didn't receive an error so it may have succeeded. Time to check if the exploit was successful.

Copy and paste the following curl command into the terminal and hit enter to execute our created payload:

curl --output - "http://secretgreetings.io/app/rce.jsp?cmd=id"

Check out the Snyk blog post "Spring4Shell: The zero-day RCE in the Spring Framework explained" for an in-depth look at the inner workings of the Spring4Shell vulnerability.

To summarize:

In the affected versions of Spring Framework, an RCE is achievable by abusing the RequestMapping annotation feature via carefully crafted HTTP requests.

The RequestMapping annotation maps web requests onto methods in request-handling classes.

By abusing RequestMapping, an attacker can access and modify nested class properties due to how Spring Core performs the request parameter binding using serialization.

The specific nested object used when exploiting the Spring4Shell vulnerability is class.module.classLoader. Through the classLoader object, an attacker can execute malicious code on the vulnerable server, resulting in RCE. In this case, it is possible due to the specific implementation of the ClassLoader class in the Tomcat server.

The Spring4Shell vulnerability allows an attacker to perform remote code execution on an application server running a vulnerable configuration, giving them full access to the compromised server. It should be mentioned that while a high number of Spring installs were vulnerable, not all Spring applications were.

Spring4Shell was given a critical severity score of 9.8 by Snyk. This score was given as the vulnerability can be exploited by an unauthenticated user over a network, resulting in an RCE (one of the most significant impacts on a system).

The recommended mitigation strategy for the Spring4Shell vulnerability is a reasonably straightforward minor version update:

1. Upgrade Spring Framework to a version equal to or greater than 5.2.20 or 5.3.18.
2. If you are using Spring Boot directly, upgrade to a version equal to or greater than 2.6.6.

Upgrading Spring Framework can be done:

• using Maven 23123, edit your pom.xml:

  5.3.18

• using Gradle, edit your build.gradle:

  ext['spring-framework.version'] = '5.3.18'

If you cannot update your version of Spring Framework for some reason, the Spring team has provided some other viable workarounds. these include:

• Downgrade to JDK 8
• Disallow binding to particular fields

These workarounds should not be treated as permanent solutions. They do not directly fix the underlying bug that caused the vulnerability. A plan should be put in place to upgrade the Spring Framework versions when possible. Software Component Analysis Tools like Snyk Open Source are of great help here. They will scan the dependencies of a project (and the dependencies of dependencies named transient dependencies) for known vulnerable elements and suggest a mitigation strategy. In the case of Snyk Open Source, the fix is applied by the click of a button.

• See the vulnerability in the Snyk Vulnerability DB
• Check out all the vulnerabilities for Spring Beans
• Spring4Shell: What we know about the Java RCE vulnerability
• See what Spring has to say about the vulnerability
• Take a look under the hood at the Git repo for Spring and how this vulnerability was fixed
• Read about an update to this vulnerability