On December 9, 2021, Apache revealed a severe Remote code execution vulnerability CVE-2021-44228 named “Log4Shell” in Apache Java-based log4J logging utility. Threat actors used the utility to execute arbitrary code and take complete control of systems.
Apache Log4j is an open-source Java-based utility widely used by cloud and enterprise software services for logging. Being used in many applications on various operating systems (like Windows, Linux, MAC, etc.) impacts all versions from 2.0-beta9 to 2.14.1. Threat actors have widely exploited Log4J to scan the internet-facing servers to identify vulnerable servers.
It is a high-profile security vulnerability with a severity score of 10, the max severity rating possible, and one of the most critical vulnerabilities ever due to its ease of exploitation and the number of affected enterprise applications and cloud services.
The Java Naming and Directory Interface (JNDI) used by Log4j to lookup supported services and protocols such as LDAP, DNS, RMI, NIS, NDS, CORBA, and IIOP allows for helpful information to be remotely retrieved. On a vulnerable Log4J system, the attacker who can control log messages or parameters can execute arbitrary code loaded from LDAP or supported services while message lookup substitution is enabled.
An unauthenticated, remote attacker could exploit it by sending a specially crafted JNDI injection in the simple HTTP request to a vulnerable log4j serve. Once the request is processed, log4j loads the JNDI resources from the server (i.e., LDAP) controlled by attackers that loaded payload could be malicious & include shell script or Java class file to the targeted system. Successful exploitation could lead to arbitrary code execution, and the attacker can take complete control of the compromised system.
The vulnerability was discovered on 24th Nov-21, first exploitation was observed on 1st Dec-21. After the initial fix patch, further other vulnerabilities, CVE-2021-45046 (remote code execution) & CVE-2021-45105 (denial-of-service) identified; are fixed in subsequent versions.
In the standard scenario, HTTP requests would be logged by the log4j utility at the server for debugging or another purpose whenever log analysis is required.
In an attack scenario, the Log4Shell could be exploited by an unauthenticated, remote attacker with JNDI payload in a simple HTTP request on a server with vulnerable log4j.
JDNI lookup would look like as below, where JNDI will try to fetch the payload from attackers-URL that would compromise the targeted server.
Attackers use various techniques in JNDI supported payloads like below using other protocols, encoding, obfuscation etc., to bypass the common detections by network security products.
2. In the User-Agent HTTP header, a simple JNDI LDAP string connects to a malicious URL.
3. Here X-API-Version header contains obfuscation (bypass techniques) jndi Ldap string with base64 encoded payload
The crafted JNDI string can be sent via URL or some of many HTTP headers listed below:
Quick Heal has released Network & End Points rules to identify and block remote attacks exploiting the Log4Shell vulnerability. Also, a detailed Advisory had been shared along with mitigation updates to customers. Below is the Log4Shell detection snapshot in our product.
We are continuing to monitor the developments around this threat. We advise all our customers to patch their systems properly and keep the AV software updated with the latest VDB updates.
Indicator of Compromise (IoCs)
Subject Matter Expert