A newly discovered Spring vulnerability enables remote code execution on enterprise Java applications.

In late March, a developer publicly posted exploit code describing a zero-day vulnerability in the popular Spring Framework, a popular solution for building enterprise applications in Java. Spring is part of VMWare's suite of enterprise products, designed to let developers quickly and easily develop enterprise-level applications. 

Spring4Shell is a vulnerability that allows attackers to remotely execute code on vulnerable applications without authentication. It uses ClassLoader access and has been assigned the following CVE designation: CVE-2022–22965.

How does Spring4shell Work?

Exploiting the Spring4shell vulnerability requires attackers to find (or create) compatible Java gadgets that allow the attacker to evaluate and run code remotely. Currently, that means using a widely exploited Apache Tomcat gadget that consumes the server's logging properties class loader. This allows attackers to bind user input to the domain model of an application and attach arbitrary code to various Java classes. 

An attacker may be able to use Apache Tomcat logging properties to call up Java processes that eventually allow the execution of arbitrary code. This might allow an attacker to encode and bind requests to Java classes and run that code whenever the class is called.

How Bad is the Spring4shell Vulnerability?

While Spring is the most popular enterprise application development framework for Java, the Spring4Shell vulnerability is not nearly as widespread as the log4shell vulnerability reported earlier in 2022.

To exploit Spring4shell, several other prerequisites must also be in place. For comparison, Log4shell impacted everyone using the widely popular library. 

Specifically, the vulnerability appears to stem from functions using RequestMapping annotation and Plain Old Java Object (POJO) parameters. It impacts Spring MVC and Spring WebFlux instances running on JDK 9 and above when the application is packaged in WAR format and deployed on Apache Tomcat servers.  

Typical Spring Boot deployments that use embedded Servlet containers or reactive web servers are not impacted. Similarly, Spring deployments that do not have both Spring MVC and Spring WebFlux dependencies are not impacted. 

Also, an attacker would need access to the source code of a Java gadget to compromise it. This is one reason why the vulnerability appears limited to a widely exploited Apache Tomcat gadget for now.

It's possible that attackers may compromise other gadgets in time or obtain access to gadget source code in other ways, which will expand the surface area impacted by Spring4shell. 

Nevertheless, many enterprise applications use specific configurations vulnerable to Spring4shell exploits. Enterprise IT professionals will need to identify susceptible systems and take immediate steps to remediate the risk.

Palo Alto Cortex XDR Can Detect Active Spring4shell Exploitation Attempts

The US Cybersecurity and Infrastructure Agency has announced that there is evidence of active exploitation of this vulnerability. It did not release any specific details about attackers's operations, but the announcement corroborates findings from reputable cybersecurity vendors around the globe. 

According to Palo Alto Networks, attackers have used this exploitation to deploy a web shell for backdoor access on vulnerable servers, allowing them to execute commands and distribute malware throughout the network.  

The company has already configured its Cortex XDR solution to detect Spring4shell exploitation attempts, providing protection to organizations that invest in best-in-class extended detection and response technologies. Lumif customers with Cortex XDR deployments are protected.

How to Respond to the Spring4shell Vulnerability

Spring has published guidance for enterprises impacted by Spring4shell. It recommends that affected organizations update their Spring Framework deployment to versions 5.3.18 and 5.2.20 or greater.  

Nevertheless, Spring understands updates aren't always immediately feasible in an enterprise environment and suggests the following temporary workarounds: 

• Upgrade Apache Tomcat. Apache Tomcat 10.0.20, 9.0.62, and 8.5.78 are not impacted by the vulnerability. 
• Downgrade Java to Version 8. Organizations that can't upgrade their Spring Framework or Apache Tomcat instances can protect themselves temporarily by downgrading to Java version 8. 
• Disallow Fields. Extending Spring's RequestMappingHandlerAdapter to update WebDataBinder and enable SetDisallowedFields after initialization can mitigate risks associated with vulnerability. This establishes a global setting that prevents the vulnerability from being successfully exploited.

These options should all be considered temporary workarounds while enterprises prepare themselves to update Spring Framework to its newest versions. That remains the best way to ensure your organization is unaffected by the vulnerability.

Contact us for further assistance.