Log4Shell: How It’s Being Exploited and How to Mitigate Damage

Join us this Wednesday, December 15 at 11AM ET for an update on the evolving situation with Log4Shell. The briefing will be followed by a live Q&A. Click here to register.

CVE-2021-44228 is a critical vulnerability affecting Log4j, a widely used, open-source logging library written in Java. The vulnerability in Log4j will parse a specially crafted log message insecurely, causing it to execute remote code with the full privileges of the main program. The exploit has been dubbed Log4Shell. 

On December 9, 2021, Chen Zhaojun of the Alibaba Cloud Security Team discovered and released sample code for a major remote code execution vulnerability in Apache's Log4j technology. In a now-deleted social media post, Zhaojun shared a proof of concept (POC) for the Log4j vulnerability. Initially, the vulnerability was thought to be limited to Minecraft, where it was used by trolls to take over the game’s servers, but it was quickly discovered that it was more broadly applicable.

A vulnerable Log4j instance will interpret the specially crafted log message as a legitimate log then attempt to access and deserialize content, such as a web resource or executable code. For example, the vulnerability could allow an attacker to initiate Lightweight Directory Access Protocol (LDAP) traffic to an attacker-controlled node from the Java Naming and Directory Interface (JNDI). The attacker-controlled node will respond with a malicious Java class file that then begins running on the victim server.

Threat Activity

Recorded Future observed scanning and exploitation behavior beginning within hours of the vulnerability’s disclosure, nearly all from Tor. GreyNoise and Bad Packets observed similar traffic. Imperva reported 1.4 million attempts to scan for the vulnerability. Cloudflare and Cisco Talos reported Log4Shell scanning attempts 2 weeks before public disclosure, suggesting the exploit was in the wild prior to the public disclosure.  

Some companies have offered their services to monitor and publish tagged IP addresses that appear to be scanning for the Log4j vulnerability. Other organizations, such as Cloudflare, have openly stated that the damage potential is so great that they are introducing proactive mitigation measures, even for non-paying organizations. Individuals at the collective Curated Intel have compiled a listing of Log4Shell indicators of compromise.

Microsoft has stated that the vast majority of activity observed is mass scanning to fingerprint servers, though they have also witnessed “exploitation and post-exploitation” activity. Researchers across social media have also reported malicious exploitation. BlackBerry researcher Greg Linares reports witnessing attacks specifically targeting SIEM installations, specifically Splunk. Splunk has stated that Data Fabric Search (DFS) and Splunk Analytics for Hadoop (Hunk) product features are affected and has provided guidance on how to remove Log4j from Splunk. An anonymous author created a GitHub repository to track affected manufacturers.

Dark web threat actors on XSS and Exploit forums have discussed the Log4Shell exploit and shared links to POC code. Some threat actors mentioned that GitHub appeared to be taking down these POC repositories, but many have been forked, and several can be openly found and are repeatedly linked. Some of the traffic may be lower given the extreme ease of exploiting Log4Shell. The Record reports that most attacks currently originate from cryptomining and botnets, including Mirai, Muhstik, and Kinsing. Microsoft has reported seeing Log4Shell used to deploy web shells and Cobalt Strike.

Notably, some defenders are publicly posting detections and tests using DNS leak detection services, many posting screenshots from the service DNSlog. We advise caution in using any anonymous services for testing your infrastructure, especially as DNSLog has not yet disclosed who has access to their logs, which could be useful to an attacker in enumerating vulnerable hosts.

Forecast

The Log4Shell exploit is useful both for initial access and lateral movement, as both externally facing and internal services can use the Log4j logging library. The earliest activity detected by Recorded Future for this vulnerability identified criminals actively exploiting it; active exploitation continues. BlackBerry researcher Greg Linares predicts the likelihood of a wormable version within the next few days, with some groups reportedly actively working on such versions.

How Recorded Future Is Affected

The security of Recorded Future's infrastructure and the customer data we hold is of paramount importance. Recorded Future does not use the Log4j library in any of our proprietary code, and we currently have no evidence that this vulnerability has been exploited on our systems. To the extent that Log4j is used by vendors that supply Recorded Future, we have deployed mitigations to address any known vulnerabilities. As we validate these mitigations, Recorded Future operations teams continually monitor and deploy any needed changes in response to emerging risks.

Procedure for Testing and Mitigating Log4j

Users can hunt for traffic attempting to exploit the software by looking for the strings '{jndi:', ‘${’, or long User-Agent strings in web-server logs. The Dutch CERT (Nationaal Cyber Security Centrum) has published a GitHub repository, which includes a detection regex: 

${(${(.?:|.?:.?:-)('|"|)*(?1)}*|[jndi:lapsrm]('|"|)}*){9,11}

Signature-based detection is likely insufficient alone, and obfuscation has already been observed. Clients can also use traffic to known callback addresses as a starting point to investigate any internet-facing hosts vulnerable to Log4Shell. While traffic to these addresses is not indicative of compromise, they display that a host responded to a Log4Shell packet. We recommend inspecting outbound LDAP, HTTP, and RMI (a custom Java protocol typically used on port 1099) traffic as a starting point to triage internet-facing hosts that may be exploited.

Different mitigations are available depending on the version deployed. Defenders can modify the logging config files by setting 'formatMsgNoLookups=true' to stop logging lookups from occurring. The older versions (2.10.0 and below) include '%m {nolookups}' in the configuration files instead of the “%m” to stop the server from looking up data added to the logs. These are the fixes provided automatically in version 2.16.0 of Log4j. Tenable also recommends removing JdniLookup and JdniManager classes from Log4j-core.jar.

Figure 1: Steps of a log4j JNDI attack and suggested mitigations (Source: Swiss CERT)

Several government CERTs, security companies, and blogs have been published with guidance to assist defenders. The Swiss CERT published the guide depicted in Figure 1 above to show various mitigations to defend against Log4Shell.

1. Check for the affected version. The affected versions of Log4j are 2.0 through 2.14.1. If you have the affected version, check for the current Java version. Log4j-2.16.0 requires Java 8.
2. If you have Java 8, update to 2.16.0.
3. Isolate affected systems to a “vulnerable VLAN”. You should also review firewall rules between affected hosts and the rest of your enterprise.
4. Monitor for outbound traffic patterns. An example would be a DMZ system that initiates outbound connections.
5. Look for unauthorized configuration changes on all systems. (Credit for steps 3-5 to SANS instructor Mick Douglas)

Figures 2 and 3: Recorded Future Intelligence Card on CVE-2021-44228 (Source: Recorded Future)

Resources

• GitHub advisory database
• Apache Logging security advisory
• LunaSec blog dubbing Log4j exploit “Log4Shell”
• Reddit r/programming subreddit thread
• VMWare advisory about affected products
• Swiss CERT guidance
• The Record story on Log4Shell