Explaining Spring4Shell: The Internet Security Disaster That Wasn’t
Hype and hyperbole were in the spotlight this week as the security world reacted to reports from yet another Log4Shell. The vulnerability was disclosed in December and is arguably one of the most serious Internet threats in years. Dubbed Spring4Shell – the new code execution bug in the widely used Spring Java framework – quickly set the security world on fire as researchers scrambled to gauge its severity.
One of the first posts to report the flaw was tech news site Cyber Kendra, which warned of the severe damage the flaw could do to “tons of apps” and “can ruin the internet”. . Almost immediately, security companies, many of which were selling snake oil, began falling over themselves to warn of the impending danger we would all face. And all this before a vulnerability tracking designation or an opinion from Spring officials is even available.
The hype train began on Wednesday after a researcher published a proof-of-concept exploit that could remotely install a web-based remote control backdoor known as a web shell on a vulnerable system. People were understandably worried because the vulnerability was so easy to exploit and was in a framework that powers a large number of websites and apps.
The vulnerability resides in two Spring products: Spring MVC and Spring WebFlux, which allow developers to write and test applications. The flaw results from changes introduced in JDK9 that resurrected a decade-old vulnerability identified as CVE-2010-1622. Given the abundance of systems that combine the Spring framework and JDK9 or later, it’s no wonder people are concerned, especially since the exploit code was already in the wild (the leaker initial quickly removed the PoC, but by then it was too late).
On Thursday, the flaw was finally given the designation CVE-2022-22965. Security advocates also received a much more nuanced description of the threat it posed. According to Spring officials, the leaked code only executed when an application developed by Spring ran on Apache Tomcat, and then only when the application was deployed as a file type called WAR, short for web archive. .
“If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit,” Spring officials wrote. “However, the nature of the vulnerability is more general and there may be other ways to exploit it.”
While the post left open the possibility that the PoC exploit could be enhanced to work with other setups, no one has discovered a variant that does, at least for now.
“This is something developers should fix, if they’re using an affected version,” CERT vulnerability analyst Will Dormann said in a private message. “But we are still in the boat of not knowing a single exploitable application.”
On Twitter, Dormann took Cyber Kendra to task.
“The ways Cyber Kendra made it worse for everyone,” he said. wrote. “1) Sensational blog post stating this is going to ruin the internet (red flag!) 2) Link to a git commit on deserialization that has absolutely nothing to do with the problem demonstrated by the original party.”
Ways Cyber Kendra made it worse for everyone:
1) Sensational blog post stating this is going to ruin the internet (red flag!).
2) Link to a git commit on deserialization that has absolutely nothing to do with the problem demonstrated by the original party. pic.twitter.com/91MAfL7K4r
— Will Dormann (@wdormann) March 31, 2022
A representative for Cyber Kendra did not respond to an email seeking comment. In all fairness, the line on internet ruin was then crossed out.
SpringShell, do not Spring4Shell
Unfortunately, while there is consensus that, at least for now, the vulnerability poses nothing close to the threat of Log4Shell, the name Spring4Shell has largely stuck. This will probably mislead some about its seriousness. In the future, Ars will refer to it by its more appropriate name, SpringShell.
Several researchers say they have detected scans in the wild that use the leaked PoC CVE-2022-22965 or a very similar exploit. It’s not uncommon for researchers to mildly test servers to understand the prevalence of a new vulnerability. Slightly more disturbing is a report published on Friday in which researchers from Netlab 360 said that a variant of Mirai – malware capable of jamming thousands of IoT devices and producing crippling denial-of-service attacks – “has won the race as the first botnet to adopt this vulnerability.”
To make matters more confusing, a separate code execution vulnerability emerged last week that affects Spring Cloud Function, which allows developers to easily decouple an application’s business logic from a specific runtime. The flaw, identified as CVE-2022-22963, resides in the Spring Expression Language, commonly known as SpEL.
Both of these vulnerabilities are potentially serious and should not be ignored in any way. This means updating Spring Framework to 5.3.18 or 5.2.20 and, to be on the safe side, also upgrading to Tomcat 10.0.20, 9.0.62 or 8.5.78. Those using the Spring Cloud feature should update to 3.1.7 or 3.2.3.
For people unsure if their apps are vulnerable to CVE-2022-22965, researchers at security firm Randori have published a simple, non-malicious script who can do just that.
So, by all means, test and fix like there’s no tomorrow, but don’t believe the hype.