pathdoc - stock.adobe.com
Was Spring4Shell a lot of hot air? No, but...
Find out why Spring4Shell was apparently not as impactful a security problem as many had at first feared, and why it’s on the cyber community as a whole to do better
It was briefly hailed as the next Log4Shell – a serious zero-day in a widely used framework underpinning thousands of applications – but a little over a week on from the disclosure of the Spring4Shell remote code execution (RCE) vulnerability in the Spring Framework, there is virtually no evidence of any meaningful 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 built on the Spring Core logging element of Spring, one of the more popular frameworks out there. If exploited, it ultimately allows an unauthenticated actor to execute arbitrary code on the target system. So far so RCE; more details are available here.
Matters were not helped by the concurrent disclosure of a separate vulnerability in Spring, with which Spring4Shell was unfortunately conflated, leading to widespread confusion, and led more than one self-proclaimed security expert who hadn’t properly read something to cry “fake news”.
Tim Mackey, principal security strategist at Synopsys’ Cybersecurity Research Center (CyRC), said this confusion speaks to a problem with how ethical hackers and researchers go about communicating and disclosing their discoveries.
Even though researchers disclose with the best of intentions, disclosure is a fraught process and can be easily misinterpreted if just one person is motivated to sensationalise to pull readers to a blog or write a viral tweet.
“Responsible disclosure exists for a number of reasons, but one of the most important of which is to ensure concise and actionable information is placed in the hands of those who need to promptly and accurately address an issue,” said Mackey.
“The confusion teams experienced with Spring4Shell didn’t need to occur, and likely would have been avoided had information on Spring4Shell not leaked out and had there not been an independent vulnerability in a different component sharing 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 is easily as critical as Log4Shell “for anyone found to be affected by it”.
It is true that the criticality of a vulnerability is somewhat subjective and increases if you happen to fall victim to it, but as Jartelius goes on to explain, it has become quickly apparent that the preconditions to exploit Spring4Shell were not created equal, as such.
“This vulnerability has garnered a huge amount of interest because it was somewhat similar to Log4j, as it shared the characteristics of being a popular library and used in similar settings with the similar impact,” he said. “The only difference was the preconditions, and that difference was massive.”
Read more about Log4Shell
- It’s been described as a ‘design failure of catastrophic proportions’ that threatens the very fabric of the digital world. Find out what the Log4j2 Log4Shell panic is all about, and what you should do about it.
- Prompt and professional community response to the Log4Shell disclosure means the dangerous and widespread vulnerability has not been exploited to the extent many had feared.
JFrog senior director of security research Shachar Menashe explained these conditions in a blog post. At the highest level, an app is vulnerable if built on the Spring Framework, running on JDK9 or later, or using data binding to bind request parameters to a Java object (this is because the vulnerability is in Spring’s data binding mechanism).
Furthermore, said Menashe, thanks to the specific exploitation vector chosen by the proof of concept exploit – arbitrary file overwrite through AccessLogValve – Spring4Shell imposes two further requirements, namely that the web app must be served by Apace Tomcat, and that it must be deployed on Tomcat as a web application resource.
In other words, the particular set of conditions that need to be met for Spring4Shell to be exploited is rather more complicated than those that were required to take advantage of Log4Shell, so even though Spring4Shell is similarly widespread thanks to the popularity of the Spring framework, it is less likely to be exploited for now.
Log4Shell hangover
Eduardo Ocete Entrala, a security researcher at AT&T Alien Labs, said at least part of the reaction to Spring4Shell stems from the reaction to Log4Shell back in December 2021.
“The vulnerabilities in the Java Spring framework have caused a generalised reaction in the software security community because of their similarity to Log4Shell, which was a really critical and impactful vulnerability,” he said. “Furthermore, the widespread usage of the Spring framework also meant that the number of systems that could be impacted by the vulnerability is large.”
Jartelius said: “A critical vulnerability, hard to identify, that can reside for years in your applications and networks waiting for an attacker to use the correct payload is never fuss over nothing, but the panic created was clearly disproportionate.
“It’s likely that we’ll continue to see this kind of journalistic or vendor sensationalism, and the best advice for companies is still to practice good cyber hygiene through regular security assessment to measure and reduce the external attack surface,” he said.
Don’t be complacent
This speaks to a wider need among organisations, and their IT leaders and security teams, to properly get to grips with the various tools and components that are being used in the IT estate, as there may be any number of dependencies or vulnerabilities lurking under the bonnet.
Radware’s director of threat intelligence, Pascal Geenens, said: “SpringShell should be a reminder for everyone to take stock in good hygiene practices. As a community, we have become too comfortable taking on big complex libraries and modules and forgotten to focus on the dependencies between modules.
“Organisations need to pare down their libraries and limit the dependencies on the modules and code that are not relevant to the application; be more careful and discerning about what we are exposing; and make sure we are running the most current versions. Attackers aren’t leaving any stone unturned.”
Interrogate your sources
The Spring4Shell saga also stands as a cautionary tale to be careful not to fall for fear, uncertainty and doubt, and a reminder to everybody in the security community, whether a chief information security officer, researcher, ethical hacker or journalist, to interrogate new information responsibly.
“All of this gets us to a reality within IT,” said Synopsys’ Mackey: “A patch management strategy that is influenced by media coverage isn’t an efficient process!
“Teams that had a software composition analysis, or SCA, solution in place that was configured to proactively alert to new vulnerabilities impacting their operations knew within hours of the CVE being published which systems were impacted and what corrective action was required.
“In the case of Spring4Shell, more appropriately known as CVE-2022-22965, the branding effort distracted from the task at hand and confusion surrounding what the vulnerable component was didn’t help,” he said.
Even so, said Mackey, as with many high-profile vulnerabilities, the scope of impacted code is likely to grow as more knowledge is gained, so if you triaged the vulnerability away rather than remediating, right after finishing this article would be a really good time to check for updates.
In short, be careful out there, but don’t have nightmares.
