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...
If the sample code is vulnerable, then I suspect there are indeed real-world apps out there that are vulnerable to RCE...
https://twitter.com/th3_protoCOL/status/1509345839134609408
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.
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.
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.
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…
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.
kb.cert.org/vuls/id/970766
Nothing novel revealed there, but it should at least help for official tracking.
kb.cert.org/vuls/id/970766
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.
The patch for CVE-2022-22965 fixes CachedIntrospectionResults, which is invoked by this function.
For local scanning of code vulnerable to CVE-2022-22965, this seems to do the trick:
github.com/hillu/local-sp…
github.com/hillu/local-sp…
For remote scanning of a live web server even w/ just curl and looking for HTTP 400, that's possible, but trickier:
1) You need to know that the target is even tomcat.
2) You need to know the relevant endpoint to hit.
3) You need to test both POST and GET.
1) You need to know that the target is even tomcat.
2) You need to know the relevant endpoint to hit.
3) You need to test both POST and GET.
https://twitter.com/sudochmod4777/status/1509554630342152192
In case anybody is curious how the local scanner works, it's just comparing the hashes of the CachedIntrospectionResults.class file against known-vulnerable versions. This picked up all of the vulnerable components I happened to have handy for testing.
github.com/hillu/local-sp…
github.com/hillu/local-sp…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
