by Ebin Sabu -- Security Software Engineer
Here, we analyze a recent critical vulnerability and how Virsec customers are already protected – even before the affected code can be patched. Customers can assess the risk and not have to resort to patching in an emergency.
On March 31, 2022, a critical vulnerability in the Spring Framework affecting the Spring MVC and Spring WebFlux applications running on JDK 9+ was released. It was titled ‘Spring4Shell’ or ‘SpringShell,’ also tracked as CVE-2022-22965. The NVD assigned a CVSS score of 9.8 (out of 10) since this vulnerability lets the attacker execute arbitrary code remotely.
In the first week that the vulnerability was disclosed, a Chinese researcher released a working proof of concept (POC) exploit even before Spring could release patches for the vulnerability. Before the POC was pulled, a lot of security researchers got access.
One research team has confirmed that they had detected a “low volume of exploit attempts” targeting the critical Spring4Shell vulnerability across its cloud services. Other research indicates that there were close to 37k attempts to exploit the vulnerability in the very first weekend the exploit was released. As shown below, this research also indicated that 16% of organizations worldwide were impacted by exploitation attempts within the first four days of the vulnerability being published.
Most of these exploitation attempts were made in Europe, as shown below:
Spring4Shell may have inherited its name from its predecessor, the Log4Shell, largely because the Spring Core Framework is a very popular framework. That is where the similarity ends. For the Spring4Shell vulnerability to be successfully exploited many operating conditions (described in the section “How Spring4Shell can be exploited” below) needed to be met. This makes a comparison with the Log4J vulnerability totally misplaced.
Attack breakdown
The Spring4Shell vulnerability affects functions that use request mapping annotation and Plain Old Java Object (POJO) parameters within the Spring Framework.
The attacker can update the AccessLogValve class to create a web shell in the Tomcat root directory. In the example below, each GET parameter is set as a Java object property. Each GET request then executes some Java code that finally drops a web shell into the root directory of the server:
The malicious .jsp file now contains a web shell payload that the attacker can then use HTTP requests to execute commands on the victim server.
How Spring4Shell can be exploited
Spring4Shell can be exploited if the following prerequisites are met for any applications deployed:
- JDK version must be 9 or higher
- Uses Apache Tomcat as the servlet container
- Application needs to be packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
- Application must be using the spring-webmvc or spring-webflux framework
- Application must have Spring framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, or older versions
Steps involved in exploiting Spring4Shell
- The attacker sends malicious HTTP packets to override Tomcat-specific ClassLoader attributes, to change the access log file path to somewhere under the web root directory and change the log pattern (the data written) to a constant pattern that contains the webshell code. This causes the webshell JSP to be dropped under the web root directory.
- Now the attacker can send query requests to the dropped webshell, to execute arbitrary commands on the victim workload.
Fix for Spring4Shell
On April 4, 2022, Spring released the patches to upgrade to a newer version of the Spring framework/boot. But for users who cannot upgrade the framework, a workaround was provided which comprises:
- Upgrading Tomcat
- Downgrading to Java 8
- Setting disallowed fields
How Virsec protects against the Spring4Shell attack
With Virsec’s Deterministic Protection Platform (DPP), customers are already protected. Virsec DPP-Host FSM and DPP-Web LFI capability can protect against attempts to exploit the Spring4Shell vulnerability. Virsec DPP-Web CMDI can also stop any commands from being executed on the OS via the malicious web shell. Finally, Virsec DPP-Host HMM’s zero runtime protection capability will block any commands or malicious code from being executed on the protected machine.
While it is always good to patch, Virsec DPP protects vulnerable applications without the need to go through a patching fire drill. Malicious malware is stopped at the first indication and customers remain protected until they can assess the risk to their organization and work out patching.
