Convopage
See the entire conversation
Can confirm! The #Spring4Shell exploit in the wild appears to work against the stock "Handling Form Submission" sample code from spring.io
If the sample code is vulnerable, then I suspect there are indeed real-world apps out there that are vulnerable to RCE...
I was able to confirm that the #Spring4Shell exploit works against the "Handling Form Submission" tutorial from here: spring.io/guides/gs/hand… 😮
Methodology followed (thanks esell & @BobTShoplifter)
gist.github.com/esell/c9731a7e…
51 replies and sub-replies as of Apr 01 2022
Ways that Cyber Kendra made this worse for everyone:
1) Sensational blog post indicating that this is going to ruin the internet (red flag!).
2) Linking to a git commit about deserialization that has absolutely nothing to do with the issue demonstrated by the original party.
The original researcher also made this a touch more confusing/misleading than it needed to be as well. To one not familiar with Java, the long list of requirements makes it seem like one may need to intentionally make an app vulnerable. This is not the case.
What is TBD is:
What actual real-world applications are vulnerable to this issue?
Or is it likely to affect mostly just custom-built software that uses Spring and meets the list of requirements to be vulnerable.
Note that Spring has an advisory out on this:
spring.io/blog/2022/03/3…
Specifically important is: Spring Framework 5.3.18 and 5.2.20 address this vulnerability.
Relevant fixes are in CachedIntrospectionResults
github.com/spring-project…
github.com/spring-project…
I've published a note, now that we have the official CVE-2022-22965 designation for #SpringShell / #Spring4Shell
Nothing novel revealed there, but it should at least help for official tracking.
CERT/CC Vulnerability Note VU#970766
Spring Framework insecurely handles PropertyDescriptor objects with data binding
kb.cert.org
I'm not sure why it took so long for me to notice, but the screenshot right in that original report calls out exactly where shenanigans begin: getCachedIntrospectionResults()
The patch for CVE-2022-22965 fixes CachedIntrospectionResults, which is invoked by this function.
Interesting that nvd.nist.gov/vuln/detail/CV… is still a 404, and cve.mitre.org/cgi-bin/cvenam… still shows as "reserved".
Some scanners will only show it as a vulnerability only after those sites are updated.
Not particularly interesting / novel. CVEs on the Mitre site are often delayed by up to several months
CVE ID CVE-2022-22965 Spring Framework
Still waiting patiently. I don't think we'll have to wait long, though.
Code analysis is showing (did some tracing) it is dependent upon class loader type. If you’re spring boot embedded or docker you’re likely fine. If you’re a war deployed to an app server watch out. I haven’t traced the change between Java 8 and 9 which makes Java 8 immune
I am also disappointed by @sans_isc for reposting half-baked information on this.
Re: Spring 0day
Is JDK a requirement only for *building*, or the target must *run* the applicaiton with JDK in classpath?
Now I see that phrasing might not be accurate enough: I'm interested in JRE-only vs. JDK runtime environments (version req. is clear).
I'm not so sure about this. Spring with embedded tomcat still reports an HTTP 400 with the Randori test, so I'd probably bet that this is a case of "The PoC as it is won't work in embedded mode" as opposed to "Isn't vulnerable"
correct, it does not matter how this was deployed. the issue is a defective security check in CahedIntrospectionResults.java. It is meant to filter class.getClassLoader() and "forgets" about class.getModule().getClassLoader()
notice that the check sees "Class.class == beanClass" as "false" since "beanClass == java.lang.Module", hence this gets past the "continue" statement.
Kicker is if the class loader lets things happen - embedded runs a different class loader vs a war deployment
I’ll reiterate doesn’t mean not something else in there - but this particular exploit should get blocked at the class loader. Spring says it well - may be other ways to exploit this…
oh, and to avoid misconceptions: the vulnerability exists in Spring, the leaked exp.py only works on Tomcat - there are probably lots of Spring apps that are not exploitable and lots of custom exploits not relying on Tomcat (see official statement)
I am sure there are some apps and I am curious to see what comes out.
Cyber Kendra absolutely made this worst by sensationalizing, but the GitHub commit that they posted actually came straight from the original README:
"[Spring 制作中的补丁链接](github.com/spring-project…)"
Deprecate SerializationUtils#deserialize · spring-projects/spring-framework@7f7fb58
Since SerializationUtils#deserialize is based on Java's serialization mechanism, it can be the source of Remote Code Execution (RCE) vulnerabilities. Closes gh-28075
github.com
Whoops, worse*
Yeah, which is even worse if it was copied without verifying accuracy.
Considering the vast majority of CK-referencing posts on social media are spammed by a single user too 😬 reddit.com/search/?q=site…
I still want to know who Kendra is.
Cyber Kendra is apparently run by somebody named Vivek Gurung. See their Google+ page for more details:
web.archive.org/web/2019031921…
But this answer is disappointing.
Kendra = Hindi for "center"
Oh, like Cyber Center?
Cool, TIL. Thank you!
For me the warning flags in that post were the instructions to rename .war to .zip (and .jar to .zip). This, to me at least, said that they weren't entirely knowledgeable on the issue (there was no reason to do that), while making some wild speculations as to it's impact.
Yeah I had a feeling lol the vulnerable code I saw looked like bog standard Spring
I haven't tested this bug 100% yet but... is it potentially affecting or just Spring over Tomcat or any serverless Spring implementation? Thanks!!
Excellent research.
I also tested this with a fresh app on Mac and Tomcat 9.0.60. Didn’t quite succeed yet, which makes me suspect that it may work slightly differently on different platforms and versions. The vuln is there, but final step still missing.
How much of a concern is this, Will?
One question, do you get the shell without tomcat? Maybe with gradlew?
How do you fix it
Does anyone know if the exploit has to be on 8080 or the port to map to the tomcat portal ?
Can you confirm that to recreate this you had to run the same project inside tomcat? and not running the standalone project with embedded tomcat?
In my testing that demonstrated successful exploitation, I imported a WAR file into a system-wide tomcat instance. I did not test standalone w/ embedded.
(No comment)