How Cortex XDR Blocks SpringShell Exploits

This post is also available in: 日本語 (Japanese)

Overview: Cortex XDR’s approach to blocking SpringShell attacks

Recently, two vulnerabilities were announced within the Spring Framework, an open-source framework for building enterprise Java applications and in Spring Cloud Function. In this blog we will dive into the coverage Cortex XDR provides for both SpringShell and the related Spring Cloud Function RCE.

Cortex XDR provides comprehensive protections for endpoint attacks, including SpringShell attacks. It helps block SpringShell and other related exploits post-exploit activity with its Behavioral Threat Protection, AI-driven local analysis, cloud-based malware analysis and other security engines across Windows, Linux, and Mac systems.

Cortex XDR has been designed to block as many steps in the attack lifecycle as possible, from the initial signs of reconnaissance and exploitation to the behaviors exhibited after a process is launched. But Cortex XDR also focuses on blocking attacks early in the attack lifecycle – such as at the exploit stage – to prevent subsequent infection and damage. For example, with SpringShell, the Cortex XDR agent can help stop post-exploit activity on Windows, Linux and Mac systems, but it also can help proactively block the exploit itself on Windows and Linux systems.

The rest of this blog presents a deep dive into how Cortex XDR blocks SpringShell exploits in Linux and Windows environments using Java Deserialization Exploit Protection. To understand how Cortex XDR helps protect Windows, Linux and Mac endpoints with SpringShell, view the SpringShell blog post published by Unit 42. To read more about Java exploits, read the Log4Shell blog post.

Cortex XDR vs SpringShell

In response to SpringShell, the Cortex XDR research team issued a 911 content update that helped mitigate the related exploit CVE-2022-22963 for our Linux agents in a few days from the discovery of the exploit. Furthermore, with the release of Cortex XDR 7.7 and content version 460-88346 we have added the Java Deserialization Endpoint Protection Module (EPM) to Windows and Linux devices as well and provided coverage for both CVE-2022-22963 and CVE-2022-22965 for known proofs of concept (PoCs) at the time of publishing.

In this post, we will delve into how Cortex XDR blocks this activity at its earliest stage.

Are these exploits deserialization exploits?

Technically these are not deserialization exploits, but an input validation issue. The first exploit (CVE-2022-22963) allows an attacker to specify a specific field in the request header that will later cause java commands to be executed. This exploit was patched by not allowing an attacker to cause this specific field from the request header to be executed.

The second exploit happened because a Spring feature enables access to specific java class attributes using HTTP request parameters and enables these attributes to be accessed and modified. The exploit is caused due to access to “hidden” class attributes, for example the “class” attribute which can be leveraged into accessing different classes and regions that were previously inaccessible, opening up multiple exploitation options to the attacker. These exploits were patched by the Spring team by allowing access to only named properties of the developer’s class. For more information about this exploit please read the root cause analysis by Unit42.

Cortex XDR vs CVE-2022-22965 (AKA SpringShell, Spring4Shell)

As described in the Unit 42 blog in detail, the public exploit enables modifying the logging directory of the Tomcat server running Spring and enables attackers to write a webshell to a directory served by the server, enabling the attacker to gain full control over the host.

The Java Deserialization module on both Windows and Linux hosts hooks the relevant functions and verifies that the modification of the server attributes are from a malicious code path. If that happens, Cortex XDR detects this activity.

SpringShell exploitation attempt blocked on Windows host

Cortex XDR vs CVE-2022-22963 (AKA Spring Cloud Function RCE)

The Spring Cloud Function command execution exploit is a remote command execution exploit allowing the attacker to cause a java command injection by crafting a malicious request. While this product is less common, the exploitation method is easy to implement and unlike SpringShell, the currently available POCs do not require an Apache Tomcat server in WAR deployment to exploit.

Cortex XDR’s Java Deserialization module hooks java’s process execution function and validates if the function was called from a vulnerable chain. If that happens, the process creation is blocked and java is terminated, blocking the exploitation attempt.

Spring Cloud Function RCE exploitation attempt blocked on a Linux host

Post-exploitation protection

As part of our response to SpringShell and many other similar attacks resulting in compromised web servers, we have built generic and specific rules for post-exploitation activities such as dropping webshells and further lateral movement that can be achieved leveraging the access these exploits provide.

While our full suite of BTP and Analytics detection will help with generic attack techniques we have also added the following rules to help block and detect similar activities:

Conclusion

Customers are advised to update their Cortex XDR agents to the latest version and latest content version and specifically for these exploits, upgrade to Cortex XDR agents to version 7.7 and content update 460-88346. Furthermore, customers are advised to enable the Java Deserialization module on Windows hosts via the exploit protection policy.

It's possible that sophisticated attackers could leverage this exploit, and to prevent this we highly suggest staying up to date with the latest agent version and content update and leveraging the mitigations described in the Unit 42 blog post about SpringShell.

Furthermore, when a new vulnerability is discovered, see how you can hunt for signs of compromise, investigate alerts, and find vulnerable software using our incident response simulation system for log4j.

Additional Resources

• Unit 42 blog post about SpringShell
• Spring’s SpringShell exploit notice
• Spring’s Cloud Function RCE notice