Spring4Shell critical vulnerability

Home / News / Spring4Shell critical vulnerability

10 Apr 2022 Author: Sofia Mashchenko

What happened?

A zero-day vulnerability that allows remote code execution without authentication has been found in the popular Java framework Spring, which is used for the development of web applications. The vulnerability has been labelled CVE-2022-22965. It is also referred to as Spring4Shell and SpringShell (similar to the notorious December 2021 Log4Shell).

Attempts to exploit the vulnerability en masse by attackers to compromise applications and systems have already been observed.

On March 29th, the researchers codeplutos, meizjm3i from AntGroup FG Security Lab reported the vulnerability to VMware, the company that owns the framework. The next day, while a fix was being prepared, all details of the vulnerability were leaked to the public.

On March 31st, Spring officially confirmed the vulnerability and released Spring Framework versions 5.3.18 and 5.2.20 with patches. Releases of Spring Boot 2.6.6 and 2.5.12 were also released, which depend on Spring Framework 5.3.18.

Please note that at the same time, two other, unrelated to CVE-2022-22965, vulnerabilities were reported, creating confusion. The first, CVE-2022-22963, that allows remote code execution, was found in Spring Cloud Function (not part of the Spring Framework), and was fixed in versions 3.1.7 and 3.2.3. The second, CVE-2022-22950, that allows application halt, was found in Spring Framework, and was fixed in version 5.3.17.

What is affected?

At a minimum, the vulnerability affects SpringMVC and Spring WebFlux-based applications running on JDK 9+.

Here are the conditions for exploiting the vulnerability in a separate case, which was described in the initial report:

JDK 9 or higher,
Apache Tomcat as servlet container,
packaging in WAR (as opposed to Spring Boot executable jar file),
dependency on spring-webmvc or spring-webflux,
Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, or an outdated (unsupported) version.

Due to the nature of the vulnerability, we expect new, more versatile exploits.

According to Rapid7’s assessment, any components that use Spring Framework versions prior to 5.2.20 or 5.3.18 along with JDK version 9 or higher are considered potentially vulnerable. Components that in addition to these conditions use @RequestMapping annotation and Plain Old Java Object (POJO) type parameters are considered vulnerable and at risk of exploitation. Components that use Apache Tomcat in addition to all the previous conditions are most at risk due to the presence of an off-the-shelf exploit.

Rapid7 provide an example of vulnerable code in their report. In addition, Microsoft has released a report analysing the vulnerability.

Administrators and developers can check their applications using curl by running the following query:

$ curl host:port/path?class.module.classLoader.URLs%5B0%5D=0

Applications that return a response with HTTP code 400 are considered vulnerable. Other responses do not indicate the presence or absence of the vulnerability.

What should you do?

The best solution is to update your applications to Spring Framework versions 5.3.18 and 5.2.20, which fix this vulnerability.

If this cannot be done now, as a simple temporary solution, developers are advised to use the setDisallowedFields method of the WebDataBinder via @ControllerAdvice to disallow the query field patterns associated with the vulnerability. Examples of this solution are given in the Spring and Praetorian blogs.

As Spring notes, the previous solution can leave gaps. In particular, if the controller itself sets the banned parameters via its own @InitBinder method, which overrides the global setting.

A more advanced solution would be to extend the RequestMappingHandlerAdapter to update the WebDataBinder after all other initialisation. For this, the application can define a bean called WebMvcRegistrations (SpringMVC) or WebFluxRegistrations (Spring WebFlux). An example of this solution is available on the Spring blog mentioned above.

With WAF as a temporary solution, HTTP requests containing strings such as “class.”, “Class.”, “.class.”, and “.class.” can be blocked. However, this method of protection is easy to circumvent, so do not rely on it in the long run.

Finally, organizations are advised to monitor application logs as well as the appearance of new processes on the servers in order to detect anomalies that may indicate a successful hack.