Explaining Spring4Shell: The Internet Security Disaster That Wasn’t

Explaining Spring4Shell: The Internet Security Disaster That Wasn't

fake images

The hype and hyperbole were on full display this week as the security world reacted to reports of another Log4Shell. The vulnerability came to light in December and is arguably one of the most serious internet threats in years. Dubbed Spring4Shell, the new code execution bug is found in the widely used Spring Java framework, the threat quickly set the security world on fire as researchers scrambled to assess its severity.

One of the first publications to report the flaw was on tech news site Cyber ​​Kendra, which warned of the severe damage the flaw could cause to “tons of apps” and claimed the bug “could ruin the internet.” Almost immediately, security firms, many of them pushing snake oil, swooped in to warn of the imminent danger we would all face. And all that before a vulnerability tracking designation or advisory from Spring maintainers was available.

All aboard

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 concerned that the vulnerability was very easy to exploit and was in a framework that powers a large number of websites and applications.

The vulnerability resides in two Spring products: Spring MVC and Spring WebFlux, which allow developers to write and test applications. The flaw is the result of changes introduced in JDK9 that resurrected a decade-old vulnerability tracked as CVE-2010-1622. Given the abundance of systems combining the Spring Framework and JDK9 or later, it’s no wonder people were concerned, especially since the exploit code was already available (the PoC was quickly removed by the initial leaker, but by then it was too late) .

On Thursday, the flaw was finally given the designation CVE-2022-22965. Security advocates also got a much more nuanced description of the threat it posed. The leaked code The spring maintainers saidran only when a Spring-developed application was running on top of Apache Tomcat and only when the application was deployed as a file type known as WARweb archive abbreviation.

“If the application is deployed as a Spring Boot executable file, ie the default, it is not vulnerable to the exploit,” Spring maintainers 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 improved to work with other configurations, no one has discovered a variation that does, at least not yet.

“It’s something developers should fix, if they’re using an affected version,” Will Dormann, vulnerability analyst for CERT, said in a private message. “But we are still in the boat of not knowing of a single application that is exploitable.”

On Twitter, Dormann criticized Cyber ​​Kendra.

“The ways Cyber ​​Kendra made this worse for everyone,” he said. wrote. “1) Awesome 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.”

A representative for Cyber ​​Kendra did not respond to an email seeking comment. To be fair, the line about ruining the internet was crossed out later.

spring shell, not Spring4Shell

Unfortunately, despite the consensus that, at least for now, the vulnerability poses nothing close to the Log4Shell threat, the Spring4Shell name has largely stuck. That 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 using the leaked PoC CVE-2022-22965 or a very similar exploit. It’s not unusual for researchers to benignly test servers to understand how frequent a new vulnerability is. A little more worrying is a report on friday in which Netlab 360 researchers said a variant of Mirai, a malware that can manipulate thousands of IoT devices and produce crippling denial-of-service attacks, “has won the race as the first botnet to adopt this vulnerability.”

To make things more confusing, a separate code execution vulnerability affecting the Spring Cloud Function surfaced last week, which allows developers to easily separate business logic in an application from a specific runtime. The flaw, tracked as CVE-2022-22963, resides in Spring Expression Language, generally known as SpEL.

Both of these vulnerabilities are potentially serious and should in no way be ignored. That means updating the Spring Framework to 5.3.18 or 5.2.20, and, as a precaution, also updating to Tomcat 10.0.20, 9.0.62, or 8.5.78. Those using the Spring Cloud feature should upgrade to either 3.1.7 or 3.2.3.

For people who are unsure if their applications are vulnerable to CVE-2022-22965, researchers at security firm Randori have published a simple, non-malicious script which you can check.

So by all means, test and patch like there’s no tomorrow, but don’t believe the hype.

Leave a Reply

Your email address will not be published.