Spring4Shell: CVE-2022-22965
Exploiting the Java Spring Framework - https://tryhackme.com/room/spring4shell
Last updated
Exploiting the Java Spring Framework - https://tryhackme.com/room/spring4shell
Last updated
In late March 2022, two remote command execution vulnerabilities in the Java Spring framework were made public. The first of these vulnerabilities affects a component of the framework called "Spring Cloud Functions". The second, arguably more serious vulnerability, affects a component in "Spring Core" — the heart of the framework — thus significantly increasing the vulnerability's potential impact and earning it the name "Spring4Shell" (a play on Log4Shell, the name of a brutal vulnerability disclosed at the end of 2021).
Spring4Shell was originally released as an 0-day in a now-deleted thread of Tweets. It was quickly identified as a bypass of the patch for CVE-2010-1622 — a vulnerability in earlier versions of the Spring Framework which allowed attackers to obtain remote command execution by abusing the way in which Spring handles data sent in HTTP requests. In short, the vulnerability allows attackers to upload a "webshell" (a piece of code which accepts commands from the attacker that the webserver is then tricked into executing) to the vulnerable server, achieving remote command execution.\
To understand Spring4Shell, it is important that we understand CVE-2010-1622. Spring MVC (Model-View-Controller) is part of the Spring Framework which makes it easy to develop web applications following the MVC design pattern. One of the features of Spring MVC is that it automatically instantiates and populates an object of a specified class when a request is made based on the parameters sent to the endpoint. In simple terms, this could be abused to overwrite important attributes of the parent class, resulting in remote code execution.
Spring4Shell works along similar lines, bypassing the mitigations that were added to patch CVE-2010-1622. The majority of the exploits for the Spring4Shell vulnerability operate by forcing the application to write a malicious .jsp
file (effectively plaintext Java which Tomcat can execute — much like a PHP webserver would execute files with a .php
extension) to the webserver. This webshell can then be executed to gain remote command execution over the target.\
Fortunately, despite how commonly used the Spring Framework is, the conditions in which the vulnerability can be exploited are actually fairly limited.\
The Spring4Shell vulnerability affects Spring Core before version 5.2, as well as in versions 5.3.0-17 and 5.2.0-19, running on a version of the Java Development Kit (JDK) greater than or equal to 9. The publicly available exploits currently available only work on applications deployed to Apache Tomcat as WARs; however, the Spring Framework maintainers have stated that they believe there may be other ways to exploit the vulnerability.
Current conditions for vulnerability (as stated in Spring's announcement of the vulnerability) can be summarised as follows:
JDK 9+
A vulnerable version of the Spring Framework (<5.2 | 5.2.0-19 | 5.3.0-17)\
Apache Tomcat as a server for the Spring application, packaged as a WAR
A dependency on the spring-webmvc
and/or spring-webflux
components of the Spring Framework\
It is worth noting, however, that these may change over time as other ways to exploit the vulnerability are discovered.
You should always review unknown exploits before running them.
Using this Proof of Concept Python Script:
We can attack a vulnerable web server
Lets look at the source code ctrl + u
Specifically we are looking for the "action" of the contact form (the only POST request available to us). This is found on line 18:
<form id="contactForm" action="/" method="post">
The action is "/
", meaning that our target URL will simply be: http://10.10.151.162/
.
Note: the trailing slash is very important here!
Lets check the script inputs real quick
Looks like running ./exploit.py
http://10.10.151.162/
should just work
And it looks like we have command execution!
We are definately root!
Lets get a real shell now so we want to get burpsuite open and prepare our shell on our attackbox
On our attack box I am running nc -lvnp 9001
Time to capture the id request in burp
First enable burp in foxy proxy
Then we want to send the request we captured in burp to repeater
After a few tries I found the box has python3
On our web shell we are going to run a python reverse shell from Pentestmonkey
At this point I was having issues with bad characters and getting a reverse/bind shell working. I am not sure if it was a limitation of the environment but I plan on revisiting this.