How to detect the Spring4Shell CVE ?

Post

As of March 30, 2022, a vulnerability on the Spring framework has been published. The CVE-2022-22965 “Spring Framework RCE via Data Binding on JDK 9+” classified as ‘Critical’ by the vendor has already been used by attackers.

Gatewatcher’s Purple Team has mobilized to provide you as soon as possible with signatures tested and validated in real conditions to detect the exploitation of this vulnerability.

Our software solution already has 5 detection rules dedicated to this vulnerability. Two new rules are proposed here to complete your detection capacity.

It is nevertheless strongly recommended to apply the updates available from the manufacturer or, failing that, to apply the remediations proposed by the manufacturer during the update period.

Detection

The following signatures are provided by default since April 01, 2022 and allow the detection of this vulnerability :

  • 2035674 ET EXPLOIT Possible SpringCore RCE/Spring4Shell Stage 1 Pattern Set Inbound (Unassigned)
  • 2035675 ET EXPLOIT Possible SpringCore RCE/Spring4Shell Stage 2 Suffix Set Inbound (Unassigned)
  • 2035676 ET EXPLOIT Possible SpringCore RCE/Spring4Shell Stage 3 Directory Set Inbound (Unassigned)
  • 2035677 ET EXPLOIT Possible SpringCore RCE/Spring4Shell Stage 4 Prefix Set Inbound (Unassigned)
  • 2035678 ET EXPLOIT Possible SpringCore RCE/Spring4Shell Inbound (Unassigned)

 

It will also be possible to detect exploitation attempts with the following rules :

  • alert http any any -> any any (msg: “ATTACK [PTsecurity] Spring Core RCE aka Spring4Shell Attempt”; flow: established; content: “pipeline.first.pattern”; nocase; content: “getRuntime”; nocase; distance:0; content: “exec”; nocase; pcre: “/(?:%25|%)(?:%7B|{)/i”; pcre:”/(?:%7D|})i/i”; reference: url, github.com/ptresearch/AttackDetection;reference: url, www.cyberkendra.com/2022/03/springshell-rce-0-dayvulnerability.html; classtype: attempted-admin; sid: 10007107; rev: 1;)

 

  • alert http any any -> any any (msg: “SPRING4SHELL CURRENT_EVENT Spring Core RCE aka Spring4Shell Attempt”; flow: established,to_server; content: “pipeline.first.pattern”; nocase; pcre: “/(?:%25|%)(?:%7B|{)/Ri”; pcre:”/(?:%7D|})i/Ri”; reference: url, www.cyberkendra.com/2022/03/springshellrce-0-day-vulnerability.html; classtype: attempted-admin; sid: 10007108;rev: 1;)

 

The first one, based on the PTSecurity rules, will allow to detect the most obvious cases corresponding to the known information about the vulnerability.
The second one, wider, will perform a detection on the use of variables in the following payload pipeline.first.pattern which will allow to detect requests similar to the second request presented below.

Important : As for any rule implementation, it is necessary to evaluate these rules in pre-production in order to assess their impact.

Vulnerability

Some of the reactions are related to the remembrance of the Log4Shell vulnerability, the other part is related to the confusion caused by the publication of different vulnerabilities during the week on this framework.

  • CVE-2022-22963 : This is also a remote code execution (RCE), but that is related to Spring Cloud.
  • CVE-2022-22950 : It relates to Spring framework, but it is a denial of service condition (Dos).

 

The vulnerability that will interest us here is the CVE-2022-22965 Spring Framework RCE via Data Binding on JDK 9+ classified as ‘Critical’ by the vendor, which has been seen by various actors as already used by attackers.

From the information provided by the vendor, as well as from various observations, the vulnerability seems, for the moment, limited to a number of conditions :

  • The use of JDK9 or higher
  • Deployment in Apache Tomcat as WAR
  • The use of spring-webmvc or spring-webflux
  • The Spring framework in a version 5.3.0 to 5.3.17 or 5.2.0 to 5.2.19 or earlier.

 

A patch has been released by the vendor in the below versions :

  • 5.3.18
  • 5.2.20

 

Note : an update of Spring Boot which depends on Spring has also been released.

To recap this vulnerability, the issue lies in the way Spring converts HTTP parameters into objects, more precisely into Plain Old Java Object (POJO). If the list of parameters is not handled correctly, it is possible to access the classLoader module. Once this module is accessed it is possible to do a number of different things. In the published Proof-of-concept, it is about getting access to the catalina context and modify the logging in order to create a webshell in jsp.

Proof of Concept

The available resources allow to have an example of exploitation of this vulnerability.
The vulnerability would come from the way non-expected fields are handled (as indicated in the Spring documentation).

Thus, the vulnerability can be exploited in the following way :

 

In the used POC case, we will also notice messages in the application logs as :

  • 2022-03-31 16:02:23.169 INFO 1 — [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Initializing Servlet ‘dispatcherServlet’
  • 2022-03-31 16:02:23.174 INFO 1 — [nio-8080-exec-1] o.s.web.servlet.DispatcherServlet : Completed initialization in 3 ms
  • 31-Mar-2022 16:02:27.964 INFO [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/usr/local/tomcat/webapps/ROOT]
  • 31-Mar-2022 16:02:28.000 INFO [Catalina-utility-1] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/ROOT] has finished in [36] ms

 

The payload here above, allows to drop a webshell.
Another POC (https://github.com/lunasec-io/Spring4Shell-POC) shows another method :

We notice here the use of specific headers and the use of these headers in the payload. This opens the door to various variants such as :

 

Auteur : Gatewatcher’s Purple Team

Table of contents

Share this post :
Our most recent post
Share this post :
Our last news