Spring4Shell: Detect and mitigate new zero-day vulnerabilities in the Java Spring Framework

At the end of March 2022, three critical vulnerabilities in the Java Spring Framework were published, including a remote code execution (RCE) vulnerability called Spring4Shell or SpringShell.

Since then, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has reported “evidence of active exploitation”, recording more than 37,000 exploit attempts in the first few days alone. With a critical CVSS score of 9.8, outlets report active scanning attempts from around the globe.

What is Spring4Shell?

Spring4Shell is a critical vulnerability in the Spring Framework, an open source platform for Java-based application development. Because 60% of developers use Spring for their main Java applications, many applications are potentially affected.

Spring is popular because it enables software engineers to more easily write and test code to maintain modular applications. The Spring Framework enables developers to map user requests to Java objects. Other libraries enable developers to become less dependent on enterprise web servers and, therefore, reduce configuration complexity and cost.

Spring4Shell is one of three vulnerabilities published on March 30:

  1. Spring Core RCE (critical): CVE-2022-22965 a.k.a. Spring4Shell or SpringShell
    Affected library: org.springframework:spring-bean
  2. Information exposure in Spring Cloud Function: CVE-2022-22963
    Affected library: org.springframework.cloud:spring-cloud-function-context
  3. Denial of service in Spring Expressions: CVE-2022-22950
    Affected library: org.springframework:spring-expression

Like Log4Shell, a vulnerability discovered in December 2021, the Spring4Shell vulnerability challenges organizations to identify and remediate application vulnerabilities in production—before malicious attackers can compromise sensitive data, such as customer or employee data.

What is the impact of Spring4Shell?

With a CVSS score of 9.8, Spring4Shell is severe because if attackers exploit it, applications can be vulnerable to remote code execution (RCE). In fact, there are already proof-of-concept exploits available publicly. Accordingly, Spring has published a fix in Spring Framework 5.3.18 and 5.2.20.

Because Spring4Shell exposes an application to remote code execution, an attacker can possibly access all website internal data, including any connected database. It may also allow an attacker to access additional internal resources to gain more permissions or to make their way to other parts of an internal network.

How to identify whether your organization is vulnerable to Spring4Shell

As published in the Spring Framework RCE early announcement, malicious attackers can exploit the Spring vulnerability if an application operates under the following circumstances:

  • Runs on JDK 9 or higher
  • Uses Apache Tomcat as the servlet container
  • Packaged as a traditional WAR and deployed in a standalone Tomcat instance. Typical Spring boot deployments that use an embedded Servlet container or reactive web server are not impacted.
  • Depends on spring-webmvc or spring-webflux
  • Uses Spring Framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, and older versions

There are several methods and tooling available to identify if an application is affected. We explore the following options:

  • Dynatrace Application Security
  • Dependency Check open source tool
  • The Apache Maven Dependency plugin

Dynatrace Application Security detects Spring4Shell-affected components automatically

For customers using Dynatrace Application Security, Dynatrace detects all three vulnerabilities automatically and in all locations across highly distributed hybrid, multicloud environments.

In addition, if you have security notifications set up, Dynatrace automatically sends a notification with the relevant details for each vulnerability upon discovery.

Further, you can also find the vulnerabilities using Dynatrace in two other ways:

  1. Sorting the vulnerability list by first seen
  2. Finding the vulnerabilities using the CVE or SNYK ID:
Dynatrace detects Spring4Shell vulnerabilities in Java Spring Framework.

In this example, we can see how Dynatrace discovered CVE-2022-22965 and CVE-2022-22963.

Although you should upgrade all affected applications, your priority focus should be applications running on Tomcat and Java 9 or newer. In the following screenshot, you can see how Dynatrace captures all this information and provides the details for each affected process so you can prioritize mitigation actions.

Dynatrace automatically finds Tomcat versions affected by Spring4Shell
Dynatrace automatically finds Tomcat versions affected by Spring4Shell.

