17.12.2021

Log4Shell: Last Updated [28.12.2021]

Log4j Vulnerability

Revision history

DateVersion
13.12.2021Initial CVE - CVE-2021-44228
15.12.2021Second CVE - CVE-2021-45046
17.12.2021CVE-2021-45046 - Elevated to Critical
20.12.2021CVE-2021-45105 - DoS vulnerability found
28.12.2021CVE-2021-44832 - RCE vulnerability found in Log4j 2.17.0 (FUD)

The log4j vulnerabilities

On December 9, 2021 a serious vulnerability, CVE-2021-44228, in one of the most widely used Java logging libraries Log4j was disclosed. This vulnerability affects versions 2 of Log4j from 2.0 and 2.14.1. An older, end-of-life, version 1 of the library is not affected by this vulnerability but should be phased out none the less.

On December 14, a new attack vector was found, CVE-2021-45046, that invalidated some of the mitigations used for the initial vulnerability CVE-2021-44228 in some non-default configurations.

On December 17, the severity of the second CVE was upgraded from CVSS 3.7 to 9.0 due to a limited RCE possibiltiy inherent in the vulnerability that was missed when it was initially classified as a DoS vulnerability. That same day a DoS vulnerability was found, tracked with the CVE CVE-2021-45105, which is fixed in version 2.17, an update is recommended.

On December 28, a new vulnerability for Log4j 2.17.0 was disclosed, CVE-2021-44832, this vulnerability is an RCE vulnerability and requires some non-default preconditions, making it not as severe as CVE-2021-44228. To properly protect against CVE-2021-44832 you must update to 2.17.1. The preconditions that need to be met to make CVE-2021-44832 exploitable are the following:

  • An attacker must be able to modify your Log4j configuration file
  • You are using the JDBC log appender with a dynamic URL and an attacker can control it

This means that only two real mitigations are available, which are an upgrade to the most recent version of Log4j or complete removal of the JndiLookup class from classpaths.

“An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From Log4j 2.15.0, this behavior has been disabled by default.” according to the Apache Log4j security announcement.

  • The base CVSS Score of the initial CVE, CVE-2021-44228, is 10.0
    • Initial CVSS: 3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
  • The upgraded CVSS Score of the second CVE, CVE-2021-45046, was upgraded from 3.7 to 9.0
    • Intial CVSS: 3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L
    • Updated CVSS: 3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
  • The library has been patched as of 2.16.0
  • LDAP/LDAPS/RMI and DNS prefixes have all been observed in the wild.

Log4j

One of the greatest challenges posed by this vulnerability is that it’s difficult to figure out which servers are affected. Although everyone should first consider internet-facing systems in Java, determining both the breadth and depth is quite tricky and CVE-2021-44228 is not restricted to only internet facing Java services. The vulnerability may be found anywhere where user-supplied data is processed and logs are maintained.

Potential Impact

Malicious attackers may

  • Plant backdoors to sell or use later.
  • Steal data
  • Ransomware
  • Cause “Chaos” or destroy

How to mitigate CVE-2021-44228

Current recommendations

The industry standard mitigations, as of December 17th, are the following.

  • Upgrade to Log4j 2.16.0 if possible
  • For all releases of log4j2, the mitigation is to remove the JndiLookup class from the classpath: Remove the JNDILookup class from classpath. 
    zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Previous recommendations

As the threat landscape is rapidly evolving several mitigation strategies have been proposed that have later been deemed insufficient due new attack vectors.

The following recommendations can therefore not be considered sufficient at this time

  • Initially an upgrade to Log4j 2.15.0 was recommended but due to the new attack vector it is no longer considered sufficient.
  • If you are unable to upgrade, then in releases >= 2.10 this behavior can be mitigated by setting either the system: 
    log4j2.formatMsgNoLookups=true
  • This prevents {$jndi:…} activity from triggering network connection which may mitigate exfiltration and code implants

Less effective mitigations

In rare cases when neither is possible, it may be possible to mitigate or slightly reduce potential impact by performing any of the following:

  • Prevent outbound connections from servers and remove the possibility of fetching LDAP and RMI payloads over the internet.
  • Certain WAF’s have already published rules to prevent this exploit, such as CloudFlare.
  • It is also possible to update Java, which will mitigate LDAP class loading but not RMI
  • With all that said and done, it’s always possible that a malicious attacker may plant a Gadget that may still work in your specific environment.

Timeline

Reading Material

Sources

Sophos