It was briefly hailed as the next Log4Shell, a serious zero-day in a widely used framework that underpins thousands of applications, but just over a week after the disclosure of the Spring4Shell remote code execution (RCE) vulnerability in the Spring Framework, there is there is virtually no evidence of any significant impact on users.
Spring4Shell, also known to 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 Spring’s Spring Core registry element, one of the More popular. frames out there. If exploited, it ultimately allows an unauthenticated actor to execute arbitrary code on the target system. So far RCE; More details are available here.
Things did not improve with the simultaneous release of a separate vulnerability in Springwith which Spring4Shell was sadly combined, leading to widespread confusionand led more than one self-proclaimed security expert who hadn’t read something right to yell “fake news.”
Tim Mackey, chief security strategist at Synopsys Cybersecurity Research Center (CyRC), said this confusion speaks to a problem with the way hackers and ethical researchers communicate and publicize their discoveries.
Although researchers disclose with the best of intentions, disclosure is a tense process and can be easily misunderstood if only one person is motivated to sensationalize in order to attract readers to a blog or write a viral tweet.
“Responsible disclosure exists for a number of reasons, but one of the most important is to ensure that concise and actionable information is in the hands of those who need to quickly and accurately address an issue,” Mackey said.
“The confusion the teams experienced with Spring4Shell did not have to occur, and probably would have been avoided if information about Spring4Shell had not been leaked and there had not been a separate vulnerability in a different component that shares the Spring name.”
not easy to blow up
One thing is for sure. Spring4Shell is not fake news. and according to outpost24 security director Martin Jartelius, is easily as critical as Log4Shell “for anyone affected by it.”
It is true that the criticality of a vulnerability is somewhat subjective and increases if you fall victim to it, but as Jartelius goes on to explain, it has quickly become clear that the preconditions for exploiting Spring4Shell were not created equal, as such.
“This vulnerability has generated a lot of interest because it was somewhat similar to Log4j, sharing the characteristics of being a popular library and used in similar environments with similar impact,” he said. “The only difference was the preconditions, and that difference was huge.”
JFrog Senior Director of Security Research Shachar Menashe explained these conditions in a blog post. At the highest level, an application is vulnerable if it is built on the Spring Framework, runs on JDK9 or later, or uses data binding to bind request parameters to a Java object (this is because the vulnerability is in Spring’s data binding mechanism).
Furthermore, Menashe said, thanks to the specific exploitation vector chosen by the proof-of-concept exploit (arbitrary file overwriting via AccessLogValve), Spring4Shell imposes two additional requirements, namely that the web application must be served by Apace Tomcat and which must be deployed to Tomcat as a web application resource.
In other words, the particular set of conditions that must be met for Spring4Shell to be exploited is quite a bit more complicated than those required to exploit Log4Shell, so even though Spring4Shell is equally widespread thanks to the popularity of the Spring framework, it is least likely to be exploited for now.
Eduardo Ocete Entrala, security researcher at AT&T Alien Labssaid that at least part of the reaction to Spring4Shell stems from the reaction to Log4Shell in December 2021.
“The vulnerabilities in the Java Spring framework have caused a widespread backlash in the software security community due to its similarity to Log4Shell, which was a really critical and shocking 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, hard-to-identify vulnerability that can reside for years in your applications and networks waiting for an attacker to use the correct payload never cares about anything, but the panic created was clearly blown out of proportion.
“We are likely to continue to see this type of vendor or journalistic sensationalism, and the best advice for businesses remains 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 broader need among organizations, and their IT leaders and security teams, to become properly familiar with the various tools and components that are used in state of IT, as there can be a host of dependencies or vulnerabilities. on the prowl hood.
malware Threat Intelligence Director Pascal Geenens said: “SpringShell should be a reminder for everyone to take stock of good hygiene practices. As a community, we have become too comfortable with large and complex libraries and modules and have forgotten to focus on dependencies between modules.
“Organizations need to reduce their libraries and limit dependencies to modules and code that are not relevant to the application; be more careful and insightful with what we are exposing; and make sure we’re running the latest versions. The attackers leave no stone unturned.”
Question your sources
The Spring4Shell Saga is also presented as a warning to be careful not to fall into fear, uncertainty, and doubt, and a reminder to everyone in the security community, whether you are an information security officer, a researcher, a ethical hacker or a journalist, to question new information. responsibly
“All of this brings us to a reality within IT,” 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, or SCA, solution that was set up to proactively alert on new vulnerabilities affecting their operations knew within hours of the CVE being published which systems were affected and what action to take. corrective was required.
“In the case of Spring4Shell, more appropriately known as CVE-2022-22965, the branding effort distracted from the task at hand, and the confusion around which component was vulnerable did not help,” he said.
Still, Mackey said, as with many high-profile vulnerabilities, the scope of affected code is likely to grow as more knowledge is gained, so if you assessed the vulnerability rather than remediate it, immediately after completing this article would be a very good time to check for updates.
In short, be careful, but don’t have nightmares.