Spring4Shell
Exploiting a remote code execution vulnerability
What is 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 waswere 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.
About this lesson
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!
How does Spring4Shell vulnerability work?
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.
curl -X POST \ -H "pre:<%" \ -H "post:;%>" \ -F 'class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{pre}i out.println("HACKED" + (2 + 5))%{post}i' \ -F 'class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp' \ -F 'class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/myapp' \ -F 'class.module.classLoader.resources.context.parent.pipeline.first.prefix=rce' \ -F 'class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=' \ http://mydomain/app/sendmessageWhat is the impact of Spring4Shell?
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).
How do you mitigate Spring4Shell?
The recommended mitigation strategy for the Spring4Shell vulnerability is a reasonably straightforward minor version update:
- Upgrade Spring Framework to a version equal to or greater than 5.2.20 or 5.3.18.
- 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:
<properties> <spring-framework.version>5.3.18</spring-framework.version></properties>- 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.
Keep learning
- See the vulnerability in the Snyk Vulnerability DB
- Check out all the vulnerabilities for Spring Beans here
- 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.
What to learn next?
Open redirect
Insecure deserialization
