How Cortex XDR Blocks Log4Shell Exploits with Java Deserialization Exploit Protection

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

Overview: Cortex XDR’s approach to blocking Log4Shell attacks

On December 9, 2021, a critical Remote Code Execution (RCE) vulnerability in Apache’s Log4j library was discovered being exploited in the wild. This vulnerability, known as Log4Shell, lets a remote attacker execute arbitrary code on an affected server.

The Cortex XDR agent provides comprehensive protections for endpoint attacks, including Log4Shell attacks. It helps block Log4Shell 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 Log4Shell, the Cortex XDR agent can stop post-exploit activity on Windows, Linux and Mac systems, but it also can proactively block the exploit itself on Linux systems.

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

Deserialization exploits and Log4Shell

In response to Log4Shell, the Cortex XDR research team issued a 911 content update that helped mitigate the Log4Shell exploit in less than 48 hours from the discovery of in-the-wild exploitation. In this post, we will delve into Java exploitation, how the Log4Shell exploit works and how Cortex XDR leverages the Java deserialization module to block the exploitation attempt on Linux systems.

What are serialization and deserialization, and how do they lead to RCE exploits?

Serialization is the process of turning some object into a data format that can be restored later. People often serialize objects in order to save them to storage, or to send as part of communications.

Deserialization is the reverse of that process, taking data structured from some format, and rebuilding it into an object. Today, the most popular data format for serializing data is JSON. Before that, it was XML.

However, many programming languages offer a native capability for serializing objects. These native formats usually offer more features than JSON or XML, including customizability of the serialization process.

Unfortunately, the features of these native deserialization mechanisms can be repurposed for malicious effect when operating on untrusted data. Attacks against deserializers have been found to allow denial-of-service, access control and remote code execution (RCE) attacks. Once an attacker manages to deserialize using a native deserialization mechanism, they can usually perform code execution.

How does the Log4Shell exploit work?

The Log4Shell exploit is a logical exploit within the log4j logging framework, where every time a log is issued the Log4j code looks for a specific url pattern of JNDI:[protocol]//[ip]/uri. If that pattern is being logged, the Log4j code will leverage the JNDI framework and will load Java code from an attacker-controlled IP address or domain and port using DNS, RMI, IIOP or LDAP/S and others.

There are a few steps to this exploit:

1. An attacker finds a user-controlled input that is logged using Log4j. (This is an extremely wide attack surface and can be found in practically every user input field)
2. The attacker sends a malicious JNDI URL with an attacker-controlled IP that is routable from the host.
3. The host sends out a request to the attacker-owned IP over the supplied protocol and port.
4. The attacker’s server responds with a Java class to be loaded and executed.
5. The Java Virtual Machine (JVM) loads the Java class, executing the code within that class and usually opening a process on the remote host.

Is the Log4Shell exploit a Java deserialization exploit?

Strictly speaking, the Log4Shell exploit isn’t a Java deserialization exploit, but it does bear the same hallmarks as the last steps of code execution of a Java deserialization exploit. As it leads to loading attacker-controlled code into the JVM and executing that code, the same mechanism and mitigations for Java deserialization exploits apply to this exploit as well.

How does Cortex XDR defend against Java deserialization exploits?

Whenever a new process is created on a protected Linux device, the Cortex XDR agent evaluates whether that process is using the JVM and injects the Java Deserialization Exploit Protection Module (EPM) into that process. That module leverages hooking facilities within the Java runtime to modify the runtime of the Java execution so that some methods are evaluated for suspicious execution patterns. Once such a method is executed, the EPM looks at the stack trace of the execution and checks whether the execution stack has the context of a deserialized object. When that happens, the module blocks the activity and denies remote code execution.

Java Deserialization EPM

Cortex XDR hooks into the JVM and detects attackers executing unauthorized queries, calling unauthorized classes and performing many other types of illicit activity.

Cortex XDR vs Java Deserialization Exploits

Java deserialization exploits usually follow a standard pattern – if a code path ends up deserializing objects in memory by attacker-provided input, that code path can be leveraged for a remote code execution exploit. In that case two things must happen:

• A deserialization function or class must be called.
• The deserialization function leads to either loading a class, running a process or dropping a file – usually a webshell.

Cortex XDR agent hooks potential deserialization code paths and validates that no code execution happened afterwards, stopping deserialization exploits that lead to remote code execution (RCE).

Cortex XDR blocking an Apache Struts deserialization exploit and preventing RCE.

Cortex XDR vs Log4Shell

Since Log4Shell uses the same set of exploitation primitives, meaning that it will load a class, drop a file or execute a process, the Java Deserialization EPM is at a good vantage point to block the activity.

Similar to how we block regular Java deserialization exploits, the module looks up the stack when such activity happens, and if JNDI functions are in the stack, the module will kick in and block the activity, including RCE and environment variable leaking that might lead to credential theft and enumeration.

We have seen active exploitation being blocked by the Java Deserialization EPM, where the attacker would have potentially executed coin miners and discovery commands on the remote host. However, since the hosts were up to date with the latest agent version and content, these attempts were blocked.

Conclusion

As more sophisticated attackers leverage this exploit, 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 Log4Shell.

Additional Resources

Unit 42 Briefing: Apache Log4j Threat Update

Hunting for Log4j CVE-2021-44228 (Log4Shell) Exploit Activity

Addressing Apache Log4j Vulnerability with NGFW and Cloud-Delivered Security Services

Threat Hunting and Investigation Hands-on Workshop - Learn How to Hunt Threats

Cortex XMDR managed detection services for 24/7 incident response