Spring4Shell: No need to panic, but mitigations are advised
Security teams around the world got another shock on Thursday when news of disclosure of a PoC for an unauthenticated RCE zero-day vulnerability in Spring Core, a massively popular framework for building modern Java-based enterprise applications, began circulating online.
Thanks to many security researchers, the situation is a bit clearer today and there’s no need to panic just yet: Unlike Log4Shell, this new flaw – with no official CVE and currently nicknamed Spring4Shell – seems to only be exploitable in certain configurations.
What we know about Spring4Shell so far
First and foremost: Spring4Shell is not the recently patched RCE vulnerability in the Spring Cloud Function library (CVE-2022-22963).
A Java Springcore RCE 0day exploit has been leaked. It was leaked by a Chinese security researcher who, since sharing and/or leaking it, has deleted their Twitter account.
We have not verified the exploit.
tl;dr big if true
Download the 0day POC here: https://t.co/SgPCdI00TS
— vx-underground (@vxunderground) March 30, 2022
According to researchers with Praetorian, Spring4Shell is a bypass of an incomplete patch for CVE-2010-1622, an old code injection vulnerability in the Spring Core Framework, and affects Spring Core on Java Development Kit (JDK) version 9 or later.
The existence of the vulnerability was made public when a Chinese-speaking researcher released PoC exploit code for it on GitHub and told the world about it on Twitter (the post and the tweets have been deleted soon after).
Several PoCs for Spring4Shell have since appeared online, and the effectiveness of some of them have been confirmed.
Can confirm! The #Spring4Shell exploit in the wild appears to work against the stock "Handling Form Submission" sample code from https://t.co/dt05rTPbGQ
If the sample code is vulnerable, then I suspect there are indeed real-world apps out there that are vulnerable to RCE… https://t.co/PFXoIusFcT pic.twitter.com/2gydOJk10Y
— Will Dormann (@wdormann) March 31, 2022
“In certain configurations, exploitation of this issue is straightforward, as it only requires an attacker to send a crafted HTTP request to a vulnerable system. However, exploitation of different configurations will require the attacker to do additional research to find payloads that will be effective,” the Praetorian researchers noted.
“Exploitation requires an endpoint with DataBinder enabled (e.g. a POST request that decodes data from the request body automatically) and depends heavily on the servlet container for the application. For example, when Spring is deployed to Apache Tomcat, the WebAppClassLoader is accessible, which allows an attacker to call getters and setters to ultimately write a malicious JSP file to disk. However, if Spring is deployed using the Embedded Tomcat Servlet Container the classloader is a LaunchedURLClassLoader which has limited access.”
Praetorian disclosed full details of their exploit to the Spring security team, and are holding off on publishing more information until a patch is in place.
What should security teams do?
In the meantime – and until a patch is provided and vulnerable apps are discovered – LunaSec, Rapid7, Praetorian, Contrast Security, and SANS ISC have shared analyses of the PoC exploit, resources for testing it (e.g., a vulnerable test app), and risk mitigation guidance.
Randori Security’s Attack Team has also released a non-malicious request that can be used to test susceptibility to the vulnerability.
“When zero day exploits like Spring4Shell come to light, organizations immediately are thrust into panic mode, scrambling to determine the potential blast radius of the vulnerability. Given the broad use of Apache Tomcat by developers, this remote code execution vulnerability has huge potential impact. Security teams need to immediately understand what software and devices might be affected and identify whether there are any vulnerable devices in their environment. This can be remarkably challenging because many organizations struggle to maintain an up-to-date inventory of devices, let alone possess the ability to detect software types and versions running on those devices,” says Jeff Costlow, CISO at ExtraHop.
“We know at this point that the remote code execution vulnerability is present in the Java Spring framework, but it may also be present in other Java applications. It affects Tomcat, a very common connector that joins together a webserver and the Java application. We suspect there may be other vulnerable applications, but are focusing on the attacks that are in the wild. We have reports of scanning already for this vulnerability so it is only a matter of time before a fully weaponized PoC is leveraged.”
UPDATE (April 1, 2022, 01:00 a.m. PT):
For more up-to-date news on this evolving situation, check out this Help Net Security video – Spring4Shell: New info and fixes (CVE-2022-22965).
UPDATE (April 6, 2022, 05:10 a.m. PT):
The US Cybersecurity and Infrastructure Agency (CISA) has added Spring4Shell to their Known Exploited Vulnerabilities Catalog, but successfull exploitations have still not been documented.