Was Spring4Shell a lot of hot air? No but…

It was briefly hailed as the next Log4Shell — a serious zero-day in a widely used framework underpinning thousands of applications — but just over a week after the Spring4Shell Remote Code Execution (RCE) vulnerability was disclosed in the Spring Framework, it’s practically there no evidence of significant impact on users.

Spring4Shell, also known by some as SpringShell and now tracked as CVE-2022-22965, bypasses a previously known vulnerability tracked as CVE-2010-1622 and affects any application running on Spring’s Spring Core logging element, a the most popular, based framework out there. When exploited, it ultimately allows an unauthenticated actor to run arbitrary code on the target system. So far so RCE; More details can be found here.

The matter was unhelped by the concurrent disclosure of a separate vulnerability in Spring, which has unfortunately been linked to Spring4Shell, causing widespread confusion and leading more than one self-proclaimed security expert who misread something to yell “Fake news” exclaimed. .

Tim Mackey, senior security strategist at Synopsys’ Cybersecurity Research Center (CyRC), said this confusion speaks to a problem with how ethical hackers and researchers communicate and disclose their discoveries.

Even when researchers make disclosures with the best of intentions, disclosure is a delicate process and can easily be misconstrued when just one person is motivated to lure readers to a blog or write a viral tweet.

“There are a number of reasons for responsible disclosure, but one of the most important is to ensure that accurate and actionable information gets into the hands of those who need to address an issue promptly and accurately,” said Mackey.

“The confusion that teams have experienced with Spring4Shell need not have occurred and likely would have been avoided had information about Spring4Shell not been leaked and there had not been an independent vulnerability in another component bearing the Spring name.”

Not easy to exploit

One thing is for sure. Spring4Shell is not fake news. And according to Outpost24 Chief Security Officer Martin Jartelius, it’s just as critical as Log4Shell, “for anyone affected by it.”

While the criticality of a vulnerability is somewhat subjective and increases the more you fall victim to it, as Jartelius goes on to explain, it quickly became apparent that the prerequisites for exploiting Spring4Shell as such were not met.

“This vulnerability attracted a lot of interest because it was somewhat similar to Log4j in that it shared characteristics of a popular library and was used in similar environments with similar impacts,” he said. “The only difference was the requirements, and that difference was huge.”

Shachar Menashe, senior director of security research at JFrog, explained these terms in a blog post. At the highest level, an app is vulnerable if it’s based on the Spring Framework, runs on JDK9 or higher, or uses data binding to bind request parameters to a Java object (this is because the vulnerability is in Spring’s data binding mechanism) .

In addition, Menashe said, thanks to the specific exploitation vector chosen by the proof-of-concept exploit – arbitrary overwriting of files by AccessLogValve – Spring4Shell has two additional requirements, namely that Apace’s web app serves and runs on Tomcat Tomcat must be provided as a resource for web applications.

In other words, the special conditions that must be met in order for Spring4Shell to be exploited are slightly more complicated than those required to exploit Log4Shell although Spring4Shell is similarly widely used thanks to the popularity of the Spring framework less possible be exploited for the time being.

Log4Shell hangover

Eduardo Ocete Entrala, a security researcher at AT&T Alien Labs, said that at least part of the Spring4Shell response was due to the December 2021 Log4Shell response.

“The vulnerabilities in the Java Spring framework have generated a general reaction in the software security community because of their resemblance to Log4Shell, which is a really critical and impactful vulnerability,” he said. “In addition, the widespread use of the Spring framework also meant that the number of systems that could be affected by the vulnerability is large.”

Jartelius said: “A critical vulnerability that is difficult to identify and can exist in your applications and networks for years, waiting for an attacker to use the right payload is never much of a fuss, but the panic generated was clearly disproportionate.

“It’s likely we’ll continue to see this type of journalistic or vendor sensationalism, and the best advice for organizations remains to practice good cyber hygiene through regular security assessments to measure and reduce the external attack surface “, he said.

Don’t be complacent

This speaks to a broader need by organizations and their IT leaders and security teams to properly engage with the various tools and components used in IT inventory, as any number of dependencies or vulnerabilities can lurk beneath the hood.

Pascal Geenens, Director of Threat Intelligence at Radware, said: “SpringShell should remind everyone to take stock of good hygiene practices. As a community, we’ve gotten too comfortable adopting large, complex libraries and modules and have forgotten to focus on the dependencies between modules.

“Organizations need to reduce their libraries and limit dependencies on modules and code that are not relevant to the application; Be more careful and critical about what we disclose. and make sure we’re running the latest versions. Attackers leave no stone unturned.”

Question your sources

The Spring4Shell saga is also a cautionary tale not to fall into fear, uncertainty, and doubt, and a reminder to everyone in the security community, whether chief information security officer, researcher, ethical hacker, or journalist, to interrogate new information responsibly.

“All of this brings us to IT reality,” said Synopsys’ Mackey: “A patch management strategy that is influenced by media coverage is not an efficient process!

“Teams that had a software composition analysis (SCA) solution configured to proactively alert them to new vulnerabilities impacting their operations knew which systems were affected within hours of the CVE’s release were and what corrective actions were required.

“In the case of Spring4Shell, better known as CVE-2022-22965, the branding efforts distracted from the real task and the confusion over what the vulnerable component was didn’t help,” he said.

Still, Mackey says, as with many high-profile vulnerabilities, the scope of affected code is likely to increase as more knowledge is gained. So if you’re triaging the vulnerability instead of fixing it, right after you finish this article, that would be a really good time to check for updates.

In short, be careful out there, but don’t have nightmares.

New Technology Era

Leave a Reply

Your email address will not be published. Required fields are marked *