Millions of installations potentially vulnerable to Spring Framework flaws

Millions of installations potentially vulnerable to Spring Framework flaws

Security firms produced two data points on Monday to estimate the number of Spring Framework installations that are vulnerable to the latest flaw, CVE-2022-22965, also known as Spring4Shell or SpringShell, suggesting that between hundreds of thousands millions of instances are affected. .

Details of the vulnerability were leaked last week, less than 24 hours after the issue was disclosed to the Spring project, leaving security professionals and developers scrambling. Scans for the specific combination of factors that suggest a vulnerable instance found 150,000 vulnerable devices after scanning a quarter of the Internet suggest that as many as 600,000 devices may have the vulnerable component that could be exploited by the leaked code, says Jared Smith, senior director of threat intelligence at security metrics firm SecurityScorecard.

Additionally, SecurityScorecard honeypot servers have detected active attempts to exploit the issues, it says.

“Given early reports suggest [SpringShell affected] around 6,000 devices, this new number is much worse,” says Smith. “Log4j was much more difficult to assess if an exposed port was being used by a Java-based application with Log4j in the background. This is much more visible and directly available to exploit and test.”

Other security companies have published data supporting a similar magnitude of impact for SpringShell. On April 4, Sonatype released data showing that 81% of applications built with the Spring Beans component as a dependency are using a potentially vulnerable version as of Monday. While the data only revealed the relative balance between up-to-date and potentially vulnerable components, Sonatype stated that the issues “affect millions of users,” in its SpringShell Exploitation Resource Center Page. The live dashboard tracks the number of potentially vulnerable downloads of the component.

The number of updated Spring Beans (green) compared to vulnerable versions (red).
The number of updated Spring Beans (green) compared to vulnerable versions (red). Source: Sonatype

Not the same as Log4j
SpringShell is a critical issue, but it’s not an “Internet on fire” issue like the Log4j vulnerability, and the patch rate shows, Ilkka Turunen, field CTO at software management and security firm Sonatype, wrote in a post. blog in April. Four.

“Even at this early stage, we can already see a slower rate of update adoption compared to Log4j,” he wrote. “This is most likely because the vulnerability only affects some Spring users on specific configurations. This graph will help us understand the fixed adoption rate in the coming days and weeks.”

The lack of immediacy to patch the SpringShell vulnerability is because the current exploit code requires a Spring application specifically configured to be able to use the flaw. The application must be installed on an Apache Tomcat server running JDK 9 or later and packaged as a web archive (WAR). Also, the application must use the Spring Beans package through the Spring WebMVC component and Spring WebFlux.

Those requirements significantly reduce the potential vulnerable instances, Sonatype’s Turunen wrote on the company’s blog.

“The reality…is that due to extenuating circumstances, only a small percentage of deployments are truly vulnerable to the issue,” he wrote. “That said, with any big project, there’s a lot of legacy that can result in older, unmaintained systems becoming potential entry points.”

The sentiment was also shared by software supply chain security firm JFrog, which confirmed that its platform is not affected by the issue. In its own analysis, the company broke down the issue and identified the root cause of the problem: “{S]starting with Java 9, due to the introduction of a new API…it is possible to bypass Spring’s protection and assign arbitrary values to the properties of the ClassLoader attribute”.

The company also emphasized that because the vulnerable setting is not a default setting, even Spring applications with the vulnerable component may not be.

“While the SpringShell vulnerability is serious in its impact on Java applications, there are very specific circumstances that must exist for an organization to be at risk,” said Shachar Menashe, senior director of security research at JFrog, in a statement. sent to Dark Reading.

What to do with SpringShell Vuln
SecurityScorecard recommends that companies scan their internal networks and perform external scans for vulnerable settings. In addition, companies should keep track of their software BOM to know when their application frameworks might be exposed to vulnerabilities, such as SpringShell and Log4j.

SecurityScorecard also emphasized that developers and application security professionals should not be complacent because the vulnerability will likely not be exposed in the current vulnerability. Other exploits will surely follow, the company declared in an analysis.

“If this sounds all too familiar and reminds you of the Equifax hack that was due to an exploit of the Apache Struts2 framework, then your instincts are right,” the company said. “This is the same type of vulnerability.”

Leave a Comment