Spring4Shell’s explanation: an Internet security disaster that did not exist

Getty Images

The hype and hyperbole were in full swing this week when the security world responded to reports of another Log4Shell. The vulnerability was discovered in December and is perhaps one of the most serious online threats in recent years. Christened Spring4Shell – a new code execution error in the widely used Spring Java platform – quickly set the security world on fire as researchers tried to assess its severity.

One of the first reports of the flaw was the technical news site Cyber ​​Kendra, which warned of serious damage that the flaw could cause “tons of apps” and “could ruin the Internet”. Almost immediately, security companies, many of which promoted snake oil, rushed to warn of the imminent danger we would all face. And all this even before a vulnerability tracking designation or recommendation from Spring technicians was available.

Everyone on board

The hustle and bustle train began on Wednesday after a researcher released an exploit-proof concept that could remotely install an online backdoor remote control, known as a web shell, on a vulnerable system. People were understandably concerned because the vulnerability was so easy to exploit and was within a framework that runs on a huge number of websites and applications.

The vulnerability lies in two Spring products: Spring MVC and Spring WebFlux, which allow developers to write and test applications. Is the result of changes made to JDK9 that resurrected a decade-long vulnerability tracked as CVE-2010-1622. Given the many systems that combine the Spring platform and JDK9 or later, it’s no surprise that people were concerned, especially since the exploit code was already in the wild (the initial leak quickly removed PoC, but by then it was too late ).

On Thursday, the flaw finally received designation CVE-2022-22965. Security advocates have also been given a much more detailed description of the threat it poses. The code leak, according to Spring staff, was only triggered when the developed Spring application ran on top of Apache Tomcat and only when the program was deployed as a file type known as WAR, abbreviated from a web archive.

If the application is deployed as a spring jar boot, ie. by default, it is not vulnerable to exploitation, ”Spring staff wrote. “However, the nature of the vulnerability is more general, and there may be other ways to use it.”

While the post leaves open the possibility of improving the PoC exploit to work against other configurations, no one has found an option that does so, at least for now.

“This is something developers need to fix if they use the affected version,” said Will Dormann, a CERT vulnerability analyst, in a private statement. “But we’re still in the boat, not knowing any apps that could be used.”

On Twitter, Dorman hired Cyber ​​Kendra.

“It’s because Cyber-Kendra has made it worse for everyone,” he said wrote. “1) A sensational blog post showing that it will destroy the Internet (red flag!) 2) A link to fixing the git about deserialization, which has absolutely nothing to do with the problem demonstrated by the original party.”

A Cyber ​​Kendra spokesman did not respond to an email asking for comment. In fairness, a line about the destruction of the Internet was later drawn.

SpringShell, no Spring4Shell

Unfortunately, although there is a consensus that, at least for now, the vulnerability poses nothing close to a Log4Shell threat, the Spring4Shell name has largely taken root. This is likely to mislead some as to its seriousness. Hereinafter Ars will call it the more appropriate name SpringShell.

Several researchers say they have discovered a wildlife scan that uses a CVE-2022-22965 PoC leak or a very similar exploit. It is unusual for researchers to test servers to understand how common a new vulnerability is. A slightly more alarming report on Friday, in which researchers from Netlab 360 said the Mirai variant – malware that can fight thousands of IoT devices and produce denial-of-service attacks – “won the race as the first botnet to accept this vulnerability.” .

To make things more confusing, a separate code execution vulnerability emerged last week that affects the Spring Cloud feature, which allows developers to easily separate application business logic from a specific runtime environment. The flaw, which is tracked as CVE-2022-22963, is in the Spring Expression language, commonly known as SpEL.

Both vulnerabilities are potentially serious and should not be ignored. This means upgrading the Spring Framework to version 5.3.18 or 5.2.20, and with great caution upgrading to Tomcat 10.0.20, 9.0.62 or 8.5.78. Those using the Spring Cloud feature should upgrade to version 3.1.7 or 3.2.3.

For people who are unsure whether their programs are vulnerable to CVE-2022-22965, researchers at security firm Randori have released a simple, harmless scenario that can do just that.

So in any case, test and correct, as if tomorrow will not be, but do not believe the hype.

Leave a Comment