Detecting and Responding to Spring4Shell with Splunk
It’s that time of the week again when you are just about ready to sit back with a nice glass of Longmorn 16 & long no more. But then, some ding-dong leaks a PoC exploit for an app framework you’ve never heard of on GitHub & ruins your entire weekend plans. Why? Because we can already see the bad guys scanning for vulnerable targets, and it’s a bloody Thursday, so close to the weekend! So that means reading up on ClassLoader manipulation, forking the PoC exploit from GitHub, developing detection rules, & downloading a couple dozen WAR files, unpacking it, and grepping for freakin’ beans man! There goes my weekend. Not cool dude, not cool at all!
In Layman’s terms
So, what is this vulnerability exactly? The vulnerability is caused by getCachedIntrospectionResults() which returns a class object accessible by web app users. An attacker can craft an HTTP request with a malicious payload that alters Tomcat’s logging mechanism to basically write a file in the web apps’ directory. Now, imagine you can create a file on the web server and can access that file via an HTTP request later. Yep, web shells.
PoC Exploit
At the time of writing, the PoC exploit for CVE-2022–22965 is available here. Going through the code, we can see the payload in the variable data being POST’ed to the target. Checking the value of the data variable & URL decoding reveals how the exploit is getting Tomcat to write a shell into the ROOT directory.
Let’s see what’s in pattern?
java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream();Once, this request is sent to the vulnerable server, you have a webshell on the server and can be used to execute commands as detailed below.
Detection
Florian Roth has shared a list of YARA rules and can be found here.
A JSP web shell is pretty trivial to detect. I’ve shared a few on my GitHub page. If you’ve a WAF, I’d recommend enabling profiles that block ClassLoader manipulation.
If you’re using logstash, sometimes it can throw errors & write interesting stuff in Linux messages syslog. The same can be detected with the following SPL.
If you’ve audit configured on the target host, you can write detections for webshell creation in the web app ROOT directory. Haven’t had time to look into it, will update my GitHub CVE-2022–22965 detection repo once I have created a detection for it.
Vulnerable WARs?
If you need to check whether any of the WAR packages deployed in your environment use the affected components, collect the suspect WAR files, unzip & find JARs matching the following pattern. Check the output for the vulnerable versions of Spring.
find WEB-INF/lib/ | grep "spring-beans-5.*\.jar"I’d come across this post which has more information on helping you figure out if you’re vulnerable; keep in mind that there’re a few prerequisite conditions to be met for the target to be vulnerable.
Well, that’s pretty much it for now folks. I’m off to pour myself a dram of Longmorn 16. Happy hunting..
References:
- https://tanzu.vmware.com/security/cve-2022-22965
- https://spring.io/blog/2022/03/31/spring-framework-rce-early-announcement
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22965
- https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html
- https://www.rapid7.com/blog/post/2022/03/30/spring4shell-zero-day-vulnerability-in-spring-framework/
- https://www.praetorian.com/blog/spring-core-jdk9-rce/
- https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
