Spring4Shell (CVE-2022-22965) is a remote code execution (RCE) vulnerability that affects Spring Core, a comprehensive framework for Java-based enterprise applications.
Spring4Shell gets its name from the Log4Shell vulnerability, one of the most critical zero-day threats ever, which affected a Java software component called Log4j and allowed hackers to take control of web servers and networks.
Spring4Shell is a critical vulnerability for web applications and cloud services. Any RCE is a serious threat, and GitHub is already full of POCs (proofs of concept) that disclose the exploit publicly, so cybercriminals can’t miss it.
Vulnerabilities such as Spring4Shell and Log4Shell will be under attack quickly, and hackers will probably find other ways to exploit it, perhaps bypassing the workarounds and mitigations, so vigilance is required.
A recent study found that 78% of businesses are open to compromise every time a new RCE technique is found, so security pros should pay special attention to zero-day RCE vulnerabilities.
See the Top Vulnerability Management Tools
Spring Core’s Popularity
The Spring Core Framework is one of the most popular Java frameworks, especially in enterprises. Companies use it to speed up development as an alternative to Java EE applications.
The tool is fully object-oriented and provides advanced features to build Java-based applications. For example, Spring allows parameter binding/extraction from requests, which allows programmers to easily manipulate them.
In other words, it can extract valuable information from HTTP requests and map it as key-value pairs or Java objects used by the application. It’s more convenient for developers.
Hackers can exploit Spring4Shell to overwrite information and upload web shells that ultimately lead to remote code execution. To achieve that, they will likely pass a malicious payload through an HTTP request to manipulate the targeted Java objects and gain full control of the target system.
Spring4Shell Exploits Explained
The exploit seems to require several components:
- JDK (Java Development Kit) 9++
- spring-webmvc or spring-webflux
- Spring framework versions 5.2.0 to 5.2.19, 5.3.0 to 5.3.17, or older
- Apache Tomcat to serve the application
- Built as a WAR (Web Application Resource) file (and not JAR)
However, Microsoft said that “Any system using JDK 9.0 or later and using the Spring Framework or derivative frameworks should be considered vulnerable.”
Most POCs exploited a REST API that accepts HTTP requests (GET, POST, etc.) and payloads. The main idea is to divert specific functions that rely on request mapping annotation and Plain Old Java Object (POJO) parameters within the Spring Framework (see screenshot below):
Attackers can send crafted HTTP requests to create a malicious .jsp file in the service’s root directory (source: Microsoft):
In other words, it’s possible under specific conditions (e.g., Spring’s request mapping feature) to modify internal variables from the client side.
Because the framework has a request mapping feature, hackers can predict which methods will be invoked according to a specific URI. In addition, parameter/property binding is convenient for developers, as it automatically populates some fields according to URI parameters, but it’s also highly predictable and prone to unwanted chaining.
Using the getClassLoader() accessor, hackers can manipulate the properties of the AccessLogValve object in Tomcat’s pipeline. That’s how the access log of a vulnerable Tomcat web server can turn into a reverse shell.
Such unauthorized shell access can lead to the worst outcomes, from stolen credentials to root escalation, depending on the server’s configuration and security policies followed for deployment.
While the exploit may look quite technical, public POCs and dark open-sourcing will ease the difficulty significantly. I’ve seen lots of Python scripts that can automate the attack.
Hackers Already Exploiting the Vulnerability
CISA added the vulnerability to its catalog and Checkpoint highlighted several key figures:
- Around 37,000 attempts to leverage the Spring4Shell vulnerability
- During the first four days, 16% of organizations worldwide were impacted by exploitation attempts
- Software vendors are the most affected industry, where 28% of the organization were impacted
- The most impacted region is Europe, with about 20% affected
Microsoft reported a “low volume of exploit attempts across cloud services for Spring Cloud and Spring Core vulnerabilities,” and strongly encouraged users to check their current configuration.
How to Detect and Protect against Spring4Shell
As the vulnerability allows RCE, monitoring suspicious activities, especially outgoing connections, can help detect the exploit.
More specifically, Microsoft indicated a quick test to determine whether you are vulnerable to Spring4shell or not:
curl host:port/path?class.module.classLoader.URLs%5B0%5D=0
Any HTTP 400 response is a positive match!
Companies that rely on Spring Framework versions 5.2 and 5.3 should upgrade to versions 5.2.20 and 5.3.18 quickly.
Alternatively, it is possible to patch Apache Tomcat with the following versions: 8.5.78, 9.0.62, 10.0.20.
The Spring project published a series of mitigations and recommendations. Organizations that cannot update for now may downgrade to Java 8 or disable binding to particular fields, for example.
VMware also published detailed advisories. The severity is marked as critical for all its products affected by Spring4Shell. At this time, there aren’t remediations for all products. Investigation is still continuing but users can apply workarounds to mitigate the threat.
Read next: SANS Outlines Critical Infrastructure Security Steps as Russia, U.S. Trade Cyberthreats
