What is Spring4Shell?
Spring4Shell is the name given to a critical remote code execution vulnerability that was disclosed on March 30, 2022. It is particularly a part of the spring-beans package, a dependency in both spring-webmvc and spring-webflux.
Not to be confused with CVE-2022-22963 which is another Spring vulnerability that also came out shortly before the Spring4Shell which is CVE-2022-22965. Check out this blog to know more about how to detect the Spring4Shell exploitation.
Who is impacted?
This vulnerability affects two Spring Frameworks: Spring MVC and Spring WebFlux, both are used for web development. This vulnerability can only be exploited if the application is running on top of Apache Tomcat, and when it’s deployed as a WAR file.
Mitigations and Remediation
According to the early announcement published by Spring, an update is available to mitigate this vulnerability viz Spring Framework 5.3.18 and 5.2.20 or greater. The Spring community also suggests some workarounds like upgrading Apache Tomcat or downgrading Java as it is not possible to upgrade every application out there. Different vendors using the Spring framework are also coming forward and releasing their own advisories for patching or remediating these issues on their software.
Exploit Explanation
Our installations are vulnerable If we have a controller with a request mapping loaded into the memory. In the given example below you can see PrintController with a PostMapping to /print. When this endpoint https://localhost:8080/print is invoked, it transforms the input into a POJO (Plain Old Java Object) which is the Print object in the example below:
@Controllerpublic class PrintController {@PostMapping("/print")public String greetingSubmit(@ModelAttribute Print print, Model model) {model.addAttribute("print", print);return "result";}}
Spring uses serialisation internally to map these values to the java object. This can also be used to set other values. Turns out you can set properties of a class as these values. Things would be clear when we run this on Tomcat.
To show this in action, we can use the following curl to create a rce.jsp file through some logging properties of the class:
This file is now served and available at http://localhost:8080/rce.jsp.
Everything that we set in the pattern would end up as the content of the file where our exploit lies. With some escaping and use of headers, you should be able to create a JSP file on the Tomcat server containing the content that we provide in the request. Then, host a JSP file with some commands that can be executed remotely using Java methods or host a reverse shell to get access to the system and escalate it from there.
Now, you can run the below curl command and they should be able to execute commands on the system. Just pass the command you want to execute to the cmd parameter.
# curl --output - "http://localhost:8080/rce.jsp?pwd=j&cmd=whoami"
References