Because Dynatrace performs continuous full-stack monitoring, it has full awareness of the underlying runtime, including the Java version the vulnerable code runs. If you have many affected applications, you can extract a list of the affected processes that are on Java 9 or newer using Dynatrace APIs. You can find a sample Python script that uses Dynatrace Spring4Shell APIs on GitHub.

Scan folders using Dependency Check open source tool

Dependency Check is an open source tool you can use to find vulnerabilities in other third-party open source libraries.

There are different ways of using it, including as a command line tool, with a Maven or Gradle plugin, or integrated in third-party tools. In the following example, we use it as a command line tool.

To scan a folder for vulnerable libraries, run the CLI and point the tool to a folder, for example:
dependency-check --scan webapps.

Open source tool Dependency Checker finds Spring4Shell vulnerabilities in the target directory
Open source tool Dependency Checker finds Spring4Shell vulnerabilities in the target directory.

Once executed, the tool generates an HTML report that lists the vulnerabilities. The following example shows that the Spring4Shell vulnerability (CVE-2022-22695) is listed:

Open source tool Dependency Checker lists vulnerabilities it finds, including Spring4Shell
Open source tool Dependency Checker lists vulnerabilities it finds, including Spring4Shell.

Use the Apache Maven Dependency plugin to detect affected components manually

Another option is to use the Apache Maven Dependency plugin to identify whether your projects use affected libraries. To find out if your application exposes the vulnerability, navigate to the directory of your Maven project and run the following three commands:

Spring Core RCE

mvn dependency:tree -Dincludes=org.springframework:spring-beans
Maven finds Spring Beans vulnerability Spring4Shell
Maven finds vulnerable spring-beans version 5.3.13.

Here we can see that the application uses spring-beans version 5.3.13 and therefore has the vulnerability.

Information Exposure in Spring Cloud Function

mvn dependency:tree -Dincludes=org.springframework.cloud:spring-cloud-function-context
Maven finds information exposure in Spring Cloud Function in Java Spring Framework
Maven finds information exposure in Spring Cloud Function.

In this case, the application uses spring-cloud-function-context version 3.2.2, which means it exposes the vulnerability.

Denial of Service in Spring Expressions

mvn dependency:tree -Dincludes=org.springframework:spring-expression
Maven finds denial of service in Spring Expressions as part of Spring4Shell
Maven finds denial of service in Spring Expressions.

In this example, the application uses spring-expression version 5.3.16, which means it is vulnerable.

How to mitigate risk of Spring4Shell

To mitigate risk, upgrade to the latest versions to address the Spring4Shell vulnerabilities.

  1. Spring Core RCE – Upgrade to versions 5.2.20 and 5.3.18 or higher.
  2. Information Exposure in Spring Cloud Function – Upgrade to versions 3.1.7 and 3.2.3 or higher.
  3. Denial of Service in Spring Expressions – Upgrade to version 5.3.17 or higher.

See the Spring blog post Spring Framework RCE, Early Announcement for further details. We also suggest you take a look at the anatomy of the Spring4Shell vulnerability and how to prevent its effects—and those of similar vulnerabilities.

How to get Dynatrace Application Security

If you are a Dynatrace customer and want to start using the Application Security module for automatic runtime vulnerability analysis, go to the Dynatrace web UI and select Vulnerabilities in the menu (separately licensed).

However, if you’re not using Dynatrace yet, it’s easy to get started in under five minutes with the Dynatrace free trial. Contact us for how you can enable Dynatrace Application Security. In the meantime, have a look at our product tour.

If you are concerned about Spring4Shell’s effect on Dynatrace components, please have a look at our security alerts, specifically SpringShell CVE-2022-22965.

Spring4Shell: Identify and minimize your production risk

Join our on-demand webinar.

Acknowledgment

This article was co-authored with Robin Wyss.

Stay updated