exploiting Spring4shell Vulnerability and POC

Raghav
4 min readAug 30, 2022

Index:

Spring4shell

Spring4shell:

Spring4shell, a new zero-day vulnerability that has been discovered in Spring Framework. Spring Framework is an open-source application framework for Java and is normally deployed with Apache Tomcat servers.

Vulnerability & Impact:

There are two vulnerabilities affecting Spring Framework, one is in Spring Core and second is in Spring Cloud. The Spring Core RCE vulnerability impacts Java class objects. The vulnerability in Spring Core has been given name Spring4shell in the lines of Log4shell as both vulnerabilities affect a library. Although, it took its name from Log4shell, it is not as dangerous as its namesake.

This vulnerability affects all versions of Spring Core Framework running on JDK versions 9 and after. This vulnerability is tracked as CVE-2022–22965. There is another RCE in Spring Cloud Function versions <=3.1.6 and <=3.2.2.

These Are The Prerequisites For The Exploit:

  • Spring Framework before v5.2.20 & v5.3.18
  • JDK 9 or higher
  • Apache Tomcat as the Servlet container
  • Packaged as WAR
  • spring-webmvc or spring-webflux dependency

How To Verify Your Application Is Vulnerable To Spring4Shell Vulnerability (CVE-2022–22965)?

Check the version of JDK and Spring Framework to verify that your application is vulnerable to the Spring4Shell Vulnerability (CVE-2022–22965). Initial Actions to Take:

  1. Check the version number of JDK: Run the “$ java -version” command to check the JDK version running on your machine. If you see your JDK version is less than or equal to 9.0, then your app is safe. No action is required.
  2. Check for Spring framework usage: Follow these steps only if your project is deployed in the form of a war package. Unzip the war package. Search for springbeans-*.jar or CachedIntrospectionResuLts.class file. For example, spring-beans-5.3.16.jar. Repeat this search process if the project runs directly and independently in the form of a jar package too. If you see the version higher than v5.2.20 & v5.3.18, then your app is safe. No action is required.

Proof of Concept:

It’s time to see the exploitation of Spring4shell practically. Let’s create a new directory named spring4shell.

Clone the repository shown in the image below. This repository contains both vulnerable docker image and exploit.

Build the Docker image vulnerable to spring4shell as shown below.

You can check if the target is set or not by visiting the URL in browser.

http://127.0.0.1:8080/helloworld/greeting/ . If you get the above message, the target is ready. Run the exploit. The python exploit uploads a java web shell on the target after exploiting vulnerability.

The exploit completed successfully. The web shell can be accessed at above highlighted address. http://localhost:8080/webshell.jsp?cmd=<command>

The POC is succesful.

How To Fix Spring4Shell Vulnerability- A Critical Remote Code Execution Vulnerability In Spring Framework (CVE-2022–22965)?

  1. Update Spring Framework: Spring maintainers have released the latest versions of Spring Boot 2.6.6 and 2.5.12 that depend on Spring Framework 5.3.18. It is recommended to upgrade Spring Framework vv5.2.20 & v5.3.18 and above to fix the Spring4Shell vulnerability.
  2. Block in Web Application Firewall: Block these file types “class.*”, “Class.*”, “*.class.*”, and “*.Class.*” in security solutions such as Web Application Firewalls. But, be sure this may affect your other projects.

Other Two Temporary Measures to Take:

  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.

--

--