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:
- Spring Core RCE (critical): CVE-2022-22965 a.k.a. Spring4Shell or SpringShell
- Information exposure in Spring Cloud Function: CVE-2022-22963
- Denial of service in Spring Expressions: CVE-2022-22950
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
- 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:
- Sorting the vulnerability list by first seen
- Finding the vulnerabilities using the CVE or SNYK ID:
- Spring Core RCE: search for CVE-2022-22965 or SNYK-JAVA-ORGSPRINGFRAMEWORK-2436751
- Information Exposure in Spring Cloud Function: search for CVE-2022-22963 or SNYK-JAVA-ORGSPRINGFRAMEWORKCLOUD-2436645
- Denial of Service in Spring Expressions: search for CVE-2022-22950 or SNYK-JAVA-ORGSPRINGFRAMEWORK-2434828
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.
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.
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:
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
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
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
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.
- Spring Core RCE – Upgrade to versions 5.2.20 and 5.3.18 or higher.
- Information Exposure in Spring Cloud Function – Upgrade to versions 3.1.7 and 3.2.3 or higher.
- 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.
This article was co-authored with Robin Wyss.