CyberWire Daily - Dissecting the Spring4Shell vulnerability. [Research Saturday]

Episode Date: June 18, 2022

Edward Wu, senior principal data scientist at ExtraHop, joins Dave to discuss the company's research, "A Technical Analysis of How Spring4Shell Works." ExtraHop first noticed chatter from social media in March of 2022 on a new remote code execution (RCE) vulnerability and immediately started tracking the issue. In the research, it describes how the exploit works and breaks down how the ExtraHop team came to identify the Spring4Shell vulnerability. The research describes the severity of the vulnerability, saying, "The impact of an RCE in this framework could have a serious impact similar to Log4Shell." The research can be found here: How the Spring4Shell Zero-Day Vulnerability Works Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. of you, I was concerned about my data being sold by data brokers. So I decided to try Delete.me. I have to say, Delete.me is a game changer. Within days of signing up, they started removing my personal information from hundreds of data brokers. I finally have peace of mind knowing my data privacy is protected. Delete.me's team does all the work for you with detailed reports so you know exactly what's been done. Take control of your data and keep your private life Thank you. JoinDeleteMe.com slash N2K and use promo code N2K at checkout. The only way to get 20% off is to go to JoinDeleteMe.com slash N2K and enter code N2K at checkout. That's JoinDeleteMe.com slash N2K, code N2K. 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. March 30th, 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. That's Edward Wu, Senior Principal Data Scientist at ExtraHop. The research we're discussing today is titled A Technical Analysis of How Spring for Shell works. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue Thank you. Easily than ever with AI tools. It's time to rethink your security. Zscaler Zero Trust Plus AI stops attackers by hiding your attack surface,

making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context, simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com security. Unfortunately, at that specific time, SpringCore themselves did not acknowledge the existence of this vulnerability. So there was a little bit of confusion initially on whether there was indeed any vulnerability

or not. And this one 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 Spring for Shell was discovered by a subsidiary of Alibaba 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 Supreme Court or the party who discovered it.

I mean, you have that kind of, I don't know, international intrigue, the diplomatic side of how quickly a vulnerability like this becomes public. Yeah, exactly. 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 a 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? But we have never heard about it. That's fascinating. Well, for folks who might be unfamiliar with it, can you explain to us what exactly SpringCore framework is? So SpringCore 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. Well, let's dig into the actual vulnerability here. Can you walk us through how is it pulled off and what exactly is it capable of? So from the high-level spring for Shell, vulnerability, which is later named as CVE-2022-22965, is a remote code execution vulnerability against the Spring Core framework. 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 in terms of impact and severity.

So how would someone go about exploiting this? What exactly do they have to do? Yeah, that's a good question. So in order to exploit this specific vulnerability, the attacker essentially has to craft a malicious web request that contains 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 is by remotely crafting a web request that remotely modifies the Java 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 has been implanted on the server, attacker will be able to access the web shell remotely and then essentially get full command line access to the target server. Wow. And that's the ballgame.

Yep. Yeah. So when you rate sort of the sophistication of what's required to exploit this, is this relatively easy to take advantage of? 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, it requires just a single HTTP or web request to generate or implant a web shell on the target server. And do you have a sense for how much this is being exploited? Are folks out there taking advantage of this? 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's 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. However, in terms of the actual success of the vulnerability, we have definitely seen

a few cases, but I would say in general, 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 SpringCore fairly quickly. So in addition to the patch, do you have any other recommendations for how folks should

best mitigate against this? So patching is definitely obviously the most important aspect of it. However, SpringCore 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. And I think 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, Spring for Shell 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 a network 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. 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? 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 businesses, they should definitely pay attention to the application servers that they have deployed their Spring Core applications on. 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. The second set of businesses who

should pay attention to Spring for Shell, 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 a Spring-Core framework, but that fact might not be very obvious. So for a lot of businesses who even do not develop Java applications or use Spring-Core

framework 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 SpringCorp. So they should go out and ask their suppliers or verify with their suppliers whether or not this is something that they're using. Absolutely. you're using. Absolutely. This is, to some extent, one of the exact scenarios where the White House executive order on software bill of material is designed

to solve. Because if every commercial application also publishes the bill of material in terms of what open source frameworks they are utilized, users of commercial softwares could essentially scan through the bill of 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 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. Our thanks to Edward Wu from ExtraHop for joining us. The research is titled A Technical Analysis

of How Spring for Shell Works. We'll have a link in the show notes. And now a message from Black Cloak. Did you know the easiest way for cyber criminals to bypass your company's defenses is by targeting your executives and their families at home. Black Cloak's award-winning digital executive protection platform secures their personal devices, home networks, and connected lives. Because when executives are compromised at home, your company is at risk. In fact, over one-third of new members discover they've already been breached. Protect your executives and their families 24-7, 365 with Black Cloak.

Learn more at blackcloak.io. The Cyber Wire podcast is proudly produced in Maryland out of the startup studios of Data Tribe, where they're co-building the next generation of cybersecurity teams and technologies. Our amazing CyberWire team is Thanks for listening. We'll see you back here next week.