This post is also available in: 日本語 (Japanese)
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.
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.
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.
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:
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.
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.
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:
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.
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.
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.