Demystifying Spring4Shell

CVE-2022–22965

Background

In late March 2022, a severe vulnerability, affected the core of the framework Spring Core. This critical vulnerability gained the moniker Spring4Shell drawing parallels to the infamous Log4Shell vulnerability from the previous year. The vulnerability stemmed from a bypass of a previous patch for CVE-2010–1622, an older vulnerability in Spring that allowed attackers to achieve remote command execution by exploiting how Spring handled data from HTTP requests. The Spring4Shell vulnerability essentially allowed attackers to upload a “webshell” onto vulnerable servers, granting ability to execute arbitrary commands remotely.

Introduction

Spring4Shell is vulnerability that leverages the weaknesses in Spring MVC, a component of the Spring Framework used for developing web applications following the MVC design pattern. Spring MVC automatically instantiates and populates objects based on incoming request parameters, which attackers can abuse to overwrite critical attributes and achieve remote code execution. Attackers typically exploit Spring4Shell by coercing applications to write malicious .jsp files to the webserver. These .jsp files contain code that the server executes upon request, effectively giving attackers control over the server remotely. However, Exploiting the Spring4Shell vulnerability requires meeting specific conditions:

JDK 9 or higher.
Versions before 5.2, 5.2.0–19, and 5.3.0–17
Web App deployed on Tomcat as a Web Application Archive (WAR)
Dependencies on spring-webmvc and/or spring-webflux

Exploitation

For exploiting the vulnerability, we must identify the vulnerable Spring based application that falls under the above-mentioned categories. Once the vulnerability is detected we can enter publicly available exploit that sends a crafted HTTP request which will use the ClassLoader to overwrite critical properties in the logging functionality, which will lead the logger to create a web shell instead of a log file.

Exploit

For the demo I will be using the exploit developed by reznok.

Through this Exploit, we can access and modify nested class properties due to how Spring Core performs the request parameter binding using serialization. The specific nested object used when exploiting the Spring4Shell vulnerability is class.module.classLoader. Through the classLoader object, we can execute malicious code on the vulnerable server, resulting in RCE.

class.module.classLoader.resources.context.parent.pipeline.first.patternSpecifies the content of the log file. Attackers inject their web shell code here.

class.module.classLoader.resources.context.parent.pipeline.first.prefix names the log file. Attackers name their web shell file here.

class.module.classLoader.resources.context.parent.pipeline.first.suffix sets the extension of the log file to .jsp, allowing the web shell to execute as a JSP file on the server.

class.module.classLoader.resources.context.parent.pipeline.first.directory , determines the location of the log file. If accessible, attackers use a directory like webapps/ROOT for easy access to the web shell.

class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormatOptionally used to improve attacker experience by removing timestamps from the output.

Now, once we execute the python executable a web shell is uploaded as a .jsp file where we can execute command through the query parameter.

In this manner, we can easily exploit Spring4Shell.

Remediation

To mitigate the Spring4Shell vulnerability, we must update our application to patched versions of the Spring Framework. For instance, versions after 5.3.18 or 5.2.20 contain the necessary fixes.

This short blog discussed about Spring4Shell vulnerability and its exploitation.