Spring4Shell – What Happened, Who’s Vulnerable, and How to Mitigate

The newly discovered vulnerability in the popular Java Spring framework, dubbed Spring4Shell, is all over the cyber news feeds today. Here, the Salt Labs team looks to clear up some confusion, explain what Spring4Shell really is, share who might be impacted, and offer tips for mitigating your risk. (Note, a robust debate has already emerged over whether “Spring4Shell” or “SpringShell” is correct – for now, we’re following the more common convention.)

What Happened?

On March 29, 2022, a Chinese researcher posted several screenshots on his Twitter account showing a Remote Code Execution vulnerability on the Spring Core Java library. It has been designated CVE-2022-22965.

Spring is one of the most popular and most widely used Java frameworks –  ~70% of all Java applications use it – so any security issue found in its core functionalities means bad news for a lot of people. Hence the high level of attention paid by the entire cyber industry.

Since the tweets were quickly deleted by Twitter, and since the disclosed information was very partial, analysis and confirmation of this vulnerability took some extra time.

What is the Impact?

Exploitation of Spring4Shell will allow an attacker to remotely execute arbitrary code on the target server, usually with equivalent permissions to the vulnerable web server itself. A successful attack might allow a user to access all website internal data, including possible access to any connected database. It may also allow an attacker to access additional internal resources to gain more permissions or to pivot to other parts of the internal network.

Who is Vulnerable?

Several conditions must be met to exploit a Java application running on Spring framework. The most basic ones are:

• Java applications running Spring version through to 5.3.17 or 5.2.19 (inclusive), depending on the variant you’re running
• Java applications running on JDK 9 or higher

If your Java applications run the above versions, we encourage you to read the following section to better understand whether you may be vulnerable to this attack.

Vulnerability Description

The Spring4Shell vulnerability is abusing a functionality of Spring’s RequestMapping annotation.

In essence, RequestMapping is what allows mapping incoming HTTP requests into their appropriate handler functions. The vulnerable condition occurs when RequestMapping is used in conjunction with traditional Java objects (also referred to as POJO – “Plain Old Java Object”) as the handler parameter.

Consider this code for example:

This code defines a new endpoint in the web application at ‘website.com/hello,’ which is supposed to receive one parameter as input. This parameter is expected to be a User object, and its value will be mapped to an internal User object.

The Spring4Shell vulnerability occurs since an attacker may also decide to send other Objects known to the application instead of the expected User object, and the Spring framework will respect these calls and attempt to map them to their appropriate classes.

Simply put, the Spring4Shell vulnerability allows the injection of Java objects into legitimate request handlers, opening the door for server exploitation.

Payload

As we know, simply triggering the vulnerability will not give attackers control over the server. Worst case, they could trigger a denial of service attack. Exploitation depends on the types of objects that can be injected per specific running Java application.

At the moment, one exploit code does exist and is circulating in the wild. This exploit code uses a payload that can be used for remote code execution over Tomcat servers. It is quite reasonable to believe that additional payloads, relevant for different environments, will be found and released in the future. As of this writing, however, we are not aware of any other such public exploits.

The current in-the-wild payload is abusing the fact that the class object is available to use as an input object, which in turn exposes the ClassLoader object. Using these classes as input fields to the request allows changing Tomcat’s logging configuration and enables the attacker to change the Tomcat log files names and location into an exposed web path.

From this point, all an attacker has to do is to generate some payload (basically to any endpoint, not necessarily to the vulnerable one) where the content of the request will include a valid JSP code. This action will create a log file that contains code such as the following, in a jsp file reachable by the attacker:

All that is left for an attacker is to browse to “/spring4shell/vuln.jsp'' to execute the malicious code. In this case, the command “vi test.txt” will be run – however, in more practical use cases, an attacker would probably choose to upload a web-shell that will grant complete control over the attacked server.

If you`re looking for more detailed information about the payload, we recommend reading this blog post which explains this technique more in depth (enable English translation as needed).

How can I protect my Java applications?

Spring has announced an emergency patch for this vulnerability, in Spring versions 5.3.18 and 5.2.20, depending on the variant you’re using. We encourage every Spring-based project to make sure the Spring framework is updated to these latest versions.

For peace of mind, the broader Salt Security team has confirmed that no elements of the Salt platform are vulnerable. We have also confirmed that our ML and AI algorithms would have detected this payload manipulation, preventing our customers from exploits. That’s the power of the rich context we continually generate about what’s “normal” in our customers’ API traffic. We’d be happy to share more details in a personal demo.

‍