​

 Spring4Shell

At the time of writing, this vulnerability has no CVE assigned and is known around the Internet as Spring4Shell, due to its similarities to the infamous Log4Shell vulnerability.

This vulnerability relies on the fact that when processing the contents of a query in requests Spring Core allows access to the class object, the default parent for all the classes in Java, which means that it is possible to rewrite any property of any class. In the PoC published by the apparent discoverer, a Chinese researcher, the schema and location of the log files can be modified by changing properties of the classLoader object, used by Tomcat for logging. Then, a request is sent containing a payload that will execute a shell, which will be logged in the location previously defined. Finally, the log file is accessed, and the injected code executed.

The following is a breakdown of the Proof of Concept done by the Chinese researcher. The PoC is done in Spring deployed to Apache Tomcat.

After setting up the server, several requests including properties of the classLoader object as parameter are sent:

http://127.0.0.1:8080/stupidRumor_war_exploded/index?class.module.classLoader.resources.context.parent.pipeline.first.patter=%25%7b%66%75%69
http://127.0.0.1:8080/stupidRumor_war_exploded/index?class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
http://127.0.0.1:8080/stupidRumor_war_exploded/index?class.module.classLoader.resources.context.parent.pipeline.first.directory=%48%3a%5c%6d%
http://127.0.0.1:8080/stupidRumor_war_exploded/index?class.module.classLoader.resources.context.parent.pipeline.first.prefix=fuckJsp
http://127.0.0.1:8080/stupidRumor_war_exploded/index?class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

These requests change the location where new log files will be created, their name, and their extension to .jsp, a filetype used to dynamically generate pages using Java.

Then, a request is made to the application. This request contains the code that will be executed:

In this request, a new header is added which content is a call to a Java function that will execute the command sent in the “cmd” parameter of a query done to the file.

Finally, a request to the newly created log file with the query parameter cmd and the value calc is sent. In the image is shown how this request is made and how the calculator is executed:

Similar manipulations of the ClassLoader object, such as CVE-2014-0114 and CVE-2010-1622, have been observed in the past. All these issues exploit an inherent behavior from Java, and it should be stressed that a secure development process that ensures that the properties of the objects used by the applications cannot be accessed by users and modify the intended functionalities should be a priority for developers.

The exploitation of this vulnerability is heavily dependent not only on the configuration of Spring Core and the JDK version, but also requires a type of server that servlet allows the writing and reading of files on disk. Therefore, with the information we have at the time of writing, we conclude that the exploitation of this issue in vulnerable systems is not trivial and requires for the attacker to investigate the victim to write a proper payload, making it way less impact than the Log4Shell one.

Mitigations

As of 31/03/22 @ 12:00am, there are no official patches to mitigate this Spring Core vulnerability.

A proven way to protect your system, provided by Praetorian, is to create a ControllerAdvice component and block a series of vulnerable field patterns necessary for successful exploitation. See the code snipped below:

import org.springframework.core.Ordered;
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 BinderControllerAdvice {
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{“class.*”, “Class.*”, “*.class.*”, “*.Class.*”};
dataBinder.setDisallowedFields(denylist);
}
}

Scene

It has been difficult for cybersecurity researchers and system administrators to understand what happened and determine if they should be worried or not about the rumors of a new vulnerability that could outshine the Log4Shell crisis. Many articles mistakenly referred to the Spring4Shell vulnerability as previous CVEs and even unrelated commits by the Spring Framework developers.

To simplify the situation, here is a timeline of the recent events involving Spring’s security:

Timeline

• On March 28th, the CVE-2022-22950 was assigned to a vulnerability affecting Spring Framework, versions 5.3.0 to 5.3.16. This vulnerability could cause a DoS condition and is considered of medium severity. It does not affect Spring Core and can be mitigated by upgrading Spring Framework to 5.3.17+.
• On March 29th, the CVE-2022-22963 affecting Spring Cloud, versions 3.1.6, 3.2.2 and older, was officially published with a medium severity level and a CVSS of 5.4. It does not affect Spring Core either, and can be mitigated by upgrading Spring Cloud to 3.1.7, 3.2.3.
• On March 29th, Spring Framework developer made a new commit on its GitHub project. The changes were made to prevent a “Class Loader Manipulation” attack exploiting the deserialization mechanisms used by Java when using @RequestMapping to parse a request.
• On March 29th, a Chinese investigator posted a Tweet with a screenshot of an apparently simple exploit for Spring Core that would lead to RCE, and a PoC in their GitHub repository. Soon after, both their Twitter account and GitHub became inaccessible. Researchers could retrieve the posted PoC and confirmed the vulnerability, dubbed Spring4Shell.

The chaos that ensued due to the lack of any structured vulnerability disclosure procedure, mixed with the confusion caused by similar vulnerabilities and products, gave potential attackers more time to prepare and try to make profit from it.

Update 31/03/22 at 15:00 GMT+1: The vulnerability has been assigned CVE-2022-22965.
Update 31/03/22 at 15:38 GMT+1: Spring has published a new patch to mitigate the issue for versions 5.3.x & 5.2.x. Older versions suffering the vulnerability are no longer supported and no patch has been issued.

​