Spring4Shell is a vulnerability of critical severity affecting Java’s most popular framework, Spring. Many cyber security firms have disclosed that they have observed the attempts to target the exploitation of CVE-2022-22965, trying to upload the webshells in order to execute the commands on the compromised systems. The attacks targeting the first Spring4Shell exploitation was first identified on March 30, 2022. According to a source, it was informed that one of Chinese security researchers leaked the details of the zero-day exploit by tweeting about it before the Spring developers could release the security patch for it. Later, the tweet was removed as well as his account was deleted from Twitter. The vulnerability affects the applications of Spring WebFlux and Spring MVC that are running on JDK 9+. Spring4Shell was first responsibly reported to VMWare by codeplutos, meizjm3i of the AntGroup FG Security Lab. It was then confirmed by researchers from Praetorian that it is a new remote code execution vulnerability. Spring4Shell is a remote code execution vulnerability that was introduced in the Spring Framework, making use of data binding functionality to bind the data stored within an HTTP request to certain parameters or objects being used by an application.
CVE ID : CVE-2022-22965 (Spring Core)
Severity Level -
CVSS v3 Score - 9.8
CVSS Vector -
WHERE IS THE VULNERABILITY PRESENT?
This bug is present in the code level wherever the “getCachedIntrospectionResults” method is being used, eventually it can be misused to gain unauthorized access to such objects by passing their class names via an HTTP request. This vulnerability leads to remote code execution in Spring Core applications.
WHICH APPLICATIONS ARE VULNERABLE TO THIS?
Any running instance/application vulnerable to Spring4Shell, might have the following configurations mentioned below: -
- Running on JDK 9 or higher
- Apache Tomcat running as the Servlet container or WAR file
- Packaged as a WAR file format and deployed in a standalone Tomcat instance. Typical deployments on Spring Boot technology using an embedded Servlet container is not impacted.
- Having dependency on spring-webflux or spring-webmvc with parameter binding (enabled by default).
- Spring Framework versions of 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions.
- Lack of whitelisting of registered HTTP fields or explicitly blacklist the fields that could cause malicious intent.
VULNERABLE APP AND EXPLOITATION
- 2 stager RCE- It involves two requests to perform the RCE in Springshell (CVE-2022-22965) which are as shown below: -
The following exploitation steps demonstrate how we can set the contents to be a JSP web shell and it is inserted inside the path of the Tomcat’s web application ROOT directory, which eventually allows us to upload a reverse shell inside Tomcat.
Exhibit: HTTP request to upload the shell (“tomcatwar.jsp”)
Exhibit: HTTP request to use the shell code for running the commands remotely
- Single request exploitation- This form of exploitation consists of only one HTTP request. It can be reproduced as follows: -
Exhibit: Nuclei command execution to intercept the request using BurpSuite
Exhibit: Intercept the request, replace the payload in the URL by the Burp Collaborator URL and forward the request
Exhibit: A callback is received at the Burp Collaborator and if you check the request headers and find User-Agent as Java, this indicates that the application is vulnerable to Spring4Shell
In order to define the impact of Spring4Shell vulnerability, we need to understand what the Spring Core Framework actually does. Spring Core basically performs the simplification of requests executing the parameter extraction on a server (Apache Tomcat server). It affects all the Java applications that are using Spring Core with non-default configuration. This type of bug has a high impact on Confidentiality, Integrity and Availability. The ways to exploit this vulnerability is easily available publicly as well as considering the fact that it does not require any authentication. This makes the CVSSv3 score as high as 9.8 which is known to be critical.
Listed are some of the Companies along with their products affected by Spring4Shell: -
DETECTION OF THIS VULNERABILITY
It can be detected whether the application is vulnerable to this CVE by checking the below: -
- Determine if the Spring Core Framework is used in your network.
- Ensure that deployments of the Spring Core Framework are running a version equal to or greater than 5.3.18 or 5.2.20.
Some of the techniques to remediate this bug are as follows:
- Upgrade to the latest patched Spring Framework versions - 5.3.18 and 5.2.20
- In case, you cannot upgrade to the latest version of Spring Framework, you can follow the workarounds mentioned as below-
- Upgrade the version of Apache Tomcat to 10.0.20, 9.0.62 or 8.5.78 in order to get appropriate protection.
- Downgrading to Java 8 is also a considerable workaround.
- Adapt the configuration of a Web Application Firewall (WAF), if such is in place, to filter out requests containing “class.*“, “Class.*“, “*.class.*“, “*.Class.*“
- Disable the binding to specific parameters. You can do this by configuring “disallowedFields” on WebDataBinder globally. This can be performed by making use of the below code, which may work in most cases: -