Dissecting the Spring4Shell vulnerability.

Dave Bittner: Hello, everyone. And welcome to the CyberWire's "Research Saturday." I'm Dave Bittner. And this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities, solving some of the hard problems of protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us.

Edward Wu: March 30, we started to hear rumors, as well as see different messages being posted in various channels, discussing a novel remote code execution vulnerability against the Spring Core framework. 

Dave Bittner: That's Edward Wu, senior principal data scientist at ExtraHop. The research we're discussing today is titled "A Technical Analysis of How Spring4Shell Works." 

Edward Wu: But unfortunately, at that specific time, Spring Core themselves did not acknowledge the existence of this vulnerability. So there were a little bit of confusion initially on whether there was indeed any vulnerability or not. And this was - also was a little bit interesting because initially, based on the rumors, similar to Log4Shell, this specific vulnerability, which later became the Spring4Shell, was also discovered by - it seems to be a party in China. And as a result of that, because of some of the repercussions that happened after Log4Shell for this specific vulnerability, whoever discovered it in China was very hesitant to share any information publicly because if - I'm not sure if you remember, but the party who discovered Log4Shell, which is Alibaba Cloud - they were fined by the Chinese government for publicizing this vulnerability with the entire world. So this time around, it turns out Spring4Shell was discovered by a subsidiary of Baba Cloud. And they were kept really quiet, which caused kind of the initial confusion where there were a lot of rumors, but there was not any confirmation from Spring Core or the party who discovered it. 

Dave Bittner: Isn't that interesting? I mean, that you have that kind of - I don't know - international intrigue, the diplomatic side of whether - or how quickly a vulnerability like this becomes public. 

Edward Wu: Yeah, exactly. And in this case, it seems even the Spring Core developers, looking at their eventual public disclosure - they were only notified a few days before the rumor got out, which is somewhat atypical compared to a traditional responsible disclosure model, where, typically, whoever discovers the vulnerability will generally give the software vendor a bit more time. And also, some of the rumor came out of various patching activities in Chinese internet companies because they knew about it, so they started patching it internally. And then some of the patching documentation got leaked out on Twitter. And then everybody else on the internet started to discover, hey, why are folks in China patching this seemingly very high-risk and high-impact Spring Core vulnerability and - but we have never heard about it? 

Dave Bittner: That's fascinating. Well, for folks who might be unfamiliar with it, can you explain to us what exactly Spring Core framework is? 

Edward Wu: So Spring Core framework is a application development framework for Java. In fact, it is one of probably the top three most popular Java web application development framework. And as a result of that, Spring Core is utilized to develop a very, very large array of web applications currently being used across the entire internet and the world. 

Dave Bittner: Well, let's dig into the actual vulnerability here. Can you walk us through, how was it pulled off, and what exactly is it capable of? 

Edward Wu: So from the high level, Spring4Shell vulnerability, which is later named as CVE-2022-22965, is a remote code execution vulnerability against the Spring Core framework. And it essentially enables or allows the attacker to gain full remote control of the target application server that is running Spring Core Framework by sending maliciously crafted HTTP or web requests. And this specific vulnerability has a CVSS score of 9.8, which is pretty much as high as it gets... 

Dave Bittner: Right. 

Edward Wu: ...In terms of impact and severity. 

Dave Bittner: So how would someone go about exploiting this? What exactly do they have to do? 

Edward Wu: Yeah, that's a good question. So in order to exploit this specific vulnerability, the attacker essentially have to craft the - a malicious web request that contain specialized bits that overwrite certain sensitive variables and program state within the target Java server application. And by doing that, the attacker could achieve a number of things. For example, the most common way to exploit this vulnerability is by remotely - crafting a web request that remotely modifies the Java logger - application logger within the target application. And by modifying the Java logger, the attacker will be able to trick the logger into writing and creating a web shell on the target application server. And once a web shell is - has been implanted on the server, attacker will be able to access the web shell remotely and then essentially get full kind of a command line access to the target server. 

Dave Bittner: Wow. And that's the ballgame. 

Edward Wu: Yep. 

Dave Bittner: Yeah. So when you rate sort of the sophistication of what's required to exploit this, is this relatively easy to take advantage of? 

Edward Wu: Yeah, I would say in terms of the sophistication, it's absolutely probably some of the easiest exploit to deploy. The only caveat with the exploit is not all web applications developed by Spring Core framework are vulnerable. So this vulnerability does have some caveats around, for example, requiring Java version 9 or above, as well as requiring a specific way for the application to be developed, as well as deployed, commonly with the Apache Tomcat framework. So there are some caveats in terms of what subset of the applications developed by Spring Core are vulnerable. However, the exploit itself is very straightforward - in fact, require just a single HTTP or web request to generate or implant a web shell on the target server. 

Dave Bittner: And do you have a sense for how much this is being exploited? Are folks out there taking advantage of this? 

