A new critical zero-day Remote Code Execution vulnerability within the Spring Framework has been publicly disclosed on the 31st of March 2022 (CVE-2022-22965).
The vulnerability, commonly known as ‘Spring4Shell’, allows an unauthorised attacker to remotely execute arbitrary code on the target host.
Sources show that 34,000 Spring4Shell attacks were detected over the past weekend alone.
Spring-core is a prevalent framework widely used in Java applications. It allows Java developers to develop applications with enterprise-level components with ease. The Spring Framework is part of JDK 9.0, and the vulnerability can be exploited by simply sending a carted HTTP request to a target machine.
Updating the Spring Framework puts an end to this zero-day. However, as with Log4J, it isn’t necessarily the easiest task to carry out as there isn’t a central way to push the update to all instances in the wild.
The vulnerability requires JDK (Java Development Kit) version 9.0 or later to be running on the machine. Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 are all vulnerable. The vulnerability allows remote attackers to plant a web shell (a small piece of malicious code) when running spring framework apps on top of JRE (Java Runtime Environment) version 9. It is caused by unsafe deserialisation of given arguments that a HTTP POST request can trigger to allow full remote access.
Default configurations are generally not affected, as it requires that the application is packaged as a WAR as opposed to the default executable JAR (typical deployments use embedded servlet container or reactive web server).
Spring Framework 5.3.18 and 5.2.20 contain fixes and have been released. If you can upgrade to Spring Framework 5.3.18 or 5.2.20 then no workarounds are necessary.
However, if this is not the case, then upgrading to Apache Tomcat 10.0.20, 9.0.62 or 8.5.78 provides protection but doesn’t solve the vulnerability entirely. It is also possible to downgrade to Java 8, if you are unable to upgrade the Spring Framework or Apache Tomcat.
Another viable workaround is to disable binding to particular fields by setting disallowedFields on WebDataBinder globally.
There are several proof of concepts of the Spring4Shell vulnerability already available, most of them from this repository.
The exploit relies on a specially crafted HTTP request as stated above. This request abuses how Spring’s RequestMapping interface interprets and parses web request query parameters. This interface maps web requests that are incoming and passes them on to the appropriate methods for handling.
The Spring4Shell vulnerability lies within the RequestMapping interface’s mechanism for user-supplied data. Attacks exploiting Spring4Shell supply a payload using Module.getClassLoader(). This then allows an attacker to load an arbitrary malicious class that the server must then parse. The vulnerable version of Spring did not filter this attack path, therefore leading to this exploit.
Roughly one in six organisations worldwide are impacted by the Spring4Shell vulnerability and are being targeted by threat actors currently.
We can assist clients by using our vulnerability scanning tools to identify whether this vulnerability is present within your environment and provide vulnerability management services to help mitigate or patch the vulnerability across your infrastructure.
The Spring4Shell vulnerability is a high-impact vulnerability that is easy for attackers to exploit on environments that use vulnerable versions of Spring. Throughout this blog we have covered what the Spring Framework is, what versions are vulnerable, the patching of Spring4Shell and how we can assist you in managing this vulnerability.
To read more on this vulnerability please visit the links below:
Please feel free to get in touch with one of our security experts to find out more.