Spring Core on JDK9 is vulnerable to remote code execution
1–10 of 73 posts
Re: Spring Core on JDK9 is vulnerable to remote code execution
#2Possible 0-day RCE impacting Spring applications.
Re: Spring Core on JDK9 is vulnerable to remote code execution
#3Possible 0-day RCE impacting Spring applications.
Possible...
Re: Spring Core on JDK9 is vulnerable to remote code execution
#4Looks like another "I'm in a 'safe' language, so can do unsafe things" crossed with the standard object deserialization error of default allowing any class to be instantiated.
The temporary fix that they list seems to imply that the current APIs don't allow specifying a finite list of allowed classes?
Re: Spring Core on JDK9 is vulnerable to remote code execution
#5“This vulnerability allows an unauthenticated attacker to execute arbitrary code on the target system.”.
Interesting that the CVE has been around for so long.
Re: Spring Core on JDK9 is vulnerable to remote code execution
#6JDK9+? Not just 9.
Re: Spring Core on JDK9 is vulnerable to remote code execution
#7I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it is the fact that a lot of the people reporting on it self-admit that they are unfamiliar with Java and Spring. One “PoC” repo I’ve seen is just simple API misuse. API misuse is a CVE in the application that does the misusing, NOT the library that is misused (in this case spring).
Something else is that very soon after there was a /hint/ of a log4j exploit, we saw rapid and evolving exploitation in the wild. We have nothing like that happening now, since this news first broke, what, 12 hours ago?
Then there’s also the suspicion where I feel the LunaSec people, one of the first groups to report on this, are desperately trying to re-catch the fire they caught when they first reported log4j. I’m sure that was amazing for marketing their company. Problem is, I think reporting on this before there is really indication of a real issue reduces the credibility of them as competent security researchers.
Of course, I may come back to eat my words.
Re: Spring Core on JDK9 is vulnerable to remote code execution
#8(Author that named "Log4Shell" here)
FYI, this is confusing because there are 2 different RCEs that have been published within the last 24 hours. One has a CVE and the other doesn't.
OP's post by Praetorian is discussing the RCE dubbed "Spring4Shell".
It's the RCE without a CVE yet, hence the name, and it affects Spring Core. It's likely fairly widespread/severe, but the "mitigating details" are still unknown.
That said, it's very similar to the Apache Struts vuln that popped EquiFax a few years ago. (a Class Loader Manipulation exploit) So there is already some tooling available to weaponize it.
The other RCE affects Spring Cloud Function and has been given CVE-2022-22963.
We wrote a post[0] with info on both CVEs that references this Praetorian post under the "Remediation" section. We also added more information about the exploit scenarios to help push the ball forward for determining how widely exploitable this is going to be.
(There is a 3rd possible one too, but it's still unconfirmed.)
Basically, the authors of Spring Core tweeted[1] that there wasn't a vuln and that has added to the chaos of this. There is a vuln here. It's not as bad as Log4Shell, but it's still bad and likely widely exploitable given how popular Spring Core is and how some Java devs[2] have confirmed that the exploitable configuration is a "common pattern" in real-world usage.
With the vuln there are more steps required for exploitation. That means kids on Minecraft won't be griefing each other with it, but that won't stop the blackhats from weaponizing this quickly. After all, this is a very similar attack to previous ones in Struts[3].
So if you're using Spring Core or Spring Cloud Function, it's a good idea to stay up-to-date on this stuff because it's moving pretty quick. If you already looked earlier this morning, a lot has changed (like this Praetorian post).
It'll be a fun weekend for security teams everywhere!
0: https://www.lunasec.io/docs/blog/spring-rce-vulnerabilities/
1: https://twitter.com/hacksilon/status/1509117953064812547
Re: Spring Core on JDK9 is vulnerable to remote code execution
#9I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it is the fact that a lot of the people reporting on it self-admit that they are unfamiliar with Java and Spring. One “PoC” repo I’ve seen is just simple API misuse. API misuse is a CVE in the application that does the misusing, NOT the library that is misused (in…
LunaSec founder here.
I can understand the suspicion. It's the right mindset to have when looking at CVEs, in general, because 99% of them are overblown. The first title I wrote for the blog post was "There is no vuln" but I was wrong. Only after I spent a few hours digging did my gut change my mind.
In this case I wrote the post to discuss 2 different vulns. One was a confirmed RCE with a CVE and the other was a WIP with only sketchy Twitter screenshots to go on. That alone was confusing many people and was the reason many people were posting about finding an "RCE POC" without realizing they were talking about the wrong vuln. That was the primary reason that we (LunaSec) wrote the original post -- to help people understand that there were 2 vulns and that they needed to be careful to confirm which they were discussing. There was too much unwarranted hype, too much confusion, and too little "real" information to prove/disprove if an exploit was possible.
That said, at some point as researchers, we have to trust our gut about potential impact and exploitability without full knowledge of the vuln. With Log4Shell, when we wrote that post, we hadn't personally proven that the JNDI vulnerability could be exploited. It just felt like a matter of time before it would be figured out by somebody much smarter that us. And with this exploit and the people discussing it, it felt like there was likely something there (which has turned out to be true, retroactively).
So that's the line, as researchers, that we have to balance by attempting to provide an "early warning" for companies/devs while also not just sitting for days with the vulnerable code (in this case Spring) to prove out an exploit until a bunch of blackhats already move on to mass exploitation.
Anyway, at this point, people that I trust a lot have come forward to say that they were able to verify the exploit with a POC themselves. Specifically, @pwntester has tweeted about this[0][1] confirming that he's been able to get an exploit. He's a very good Java dev that is much, much faster than myself or anybody else on my team.
--------
In this case, I noticed some people talking about it on Twitter and tried to put together info to help people "prove out" a POC with a "basic vulnerable app". Then I went to bed and looked at this again.
That's when I realized that this was very confusing because there were multiple vulns being conflated in different libs. And then the Spring devs said that this wasn't an issue, but it very much still felt like there was the possibility for an exploit still. It turned out to be "Class Loader Manipulation" instead of "Deserialization injection" but the activity relating to this on Twitter was real.
I sat with my engineers for several hours just poking at getting a POC working and we're very confident that, with a little more time, we'll be able to turn this into a POC like the Struts one. We're just not Java guys so it's slow. Getting a debugger takes time, understanding Spring takes time, etc. There are much more competent devs and researchers out there than us -- we're just trying to reduce the uncertainty and misinformation in a way that helps companies patch faster.
Communicating clearly about hard technical subjects while also writing POCs on-the-fly is difficult, and I apologize if what I wrote came across as more "corporate shill" than "security researcher trying to reduce entropy". That's on me!
0: https://twitter.com/pwntester/status/1509240072301912074
1: https://twitter.com/pwntester/status/1509248853614239747
EDIT: Clarified some text
Re: Spring Core on JDK9 is vulnerable to remote code execution
#10I am still deeply skeptical that this exploit really exists, or if it does, it is extremely exaggerated. I can’t really articulate the reasons why. Part of it is the fact that a lot of the people reporting on it self-admit that they are unfamiliar with Java and Spring. One “PoC” repo I’ve seen is just simple API misuse. API misuse is a CVE in the application that does the misusing, NOT the library that is misused (in…
I'm skeptical as well because everyone is saying they've reproduced it, but there's no CVE and none of them want to post the source code to reproduce it. It's all "use this closed source docker image" or "it was in this now deleted github" or "it was in this now deleted twitter leak".