Edward Wu: That's a very good question, Dave. From our perspective, we have definitely seen a lot of attempts to exploit this specific vulnerability because it being a remote code execution vulnerability that resides on a lot of web servers or applications servers, which are also frequently publicly accessible. So we have seen a tremendous amount of scanning that's happening on the public internet, where various parties are essentially looking for public-facing web servers that were developed using Spring Core framework and that could be vulnerable to this vulnerability. 

Edward Wu: However, in terms of the actual success of the vulnerability, we have definitely seen a few cases, but I would say in general, it doesn't look - based on what we have seen and what we know today, it doesn't look like a lot of the exploitation attempts has been successful. And I think this has to do with a few reasons, the first being this vulnerability requiring or having some caveats that makes it not globally applicable to every single application developed by Spring Core. In addition to that, Spring Core framework did do a good job by quickly publishing a patch, as well as a workaround for the application developers so that they could secure or patch their existing deployments of Spring Core fairly quickly. 

Dave Bittner: So in addition to the patch, or do you have any other recommendations for how folks should best mitigate against this? 

Edward Wu: So patching and - is definitely, obviously, the most important aspect of it. However, Spring Core itself, being a part of a kind of a core component of the open-source software supply chain - there are also a number of steps that businesses could take to mitigate their risk against this specific vulnerability, as well as, to some extent, the future iterations of other open-source software supply chain vulnerabilities. And the first part is around asset identification, as well as inventory in being able to identify different applications running in the environment, as well as the different types of open-source software that are executing or residing on those servers. So that's one. 

Edward Wu: And I think another interesting step - another important step that business could take is to level up their monitoring of the behaviors of application servers or vendor softwares that rely on open-source software. And the reason being, if we look at this specific attack, or this specific exploit, Spring4Shell allows the attackers to remotely control vulnerable web applications. However, for most attackers, that alone is not a success. Most attackers - and the step of gaining the initial entry to a business or in networks through this vulnerability is the first step of most of the attack campaigns. And as a result of that, by monitoring and looking for suspicious network activities from web application servers, as well as vendor softwares, the business will be able to proactively identify potential compromised web application servers or vendor softwares before the attacker are able to gain further foothold or move laterally within an enterprise. 

Dave Bittner: So in terms of who may be at risk here and who should be concerned about this, who are we talking about? Who needs to have their radar up? 

Edward Wu: Yeah, that's a very interesting question. From my perspective, I believe there are two sets of business that should really pay attention for this specific vulnerability, the first set being businesses who do Java application development themselves and who are utilizing Spring Core to develop business-critical applications. So for those business, they should definitely pay attention to the application servers that they have deployed, their Spring Core applications out, they should definitely patch their internal versions of the Spring Core that they use to develop their applications. So that's kind of the first set. 

Edward Wu: The second set of businesses who should pay attention to Spring4Shell vulnerability is a little bit more subtle. And this has to do with the general challenge with open-source software supply chain, where Spring Core as a application development toolkit can also be used by software vendors to develop commercial softwares. So for a lot of business, obviously, they could have a number of third-party commercial softwares running within their enterprise. And some of those applications or commercial softwares could be developed by Spring Core framework, but that fact might not be very obvious. So for a lot of business who even do not develop Java applications or use Spring Core frameworks themselves, they could still be vulnerable by the virtue of having third-party commercial applications deployed within their network that also happen to be developed by Spring Core. 

Dave Bittner: So they should go out and ask their suppliers or verify with their suppliers whether or not this is something that they're using? 

Edward Wu: Absolutely. This is, to some extent, one of the exact scenarios where the kind of the White House executive order on software bill of material is designed to solve, right? Because if every commercial application also publish the bill of material in terms of what open-source frameworks they are - that they're utilized, users of commercial softwares could essentially scan through the bill of the materials they got and immediately determine which applications are developed using a vulnerable version of Spring Core, instead of, without it, the users will have to ask each and every vendor of the commercial software they are using, hey, whether, you guys - this specific application was developed using Spring Core. Which version of Spring Core did you guys embed? And, obviously, it's a lot more manual and tedious. 

Dave Bittner: Our thanks to Edward Wu from ExtraHop for joining us. The research is titled "A Technical Analysis of How Spring4Shell Works." We'll have a link in the show notes. 

Dave Bittner: The CyberWire podcast is proudly produced in Maryland out of the startup studios of DataTribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Rachel Gelfand, Liz Irvin, Elliott Peltzman, Tre Hester, Brandon Karpf, Eliana White, Puru Prakash, Justin Sabie, Tim Nodar, Joe Carrigan, Carole Theriault, Ben Yelin, Nick Veliky, Gina Johnson, Bennett Moe, Chris Russell, John Petrik, Jennifer Eiben, Rick Howard, Peter Kilpe, and I'm Dave Bittner. Thanks for listening. We'll see you back here next week.