Wicked Good Development is dedicated to the future of open source. This space is to learn about the latest in the developer community and talk shop with open source software innovators and experts in the industry.
Did Spring4Shell set the internet on fire again? Not so fast. In a special episode of Wicked Good Development we dissect the zero-day RCE vulnerability in the Spring Framework dubbed Spring4Shell or Springshell. From comparisons to Log4j to how to remediate it and what versions on vulnerable, the experts on today's show break down what we know so far about this new vulnerability. And most importantly, how to determine if you're effected.
You can stay up to date on all things Spring4Shell on our resource center.
Wicked Good Development is available wherever you find your podcasts. Visit our page on Spotify's anchor.fm
Spring4Shell, Java, JDK9, Log4j, Open Source vulnerabilities
Kadi Grigg: [00:00:01] Hi, my name is Kadi Grigg. Coming to you live from Sonatype today, we're here for a conversation with senior security researcher, Ax Sharma, another security researcher, Juan Aguirre and we have Developer Advocate Steve Poole. Thank you all so much for joining today. Before we dive in, I know the topic of conversation we'll aoll be discussing today is the SpringShell. So before we get into it, Ax, do you want to give us a high level overview currently where we're at? Why has my Twitter feed been blowing up for the past 48 hours over SpringShell? [00:00:34][32.9]
Ax Sharma: [00:00:34] So yes, it’s been a crazy last 48 hours. I don't think anyone got much sleep in the InfoSec space. To give a quick recap, it all started with sort of a rumor. Based on one comment that was vastly unrelated to remote code execution - A Spring developer made this comment. It was just deprecating untrusted serialization. Somebody thought it was fixing a bug, or there was some confusion. That advisory went on a QQ chat and that led to, you know, some vague advisories on the internet alleging that Spring has this new SpringShell vulnerability, but no one had at that time - Like early hours of yesterday, nobody had a working POC at that time. To make matters worse there were also two more spring CVEs, especially the SpEL, expression injection one, which is in the Spring cloud function that complicated matters a little bit causing confusion.
Kadi Grigg: [00:01:33] So all this has been going on, and there's a lot of confusion, all coming from Twitter. So my question is we know a little bit about how it got uncovered, but what's affected? [00:01:46][12.8]
Ax Sharma: [00:01:47] Absolutely. So the SpringShell vulnerability has now officially been confirmed in the spring-beans component, and it's been assigned to just a few hours ago, an advisory came out as well. I will let Juan kind of go into the remediation details of it, either now or later, but I just want to let everyone know that SpringShell has been confirmed by Spring maintainers now and that they released fix versions. [00:02:12][24.4]
Kadi Grigg: [00:02:15] Before we get into the remediation, though, I just want to talk about how do you know before, even before you go through that phase - is how do you even know if you're affected? [00:02:23][8.0]
Juan Aguirre: [00:02:25] We can go over that a little bit. So initially, you know, there was like a big mess on the internet. A big scandal. Everybody thought, you know, this is huge. We're all affected. But there are certain conditions that need to apply for you to actually be affected and this to be exploitable in your application. And there's a few. So let's just quickly go over them. JDK9, for the Java version, you're going to be using in your applications. You're going to need JDK9 or higher. Although, you know, nowadays, you should be using 9 or higher, if lower, it's about time to update. [00:03:05][39.7]
Steve Poole: [00:03:06] Yeah. So that's what is weird is that in this particular instance, if you’ve been tardy in moving off Java8 then you’re safe, but of course you're safe from this, but then you'll be vulnerable for all the other vulnerabilities. And of course as a community, we've been pushing people for a long time to move to java 8 and move away from java7. But yes, it's just slightly ironic that if you're an old version, you're not affected you know, at least one of the versions [00:03:38][32.2]
Ax Sharma: [00:03:39]. The line is not too clear. But could you maybe go over the untrusted deserialization aspect of this? Because I think you tried a POC as well and I want the readers who are not familiar with deserialization [to know] how is that relevant here. [00:03:50][11.2]
Steve Poole: [00:03:51] Yeah. So that seems to be the case now,with vulnerabilities, they come almost always with a proof of concept. And as we've seen with Log4J and now with these two, they are pretty trivial POC. The effect on both - whether we look at the SpEL one or whether we look at the Spring4Shell, is effectively it's a very simple way for a bad actor to run arbitrary code on your server. One is slightly harder than the other but the net effect is, I can send you a payload that I can use to run any code I want, where the code that’s is already installed or possibly get into the wires of it. So in terms of RCE’s? It;s way up there as being very easy, and very dangerous. [00:04:45][54.3]
Juan Aguirre: [00:04:50] Yes, absolutely. The usually exploitable dangerous… and that's just getting into one of the factors of it, another thing that we need for this to also be a factor and exploitable in your applications is Tomcat, right? It needs to be deployed as a Tomcat, and it needs to be deployed as a WAR. [00:05:09][18.6]
Ax Sharma: [00:05:11] Right. So what Kadi asked, “how do you know you're vulnerable?” That really helps, Steve and Juan. But I still am trying to get a feeling personally, if it's like the real world impact. Are many mainstream applications impacted by this? Or is it like you have to be running? I don't know, like an inadequately secure application that can be breached using this? [00:05:32][21.1]
Steve Poole: [00:05:33] I don't think so. I think what we've seen, it's a vulnerability that pre-authentication checks. As far as I can see. We have the job, obviously with the Java 9 thing, and I think you have to go to a system that has modularity built in, which ironically is why this thing is available because the code that’s compromised is vulnerable made checks as to its operating environment, and it was written before Java modules and unfortunately, the check was not an inclusive one. So what happened was there was a new capability enabled by Java 9. And the Spring code didn’t disable the capability. So really any authoring version is at risk for this. And so what we said, the suggestions are literally to move to the latest of one of major things that we talked about, Tomcat. What's going on here is the vulnerability is able to redirect Java logging. So Tomcat is a logging system and what the vulnerability allows you to do is redirect logging to an arbitrary file of the chain, but also at the same time, the contents of the log is exactly what the bad guy wants. So what they've managed to do is write basically a very simple piece of code that runs on the machine using JSPs with another requirement that you have to have to be vulnerable. So, they write the vulnerable code on the test and then now they can call from the URL, and that will drive them back in. So it's slightly convoluted. But if you've got a new version of Java and you’ve got JSPs running and you’ve got Spring, that's the selection criteria, [00:08:00][147.0]
Juan Aguirre: [00:08:03] This is nothing like before with the redirecting of the logging or right to our - In this case, I guess you can create a Web Shell or a whole lot of other things and get your remote code execution so that that technique has been seen before, right? And they just found a clever way to leverage it here. Which I know from a security perspective… [00:08:29][25.5]
Steve Poole: [00:08:30] You said Web Shell. And I think that's something that's pretty common in programming languages. But I think that's the first time, I think for a long time. But I think it claims to be right with you. [00:08:44][14.1]
Kadi Grigg: [00:08:48] What are the steps that people should be looking at to do to help mitigate that risk profile if they are affected? [00:09:04][15.9]
Ax Sharma: [00:09:07] Yes. Well, I mean, upgrading to the latest version, like I said. I know they released the 5.3.18 today, keep me honest, Juan, and they backboarded to fix 5.2.20 and please keep an eye on the updated advisory released by VMware. The other steps you can take there's also a workaround provided by Praetorian as one of the companies, and their workaround also got included in Rapid7’s blog post. If you cannot get the latest version, yeah, but Juan, have you seen anything else or Steve like when comes to the remediation? [00:09:41][33.7]
Steve Poole: [00:09:42] No, I mean, we've got the very basic, which is what we need. [00:09:47][5.7]
Ax Sharma: [00:09:49] I think it's fast. Yet yesterday, we know it was a vulnerability today, well, [00:09:55][5.5]
Steve Poole: [00:09:55] As I said the problem was easily discovered. And so they do exactly what it wasn’t too complicated, which is a good thing Yeah, but it wasn't very meaningful discussion. I have not looked at much of the workarounds. See how it would get away from that? [00:10:18][23.3]
Juan Aguirre: [00:10:19] Yeah, this was a cause of an earlier insufficient fix for a 2010 CV, of a really old CV. So they knew exactly where to go in and try to implement this. So this is kind of also implementation dependent. You have to implement it in a certain way in your application to be vulnerable, right? You have to use it. You have to do the request mappings and you have to use plain old Java object. There's also some things you can do in the implementation to prevent it, which are some workarounds that are in the original Spring framework. And it's just based on how you use it out of binders and all that, right, the request mappings. So there are some workarounds they published in their official blog. But like expansion, you know that the best thing you can do is just update and you don't have to worry about going back and re-implementing all your applications and redeploying.. [00:11:19][60.0]
Ax Sharma: [00:11:20] I find it interesting you mentioned the data binder. I think in Springs’ docs, there was an explicit disclaimer that allowed fields that should be used with the data binder, right? And I think the 2010 CV you're offering, I’ll just spell it out for the audience. Even 2010 1622, I believe. Yeah. And the SpringShell official CV that's been released 2022 22965, that is not to be confused with other tools that they released, I will not spread rumors. [00:11:52][31.8]
Kadi Grigg: [00:11:55] Well, thank you for the clarity on that, as well as giving us the specifications that you know are vulnerable and things to be looking out for. I think my last question for you is we saw previously with Log4j that it kind of mutated over time. Do we expect to see any of that type of mutation with this vulnerability? [00:12:12][17.1]
Steve Poole: [00:12:15] Well, I think what we saw with Log4j was that there was a lot of confusion as to how damaging it was and that you could be compromised. And so it went off in a different direction. I hope that's not going to happen here. You said the conflating of a few vulnerabilities. But I think this would take a while is quite straightforward. And the consequences of that, we know exactly what happens there. All right. So I think this is great for next. I think we should be done with this one. Cross fingers. [00:13:01][46.3]
Juan Aguirre: [00:13:03] That's helpful thinking. I am not completely sure just because even in the Spring advisory, they themselves kind of go ahead and say, you know, that this is very general in the issue. So there could be other ways to exploit it that we're not aware of right now, right? They themselves are coming out and saying it. And the thing, though, is that since this was mainstream, all over Twitter, all over everywhere. So now they're going to be scrutinizing not just the face, but probably to other parts of the Spring, right? It's going to be in the eyes of all researchers now. So I think that also is the reason why it went on for so long and it's still going on. So I think it could also potentially happen here with all of the attention it is getting. [00:13:54][50.6]
Steve Poole: [00:13:55] Yeah. I mean, the other thing that we still see with Log4j is that people are still not fixing it. You know, we can have a whole conversation about why people are not fixing it. And to be honest with Log4, there’s likely to be some dependencies that would need to be updated rather than probably customers themselves. With the Spring framework, it's usually much higher up in terms of dependency so it is more obvious to people. So again, we hope that this will be fixed faster than Log4j was. But I do think the point is, people will have a look at this go and see if they can find other problems. [00:14:37][41.4]
Kadi Grigg: [00:14:38] All right - Final Thoughts. [00:14:42][3.8]
Ax Sharma: [00:14:43] I honestly, I've seen both names being used for this vulnerability, SpringShell and Spring4Shell. Whatever Spring Advisory is on, please follow the steps in it and additional information is coming out as we speak. That being said, to what Steve was saying is very interesting with Log4j because even today if you go to Sonatype’s Log4j dashboard or if just Google it I'm still seeing like 44% downloads even today there are Log4j versions. But it's a surprise. It's been months. [00:15:17][34.1]
Kadi Grigg: [00:15:20] All right. Well, you heard it here. Make sure you update, stay up to date. If you want more information on SpringShell, please go to dev.sonatype.com, you can see where the dashboards are at and get more information till we have more updates. Stay tuned. [00:15:20][0.0]