Mitigating Spring4Shell with Group-IB

Spring4Shell (which has been assigned an id of CVE-2022-22965) is the unofficial name of the recently discovered vulnerability, which is exploitable in some installations of the Spring Framework. Originally released as a PoC by a Chinese speaking researcher on March 29, the issue can lead to full compromise of a vulnerable Java application, the exploitation is quite straightforward and easy to use, however, not every application is vulnerable to it. See Spring Developers official acknowledgement here.

What Spring4Shell is not

The Spring4Shell vulnerability should not be confused with any of the following:

1. Not CVE-2022-22963, which is a vulnerability released on March 29, 2022 and affects the Spring Cloud Library.
   
2. Not CVE-2022-22950, which is a Denial of Service Vulnerability in SpEL, released on March 29, 2022.
   
3. Not CVE-2022-27772, which is a Local Privilege escalation via Hijacking of temporary directory, released on March 23, 2022.
   
4. Not related to the github commit which removed a potentially dangerous deserialization, according to Spring
   
5. Spring4Shell is the successor of CVE-2010-1622, a decade old similar vulnerability in the Spring Framework.
   
   

What is Spring Framework?

The Spring Framework (Spring) is an open-source application framework that provides infrastructure support for developing Java applications. Spring is one of the most popular Java Frameworks in use.

According to the published Proof of Concept code and the vulnerability description, the issue exists due to the improper filtering of the Java class properties during the HTTP input binding. For developers using Spring there is the possibility that an incoming HTTP request could be transformed directly to a Java Object.

This is possible due to some changes in Java 9, which could allow some potentially dangerous incoming HTTP parameters to be transmitted to the Spring runtime as the corresponding Object properties, which can lead to changing the parameters of internally running Objects. Java 9 added an extra getModule() method, which could be used by an attacker to traverse the Object chaining path, providing another method to modify protected and potentially dangerous functions and properties.

The Proof of Concept code uses this issue, for example, to change the internal logger behavior, leading to arbitrary write in the publicly available directory. In this case a potential attacker can overwrite server files or write a backdoor (webshell file).

It should be noted that other Java web frameworks can be affected in this way, if their authors did not notice the changes in Java 9, and use the parameter binding in the same way.

The vulnerability has been widely discussed in the cybercrime community since approximately March 29, 4PM CET. Group-IB Threat Intelligence team detected multiple mentions in Telegram channels and darkweb forums, including LAPSUS, KelvinSec chats and major cybercrime communities such as Exploit, XSS. So far, Group-IB Underground Research and Monitoring group hasn't observed any attacks planned utilizing Spring4Shell.

These are the requirements for the specific scenario from the report:

• Apache Tomcat as the Servlet container
  
• Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
  
• spring-webmvc or spring-webflux dependency
  
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions
• Java 9 or above
• HTTP parameters are processed with RequestMapping annotation and POJO (Plain Old Java Object).

Official Fix: Upgrade Spring Framework to either 5.3.18 or 5.2.20 which contains the fixes.

Official Workaround

Until the official fix or workaround from Spring.io can be applied we recommend security teams follow these actions:

• Monitor newly created files in the public serving directories of the webserver that hosts the Spring application, to detect potential webshells.
• Identify all your vulnerable installations and assess the criticality, consider if some of these should be taken offline pending fix.
• Work with your WAF Vendor to get a signature blocking the current exploit.
• Setup your log-parsing systems to look for signs of an attack utilizing the exploit.
  
• Regularly check this blog for updates.