SpringShell: Spring Core RCE 0-day Vulnerability

This vulnerability is NOT as bad a Log4Shell. All attack scenario are more complex because of the nature of Class Loader Manipulation attacks work in Java. Spring4Shell exploitation requires deep Java knowledge to get a functioning POC. Class Loader Manipulation is more complicated to understand than the Log4Shell vulnerability.

Today, researchers found another worst vulnerability which may cause severe damage to tonnes of applications. that can ruin the internet. At this point, there is no CVE id for this vulnerability, but Now the bug is been tracked as CVE-2022-22965, we may call it Spring4Shell. The vulnerability exists in the Spring core with the JDK version greater or equal to 9.0.

Spring Framework and derived framework spring -beans-*.jar files or CachedIntrospectionResults.class

All the details below are confirmed now shared from an Unconfirmed source. We don't take responsibility for any damage caused.

Vulnerability Details and Investigation

(1). Check the JDK version number 

On the running server of the organization system, run the "java -version" command to check the running JDK version. If the version number is less than or equal to 8, it is not affected by the vulnerability.

(2). Check for Spring framework usage

1. If the organization system project is deployed in the form of a war package, follow the steps below to judge.

• Unzip the war package: Change the suffix of the war file to .zip and unzip the zip file
• Search for a jar file in spring-beans-*.jar format (for example, spring-beans-5.3.16.jar) in the decompression directory. If it exists, it means that the business system is developed using the spring framework.
• If the spring-beans-*.jar file does not exist, search for the existence of the CachedIntrospectionResuLts.class file in the decompression directory. If it exists, it means that the business system is developed using the Spring framework.

2. If the organization system project runs directly and independently in the form of a jar package, judge according to the following steps.

• Unzip the jar package: Change the suffix of the jar file to .zip, and unzip the zip file.
• Search for a jar file in spring-beans-*.jar format (for example, spring-beans-5.3.16.jar) in the decompression directory. If it exists, it means that the business system is developed using the spring framework.
• If the spring-beans-*.jar file does not exist, search for the existence of the CachedIntrospectionResuLts.class file in the decompression directory. If it exists, it means that the business system is developed using the spring framework.

(3) Comprehensive Investigation

After completing the above two steps of troubleshooting, the following two conditions are met at the same time to determine that it is affected by this vulnerability:

1. JDK version number is 9 and above;
2. using the spring framework or derived framework.

Vulnerability Fix Guides

At present, there is no official patch for spring. But it is recommended to use the following two temporary solutions for protection, and pay attention to the release of official patches in a timely manner, and fix vulnerabilities according to the official patches.

Update: Now the Spring team has fixed the vulnerability and released the latest versions of Spring Boot 2.6.6 and 2.5.12 that depend on Spring Framework 5.3.18

We have some updates, this vulnerability is much bigger than NOT as bad a Log4Shell Vulnerability. So we recommend paying attention to the release of official patches and making it apply before crooks.

WAF protection

On network protection devices such as WAF, implement rule filtering for strings such as "class.*", "Class.*", "*.class.*", and "*.Class.*" according to the actual traffic situation of deployed services. After filtering the rules, test the business operation to avoid additional impact.

Temporary repair measures

Temporary repair of the leak should be performed in the following two steps at the same time:

1. Search the @InitBinder annotation globally in the application to see if the dataBinder.setDisallowedFields method is called in the method body. If the introduction of this code snippet is found, add {"class.*","Class.* to the original blacklist ","*.class.*", "*.Class.*"}. (Note: If this code snippet is used a lot, it needs to be appended everywhere)

2. Create the following global class under the project package of the application system, and ensure that this class is loaded by Spring (it is recommended to add it in the package where the Controller is located). After the class is added, the project needs to be recompiled and packaged, and tested for functional verification. and republish the project.

import org.springframework.core.annotation.Order;

        import org.springframework.web.bind.WebDataBinder;

        import org.springframework.web.bind.annotation.ControllerAdvice;

        import org.springframework.web.bind.annotation.InitBinder;

        @ControllerAdvice

        @Order(10000)

        public class GlobalControllerAdvice{ 

             @InitBinder

             public void setAllowedFields(webdataBinder dataBinder){

             String[]abd=new string[]{"class.*","Class.*","*.class.*","*.Class.*"};

             dataBinder.setDisallowedFields(abd);

             }

        }

From the Git Repository of Spring projects, it seems that the Spring developer is working on a fix for the remote code execution vulnerability, but we have to wait for the official confirmation.

We will update the post as we get more information on this story. You can follow us on Facebook, Twitter, and Telegram.