30 March 2022

Understanding Spring4Shell: vulnerability, attacks and mitigations


Image source: https://www.cyberkendra.com/2022/03/springshell-rce-0-day-vulnerability.html

Spring Core on JDK9+ is vulnerable to remote code execution, as described in CVE-2022-22965, also known as Spring4Shell. But what is Spring4Shell? How does it work? What types of attacks are possible and which mitigations exist? We’ll answer these questions in this article.

Note: this is a work in progress; we’re adding new bits and pieces continuously while more information emerges.

Vulnerability overview

On March 30th 2022, a number of possible remote code executions in the Spring Framework family became public:

  • CVE-2022-22965, also known as Spring4Shell: An RCE confirmed by several sources in Spring Core (5.2 <=5.2.19, 5.3 <= 5.3.17 and older versions) that leverages class injection (very severe). So far, this only seems to impact Spring applications deployed as a WAR on Tomcat. Spring boot applications don’t seem to be affected - by the exploit that’s currently published. However, the nature of the vulnerability is more general, and there may be other ways to exploit it so our advice is to also upgrade Spring boot as quickly as possible. A fix is available in Spring Framework versions 5.3.18 and 5.2.20 and Spring Boot 2.5.12 = and 2.6.6 (source).
  • CVE-2022-22963: An RCE confirmed in Spring Cloud Function (<=3.1.6 and <=3.2.2). Less servere, Patch available.
  • An unconfirmed deserialization weakness in Spring Core (<=5.3.17). Initially discussed as allowing RCE via Deserialization, but doesn’t seem exploitable (yet) and is therefore currently not severe.

This article describes the first and most severe vulnerability: Spring4Shell.

Introduction

On March 29th, a number of (now deleted) tweets announced a 0-day vulnerability in Spring core. The vulnerability was confirmed by Praetorian as a remote code execution vulnerability due to a bypass for CVE-2010-1622. The vulnerability was confirmed by the Spring team in a blog post on March 31st. The vulnerability was published on March 31st as CVE-2022-22965.

A fix is available in Spring Framework versions 5.3.18 and 5.2.20 and Spring Boot 2.5.12 and 2.6.6 (source). A public proof-of-concept is available, which means that the vulnerability may be exploited in the wild already. The name “Spring4Shell” calls back to the Log4Shell vulnerability in december, but so far, and impact of that magnitude has not been demonstrated.

A TL;DR from Chris Partridges Github page on the vulnerability about the potential impact:

On March 29th, A GitHub user (p1n93r) claimed that by sending crafted requests to JDK9+ SpringBeans-using applications, under certain circumstances, that they can remotely:
• Modify the logging parameters of that application.
• Use the modified logger to write a valid JSP file that contains a webshell.
• Use the webshell for remote execution

Who is vulnerable and how bad is this?

A description from the Spring blog:

The vulnerability impacts Spring MVC and Spring WebFlux applications running on JDK 9+. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
These are the requirements for the specific scenario from the report:
• JDK 9 or higher
• Apache Tomcat as the Servlet container
• Packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
• spring-webmvc or spring-webflux dependency
• Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

Spring boot does not seem to be affected by the exploits that are currently public. However, the more we learned, the more possible future attack vectors spring up (no pun intented), so we urge Spring boot users to update as quickly as possible as well. It’s very well possible that a working exploit for Spring boot will emerge somewhere in the next few days.

Mitigations are possible (see below) and are advised to apply.

Chris Partridges Github page writes about the potential impact:

In my opinion, any news article going out of its way to say "could this be the next log4shell?!?" is willfully overblowing this - this is a severe vulnerability, sure, but it only impacts nondefault usage of SpringCore with no proven widespread viability. It's categorically not log4shell-like. While this currently does not seem like it's going to be a cataclysmic event, given this is RCE it it at least worth the research to figure out how much risk exposure your organization could have - see "Check Yourself!" to get started.

Randori Security’s Attack Team published a fairly straightforward test to check whether an application is vulnerable:

Attack

JFrog's blog post and Snyk's blog post describe the vulnerability and exploits in details.

Exploit documentation can be found on Chris Partridges Github page on the vulnerability. A sample vulnerable application was created by LunaSec: lunasec-io/spring-rce-vulnerable-app.

Ankit Anubhav shared this image about the attack flow on Twitter:


Source: https://twitter.com/ankit_anubhav/status/1509383534456172546

Roy was able to confirm and reproduce the vulnerability:

Greg Foss confirms the exploit as well:

A PoC by BobTheShoplifter on Github: https://github.com/BobTheShoplifter/Spring4Shell-POC.

Mitigation

The Spring team has released fixes in Spring Framework versions 5.3.18 and 5.2.20 and Spring Boot 2.5.12 and 2.6.6 (source). The recommended mitigation is to upgrade to one of these versions.

Roy van Rijn’s illustrates the fix in this tweet:

The Spring team has also published a workaround in their blog post about the vulnerability, as well as a mitigation alternative.

Praetorian offers remediation advice in their blog post by adding a Spring AOP advice.

Michael Simons reports on Twitter that Apache Tomcat patch releases hardened against Spring4Shell have been released:

Sources and further reading

If you are low on time, read these articles first (in the order below):

If you need more information, continue here:

Bert Jan Schrijver

Bert Jan is CTO at OpenValue and focuses on Java, software architecture, Continuous Delivery and DevOps. Bert Jan is a Java Champion, JavaOne Rock Star speaker, Duke's Choice Award winner and leads NLJUG, the Dutch Java User Group. He loves to share his experience by speaking at conferences, writing for the Dutch Java magazine and helping out Devoxx4Kids with teaching kids how to code. Bert Jan is easily reachable on Twitter at @bjschrijver.

Roy van Rijn

Director at OpenValue Rotterdam, Java Champion, JavaOne Rockstar, founder of the Rotterdam JUG, public speaker, blogger, loves: agile, cryptography, math, algorithms!