Spring4Shell: No need to panic, but mitigations are advised
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2010-1622 | NVD description · AI analysis pending | — | 52% | — | — | — | |
| CVE-2022-22963 | SpEL Expression Injection RCE in VMware Tanzu Spring Cloud Function VMware Tanzu's Spring Cloud Function contains a remote code execution flaw (CWE-94, expression-language code injection) in its routing functionality. When the routing feature evaluates an attacker-supplied Spring Expression Language (SpEL) routing-expression, a specially crafted expression is processed by the framework, resulting in arbitrary code execution on the server and access to local resources. Any deployment of Spring Cloud Function that evaluates untrusted routing-expressions, typically via exposed application endpoints, is affected. An attacker who can reach such an endpoint gains code execution in the context of the running application, which can lead to data theft, lateral movement, or ransomware. Exploitation is confirmed in the wild: CISA added the flaw to its Known Exploited Vulnerabilities catalog on 2022-08-25 and EPSS rates the 30-day exploitation probability at 99.9% (100th percentile), although no public PoC is cataloged in this data. Do: Apply the vendor update per VMware/Tanzu instructions immediately, as patching is the required action for this KEV-listed vulnerability. Until patched, prevent untrusted clients from supplying the routing-expression (restrict or disable the routing functionality) and limit network exposure of affected services. Review application logs for unexpected SpEL payloads in routing-expressions and check affected hosts for indicators of compromise, including ransomware staging. | 9.8 | 100% | KEV PoC |
| largeplausibly tens of thousands of deployments (10,000-100,000 systems); exact installed base unpublished | |
| CVE-2022-22965 | Unauthenticated RCE in VMware Spring Framework (Spring4Shell) - JDK 9+ Tomcat WARs CVE-2022-22965 ('Spring4Shell') is a critical (CVSS 9.8) remote code execution flaw in VMware's Spring Framework, caused by insecure data binding that lets unauthenticated attackers overwrite internal class and module properties through crafted request parameters (CWE-94, code injection). It affects Spring MVC and Spring WebFlux applications running on JDK 9 or later; the demonstrated exploit path requires a Tomcat WAR deployment, while applications packaged as Spring Boot executable jars are not exploitable that way, though the underlying issue may be reachable via other routes. A successful attack yields full remote code execution with the privileges of the application server, with no authentication or user interaction required. VMware Spring Framework 5.3.0-5.3.17 and 5.2.0-5.2.19 (plus older releases) are affected, and the flaw also impacts bundled products from Cisco, Oracle, Siemens and Veritas, including multiple Oracle Communications Cloud Native Core components. It is being actively exploited in the wild: added to CISA's KEV on 2022-04-04, EPSS puts 30-day exploitation probability at 99.6% (100th percentile), a public PoC is available, and mass scanning of vulnerable servers has been observed. Do: Upgrade Spring Framework to 5.3.18, 5.2.20 or later (or apply vendor-supplied fixes for bundled products, e.g., via Oracle's patch release and Cisco's advisory), prioritizing internet-facing Tomcat WAR deployments on JDK 9+; this is a CISA KEV entry, so treat patching as urgent. If patching must wait, mitigate by running on JDK 8, deploying as a Spring Boot executable jar rather than a WAR on Tomcat, and applying the vendor-documented workaround that disallows 'class.*', 'Class.*' and 'module.*' fields in data binding. Inventory exposed Tomcat/Spring services and hunt for signs of exploitation given confirmed in-the-wild use. | 9.8 | 100% | KEV PoC |
| massmass - on the order of 1M+ Spring-based Java deployments overall, with at least ~100,000 internet-exposed Tomcat servers on JDK 9+ plausibly meeting the… |
Full article786 words · extracted from helpnetsecurity.com · click to collapse
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.
Text extracted automatically; images, tables and formatting may be missing. Original: https://www.helpnetsecurity.com/2022/03/31/spring4shell/