What you need to know: 0-day vulnerability in Spring core framework (Spring4Shell)

Over the past 24 hours, from the time Cyber Kendra published the initial blog post, there was significant debate over its severity, implications, and remediation requirements. Trying to make sense of it all is hard even for even the most tech savvy, so here is a list of everything you need to know! We will keep this blog continuously updated based on new developments.

One thing we can state with confidence is that it won the unofficial award for “most confusing 0-day publication of the year so far in 2022”. We have summarized and simplified the key information below so it is consumable by both security professionals and other key stakeholders.

What’s the security bug all about?

Confusion ensued on several items of the publication and experts’ analysis. To add to the confusion, another Spring-related vulnerability has been published, which is unrelated to it in nature and applicability.

The essence of the bug enables an attacker to exploit via the construct of a class-loading mechanism that can effectively open the designated web server to malicious payloads that will be able to run code on the server.

The default parameter handling of the spring-framework based server is not vulnerable to the attack. The attack is focused on less hardened implementations of parameter handling, such as the Plain Old Java Object parameters (POJO).

Vulnerable applications in the wild

While the security community started dissecting and debating, several experts announced in-the-wild findings. One specific case that put to rest the debate at large was official Spring tutorial code that seemed to be vulnerable, which derivatives or inspired-by code can potentially be affected and prone to this attack.

OK, where are we with Spring stuff?
1) CVE-2022-22963 is a thing, and it affects Spring Cloud Connector. It’s RCE, so the CVSS score of 5.4 seems way off.
2) Spring4Shell / SpringShell, invented by Cyber Kendra, isn’t a Spring vulnerability at all.
Does that sound about right? pic.twitter.com/OwPgA2BSIS

— Will Dormann (@wdormann) March 30, 2022

Am I vulnerable?

While announcing a security bug, especially with such a potentially high impact, organizations are prone to alert fatigue. For organizations that are using Spring as their main development framework, the process of going through the asset inventory, weeding out the vulnerable applications, and updating each can be a non-trivial task.

Here are a couple rules to help you navigate through this decision:

• JDK9 or higher is necessary for a successful exploitation. Any prior versions of JDK are not exploitable.
• If you use Spring Framework 5.3.18 or 5.2.20 (or above) – you are not vulnerable to exploitation.

Note: Some publications have designated either Spring Beans, Spring WebMVC or Spring-WebFlux dependencies as a minimal requirement but the attack surface can be extended beyond this short list and we are not using it as a closed and finite list.

How to use context to prioritize remediation

1. The straightforward way to manage the vulnerability is to upgrade to patched versions of the Spring Framework. Because this option is not always available, or cannot happen immediately, there are other remediation options that you can take, depending on your contextual risk and threat model.
2. Check-springshell is a testing suite for Spring4Shell, which you’ll be able to use in order to determine if your implementation is vulnerable to the attack. The only limitation is that it tests against the known attack scenarios, which are still being investigated by the community, and is not a general-purpose testing and payload building testing suit. It does let you parametrize and invoke some variations and test limitations of the payload execution.
3. Add a shared controller in Spring to deflect the use class-loading calls as a field. You can use this snippet to capture and deny dangerous known patterns.

import org.springframework.core.Ordered;

import org.springframework.core.annotation.Order;

import org.springframework.web.bind.WebDataBinder;

import org.springframework.web.bind.annotation.ControllerAdvice;

import org.springframework.web.bind.annotation.InitBinder;

@ControllerAdvice

@Order(10000)

public class BinderControllerAdvice {

@InitBinder

public void setAllowedFields(WebDataBinder dataBinder) {

      String[] denylist = new String[]{"class.*", "Class.*", "*.class.*", "*.Class.*"};

      dataBinder.setDisallowedFields(denylist);

}

}

Disclaimer

The dust hasn’t settled quite yet. The debate over its risk and exploit commonality is still ongoing. The exploitation methods and variations are still under investigation and there is also a discussion about a potential third vulnerability that has not yet been published.