This page will be updated as we add new guidance.
Last Update: 2:20 pm ET, Dec. 20, 2021
On December 9, 2021, the Log4j vulnerability, tracked as CVE-2021-44228, was publicly revealed via the project’s GitHub. This page collects all the intelligence that Randori has gathered since the release of the vulnerability that impacts many types of software, and likely billions of devices.
This vulnerability, which was discovered by Chen Zhaojun of Alibaba Cloud Security Team, impacts Apache Log4j 2 versions 2.0 to 2.14.1.
This weakness allows arbitrary code execution. A logging utility such as Log4j is meant to allow developers to log various types of data within their applications, this data is typically based on user inputs, but does not have to be.
The Log4j vulnerability allows an attacker to load any code they want via the Log4j logging structure. Threat actors can point the logging protocol to a Java library of their choosing, and it would automatically load the target.
We estimate Log4j to be as far reaching as the Heartbleed vulnerability and Shellshock combined. More than 2.5 billion devices running Java, coupled with the fact this vulnerability is extremely easy to exploit, means the impact is likely very far reaching.
In light of recent changes, we recommend an update to Log4j 2.17.0 for this vulnerability.
In the hours after the initial vulnerability was reported, the Randori Hacker Operations Center created a proof of concept exploit of the vulnerability. That analysis is collected at https://www.randori.com/blog/cve-2021-44228/, where it has been extensively updated as we’ve learned new information.
What is Log4j? What can it do?
The Apache Log4j library is a Java-based logging tool widely used in applications around the world. It’s a piece of software that saves data on a computer. It’s used to record log information in many different enterprise and cloud applications that consumers and businesses both use.
It logs a lot of information. When browsing a website, it will write down what IP address you have, what browser you are using (Firefox, Chrome, Safari, etc), when you made the request, what page you accessed.
The Log4j library is used ubiquitously in Java software. Oracle (the company that runs Java) says “There are more than 4.5 million Java developers, 2.5 billion Java-enabled devices, and 1 billion Java-based smartcards.”
What is the Log4j, or “Log4Shell,” vulnerability?
Log4j is the most ubiquitous logging capability for Java, and Log4j has been around for a decade itself. The vulnerability allows a malicious user to inject a JNDI that uses a URI to point to a potentially untrusted Java class on an attacker-controlled LDAP server, which forces the Log4j 2.x library to execute the code. Said another way— it’s a remote code execution vulnerability, meaning any attacker will almost certainly be able to run code of their choice on affected systems, making the computer do what they want.
Fastly has a detailed writeup of how the attack proceeds following the execution of the initial exploit.
The Log4Shell vulnerability is, at this time, specific to the Log4j 2.x version of the logger. Log4j 2.0 added lookups, including JNDI lookups. These JNDI lookups were not restricted, leading to the vulnerability. Log4j 2.17.0 resolves this issue by limiting the protocols by default to only java, ldap, and ldaps and limits the ldap protocols to only accessing Java primitive objects by default served on the local host.
Ben Baumgartner, director of targeting at Randori, explains the vulnerability in the video below.
Why is it so hard to stop?
Part of the challenge is that Log4j can be reached in a lot of different ways—the attack vector can be anything—HTTP request, text message, email, change name of computer. Any kind of data that uses a logging function is likely vulnerable. Because it is so easy to take advantage of, we expect it to be used in ransomware attacks.
We estimate the Log4j vulnerability to be as far reaching as the Heartbleed vulnerability and Shellshock combined. More than 2.5 billion devices running Java, coupled with the fact this vulnerability is extremely easy to exploit, means that the impact is very far reaching. The Randori Attack Team suggests it’s a 1 out of 10 in terms of ease of exploit—with one being the easiest.
Attackers may take this exploit and stuff it into all sorts of places and spray it over the internet. Eventually we expect targeted attacks and it to be used for ransomware.
The Log4j 2 library is very frequently used in enterprise Java software—it’s highly ubiquitous. Due to this deployment methodology, the impact is difficult to quantify. Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately. The diagram below, from Fastly, shows how the attack would operate.
Who is impacted?
Many, many services and technologies are vulnerable. Java and everything that uses java, including Android, and Apple. Steam, Apple iCloud, and apps like Minecraft have been proven to be vulnerable.
The Randori Attack team has proven with exploits—in live environments—the exploitability of VMware products and Jamf Pro. Thousands of enterprises will be impacted by the widespread nature of this bug. And, we estimate billions of devices—including IOT and embedded devices could be impacted, affecting consumers around the world.
Enterprise services with patches
What enterprise technologies are confirmed to be exploitable by the Log4j/”Log4Shell” vulnerability, and are there indicators of exploitation?
Jamf Pro is proven to be exploitable. Randori’s Attack Team has validated exploitability with working exploits that achieve code execution via unauthenticated network vectors specifically on Jamf Pro and anticipates widespread exploitation by threat actors imminently. Randori does not release proof-of-concept code. These exploits include 10.34.0 on Java 11.
Several VMware products were proven by Randori to be exploitable. VMware has assigned VMSA-2021-0028 to this issue and has begun to release mitigations. The Randori Attack Team can confirm exploitability of VMWare products in live environments (VMSA-2021-0028) via Log4j (CVE-2021-44228) aka “Log4Shell.”
Consumer technologies with patches
Which consumer products are confirmed to be exploitable by Log4Shell (that have a patch)?
Minecraft: Java Edition
What can consumers do to stay safe?
Minecraft has already rolled out a fix to consumers. Consumers who use Minecraft: Java Edition should deploy that patch.
Ultimately, most of the impacts will be felt on the enterprise side. The best thing consumers can do is watch for security advisories and updates from the apps they use.
How do I protect myself against the Log4j vulnerability?
As part of protecting your critical systems from the Log4j/”Log4Shell” vulnerability, Randori has several recommendations:
Review your attack surface to enumerate any external facing devices that have log4j installed.
Ensure that your security operations center is actioning every single alert on the devices that fall into the category above.
Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts, such as Google Cloud Armor.
Upgrade impacted applications to Log4j 2.17.0
Monitor and follow vendor advice for impacted third-party applications. Apply patches when available.
Please note: Hotpatching mitigations that are performed during runtime are only effective for the lifetime of the Java Virtual Machine and should not be relied upon for ongoing protection.
Apache has already released an update to Log4j 2 that patches this vulnerability. Vendors who use the Apache software impacted by Log4j/Log4Shell should immediately apply the patch released by Apache to their systems: https://logging.apache.org/log4j/2.x/security.html
Greynoise has also been compiling a list of hosts exploiting CVE-2021-44228; follow this link to see the complete list.
Researcher Florian Roth also published YARA detection rules.
This section will compile security guidance from major vendors as they release it.
Watch the video below to find out how Randori customers can use Randori Recon to enumerate their exposure to the Log4j 2 vulnerability.
For more details on remediation, read the Randori Attack Team’s blog at https://www.randori.com/blog/cve-2021-44228/.
