News

Log4j Attack Methods Explained by CrowdStrike

• By Kurt Mackie
• 12/16/2021

CrowdStrike on Thursday presented advice for organizations attempting to address a security vulnerability in the Log4j Java logging framework used in Apache Web servers, currently undergoing widespread exploitation.

The advice came via a "Log4j2 Zero-Day Vulnerability Update" online session, presented by Adam Meyers, senior vice president of intelligence at CrowdStrike. In general, organizations should install the latest version of Log4j, if possible, which is version 2.16.0.

Log4j version 2.16.0 is for users of Java 8 or later products. The Apache Software Foundation, which oversees the Log4j Java logging library that's used in multiple applications, had issued updates with fixes earlier than this current version. However, those earlier releases have been deemed to be incomplete fixes per security researchers, so version 2.16.0 is the one to deploy.

Meyers noted that there is a Log4j version 1 product, but it's deprecated and not something to be relied on. "So definitely work to upgrade to the latest version and keep eyes on any vulnerabilities that are coming out," he said.

Organizations can also disable the Java Naming Directory (JNDI) as a workaround, "which is in the actual settings for Log4j."

Meyers cautioned to preserve "as much digital evidence as possible before you start mediating because this will enable us to understand the impact of that incident and how far the threat actor has gone." Organizations should preserve "both memory and disk evidence for these potentially impacted systems," he added.

Attack and Patch Timeline
Many organizations are subject to ongoing attacks leveraging this Log4j vulnerability, dubbed "Log4Shell." A list of affected apps compiled by the U.S. Cybersecurity and Infrastructure Security Agency (CISA) can be found in this GitHub post.

In the CrowdStrike online session, Meyers offered the following chronology, crediting Alibaba with first discovering the Log4j flaw:

• Nov. 24, an Alibaba researcher notified the Apache Software Foundation of a remote code execution vulnerability in Log4j.
• Nov. 29, the vulnerability called "Log4Shell" (CVE-2021-44228), gets a patch with the release of Log4j version 2.15.0-RC1, but it's not a complete fix.
• Dec. 5, Log4j 2.15.0-RC2 is released, which restricted protocols previously allowed, but it also still enables attacks using so-called "gadget chain" code within Log4j.
• Dec. 9, a proof-of-concept exploit gets circulated on the Internet, picked up by "a lot of different threat actors."
• Dec. 13, Log4j version 2.16.0 was released, which "removed some of the logging functionality and also disabled the Java Naming Directory (JNDI) … and this seems to fix the problem."

How Log4j Attacks Work
The exploit of Log4j's message lookup function is apparently easy to conduct by just sending a text string to a server, typically via HTTP. Meyers explained that it works via a deserialization process, which can be abused by attackers to execute "arbitrary class files" on a system.

Here's his explanation of the serialization and deserialization process:

Serialization is a topic that a lot of people aren't too familiar with, unless you're in the programming side of the house. And so if you think about an object in an object-oriented programming language, and you want to be able to move that object with its data and state to another process or to another system, and to transfer it efficiently, it's a binary set of information and so what they do is they convert it into effectively a string that can then be easily moved over a network and then deserialize.

Security issues can arise with this process when the "object contains user controlled data." A link to a Java class file will execute, for instance. Attackers use this method with JNDI to point to a Lightweight Directory Access Protocol (LDAP) server that they control, Meyers explained:

It [the exploit] is using the JNDI with LDAP and specifying host and path. When that gets processed, when that gets evaluated, it will go out to that server and pull down that code and execute it. So what we have seen a lot of organizations doing as well is on the network side trying to mitigate this by not allowing outbound communication from systems that they know might be running Log4j, working and evaluating things like LDAP queries that go out.

The reason why these attacks work is that JNDI lacks security controls on LDAP requests, CrowdStrike explained in this blog post. "Also, LDAP, contrary to other JNDI protocols, supports the loading of classes from remote resources."

Threat actors are currently experimenting with delivering various payloads using this vulnerability. CrowdStrike observed Kinsing cryptominers getting deployed on Dec. 10. Later, on Dec. 13, Nemesis Kitten malware was seen. Muhstik backdoor malware and XMRig miners have been observed as well.

Meyers mentioned that nation-state actor China is likely involved in the current attacks, and CrowdStrike is currently compiling that information.