Explaining Spring4Shell: The Internet security disaster that wasn’t

Getty pictures

Hype and exaggeration were shown in full this week when the security world reacted to reports of another Log4Shell. The vulnerability came to light in December and is without a doubt one of the most serious internet threats in several years. Named Spring4Shell – the new code execution error in the widely used Spring Java framework – quickly set fire to the security world as researchers tried to assess its severity.

One of first posts to report the bug was the technical news site Cyber ​​Kendra, which warned of serious damage that the bug could cause to “tons of applications” and “could destroy the internet.” Almost immediately, security companies, many of them squeezing snake oil, fell on themselves to warn of the imminent danger we would all face. And all this before a vulnerability tracking designation or advice from Spring entertainers was even available.

Everyone aboard

The hype train started on Wednesday after a researcher published a proof-of-concept utility 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 existed in a framework that runs a huge number of websites and apps.

The vulnerability exists in two Spring products: Spring MVC and Spring WebFlux, which allow developers to write and test apps. The bug is a result of changes introduced in JDK9 that revived a decade-old vulnerability tracked as CVE-2010-1622. Given the abundance of systems that combine the Spring framework and JDK9 or later, it was no wonder that people were worried, especially since the exploitation code already existed in nature (the first leak quickly took down PoC, but then it was too late.)

On Thursday, the error finally got the designation CVE-2022-22965. Security defenders also received a much more nuanced description of the threat it posed. The leaked code, said spring holderran only when a Spring-developed app was running on top of Apache Tomcat and then only when the app was distributed as a file type known as a WARabbreviation for web archives.

“If the application is distributed as a Spring Boot executable jar, ie standard, it is not vulnerable to exploitation,” wrote the Spring maintainers. “But the nature of the vulnerability is more general, and there may be other ways to exploit it.”

While the post left the possibility that PoC utilization could be improved to work against other configurations, no one has found a variant that does, at least for now.

“This is something that developers should fix, if they use an affected version,” said Will Dormann, a vulnerability analyst at CERT, in a private statement. “But we’re still in the boat of not knowing a single application out there that can be exploited.”

On Twitter, Dormann Cyber ​​Kendra took to the task.

“The way Cyber ​​Kendra made this worse for everyone,” he said wrote. “1) Sensational blog post indicating that this will destroy the internet (red flag!) 2) Links to a git-commit on deserialization that has absolutely nothing to do with the issue demonstrated by the original party.”

A Cyber ​​Kendra representative did not respond to a request for comment. In the name of justice, the line to destroy the internet was later broken.

SpringShell, not Spring4Shell

Unfortunately, even though there is agreement that, at least for now, the vulnerability does not pose anything close to the Log4Shell threat, the Spring4Shell name has largely stuck. It is likely to mislead some about its severity. In the future, Ars will refer to it with its more appropriate name, SpringShell.

Several researchers say they have discovered scans in nature that use the leaked CVE-2022-22965 PoC or an exploitation similar to it. It is not uncommon for researchers to benignly test servers to understand how widespread a new vulnerability is. Something more worrying is one report on Friday where researchers from Netlab 360 said that a variant of Mirai – malicious software that can hack thousands of IoT devices and produce devastating 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, allowing developers to easily disconnect business logic in an app from a specific run. The bug, tracked as CVE-2022-22963, is found in Spring Expression Language, commonly known as GAME.

Both vulnerabilities are potentially serious and should in no way be ignored. This means that you update the Spring Framework to 5.3.18 or 5.2.20, and with great caution also upgrade to Tomcat 10.0.20, 9.0.62 or 8.5.78. Those who use the Spring Cloud feature should update to either 3.1.7 or 3.2.3.

For people who are not sure if their apps are vulnerable to CVE-2022-22965, researchers at the security company Randori have released a simple, non-malicious script who can do just that.

So by all means, test and patch as if there is no tomorrow, but do not believe the hype.

Leave a Comment