Updated April 13th, 2022 to include the latest available information about CVE-2022-22965, further explanation of dependencies in Spring Framework, and data about the prevalence of this vulnerability in cloud environments.
Two critical Remote Code Execution (RCE) vulnerabilities were recently patched in popular Spring Java libraries, and both have generated quite a bit of buzz:
CVE-2022-22965 (Spring Framework RCE via Data Binding on JDK version 9 or higher) –
This vulnerability affects Java software dependent on Spring Framework versions earlier than 5.2.19, and versions 5.3.0 to 5.3.17. Developers must update their software’s dependencies to Spring Framework versions 5.3.18 or 5.2.20, or apply any of multiple workarounds suggested by Spring.
Dubbed “Spring4Shell” (in the same vein as “Log4Shell”), this vulnerability has received the most attention so far. This is mostly due to the widespread use of the Spring Framework libraries in Java-based software, and partly because of debated comparisons to Log4Shell and an initial lack of vendor validation following the vulnerability’s debut. Praetorian have claimed that this vulnerability is in fact a bypass of a much older vulnerability in Spring Framework (CVE-2010-1622).
CVE-2022-22963 (Spring Cloud Function RCE via malicious SpEL Expression) –
This vulnerability affects Java software dependent on Spring Cloud Function (SCF) versions earlier than 3.1.6, and versions 3.2.0 to 3.2.2. Developers must update their software’s dependencies to SCF versions 3.1.7 or 3.2.3.
Initially rated as medium severity, VMware have since changed their assessment and rated this vulnerability as critical. Because this vulnerability also affects an (unrelated) Spring library, happened to be published the same day as Spring4Shell and was already assigned a CVE, the two vulnerabilities have been frequently conflated. Now that Spring4Shell has a CVE of its own, we expect this confusion to dwindle.
Technical details
In short, resources running software incorporating affected versions of these libraries are potentially vulnerable to specially crafted HTTP POST requests that allow an attacker to remotely execute code on the machine. Remote exploitability of both vulnerabilities requires that resources running vulnerable applications will be exposed and have an open HTTP port.
However, there are mitigating factors that limit exploitation of these vulnerabilities in real-life situations. In the case of Spring4Shell, for example:
Applications must be using JDK version 9 or higher
Application dependencies must include spring-webmvc or spring-webflux
Applications must use data binding with particular parameter types
This combination of requirements is due to the nature of Spring4Shell - while the underlying bug is technically located in spring-beans, the only currently known methods of triggering it are via the abovementioned spring-webmvc or spring-webflux libraries - both are dependent on spring-beans, as can be seen in the following dependency tree:
Additionally, currently known exploitation methods of Spring4Shell have the following prerequisites, though these could very well change as new exploits emerge:
Applications must be packaged as WAR files (requiring a web container to run, as opposed to traditional JAR files)
Web applications must be served by Apache Tomcat, GlassFish or Payara (as a web container)
All these conditions might only be present in few actual real-world applications, and none have been publicly discovered so far (excluding intentionally vulnerable applications purposely built by security researchers to showcase this vulnerability). However, this vulnerability does affect some code samples from tutorials on Spring's website, and these could have been used as the basis for some applications, so it's difficult to determine the exact impact of Spring4Shell at the moment.
As for CVE-2022-22963 (the SCF vulnerability), although exploitation is simple and multiple proof-of-concept (POC) exploits have already been published online, it is only exploitable in applications using routing functionality. Moreover, most software dependent on the SCF library is probably running on short-lived Function-as-a-Service (FaaS) instances. Our own data shows that this library is not very prevalent in cloud environments, and is indeed mostly found on Serverless resources. Therefore, although many environments might have some affected resources, we expect this vulnerability's practical impact to be limited.
Note that much like in the case of Log4Shell, end-users cannot update dependency versions of vulnerable 3rd party applications, and must wait for maintainers to release patches for affected software.
Protecting your cloud environment with Wiz
As of March 31, 2022, Wiz scans customer cloud environments for any affected application dependent on vulnerable versions of both aforementioned Spring Java libraries.
Wiz is a full stack agentless solution for securing cloud environments. Our unique scanning technology allows users to detect vulnerable installations across all cloud workloads in their environments within minutes of deployment, track their progress on patching affected resources, and prioritize patching efforts based on toxic combinations like external exposure or admin permissions on an affected resource.
In the case of these newly discovered vulnerabilities, Wiz gives further precedent to resources with open HTTP ports, to help customers focus on identifying and patching resources most at risk of exploitation.
The Wiz Threat Center is the best place to view any critical security issues affecting your environment. It contains pre-built Controls that retrieve all resources with vulnerable versions of Spring Cloud Function and Spring Framework, and display their corresponding privilege escalation paths – all with one click.
Prevalence of CVE-2022-22965 in cloud environments
Our data shows that about 63% of cloud environments are affected by CVE-2022-22965, though in many cases the vulnerable resources are not exploitable by current publicly known exploits. Out of all affected resources, around 75% are virtual machines and 25% are containers.
This blogpost was written by the Wiz Research Team, as part of our ongoing mission to analyze threats to the cloud, build mechanisms that prevent and detect them, and fortify cloud security strategies.
