Second Log4j Flaw Discovered But patch Already Release

A vulnerability in the Apache Log4j aka "Log4Shell " which is now tracked as CVE-2021-44228 has surfaced online, as just after one or two hours its exploit and PoC released which allows the attackers to remotely execute code in the vulnerable system. 

It was noted that more than billions of applications were vulnerable to Log4Shell vulnerability. After a couple of days, another vulnerability has come to light. 

“A second vulnerability involving Apache Log4j was found on Tuesday,” according to a MITRE alert. “The description on the new CVE 2021-45046 said the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was ‘incomplete in certain non-default configurations.’”

What is Second Log4Shell & How Bad it is?

Earlier today, the second Log4j vulnerability (CVE-2021-45046) was upgraded from a CVSS score of 3.7 (limited DOS) to a CVSS score of 9.0 (limited RCE), after the researcher shows the technique to achieve RCE on 2.15.0

With the discovery of the first vulnerability which makes much louder sound throughout the internet, this second vulnerability doesn't make as much noise as Log4Shell. The fixes/ patch released for CVE-2021-44228,  log4j2.15.0 was incomplete in certain non-default configurations. To mitigate the previous Log4jShell vulnerability it is recommended to upgrade the Log4j version to the latest v2.15 (at that time). But if have updated the Apache Log4j version to 2.15 to mitigate the Log4Shell vulnerability then -    You may still be vulnerable to Log4Shell (RCE) if you only enabled the noMsgFormatLookups flag or set %m{nolookups} when you also set data in the ThreadContext with attacker-controlled data. In this case, you must upgrade to 2.16.0, or else you will still be vulnerable to RCE.

In our earlier post, we have recommended everyone update the Log4j to v2.16. Apache team also says- 

“This could allow 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 a denial-of-service (DOS) attack.”

“Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default.” But previous mitigations that involve “configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do not mitigate this specific vulnerability,” MITRE warned. “Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).”

With the release of the CVE-2021-44228, dozen groups started scanning the internet to these vulnerabilities. It is been observed that attackers are exploiting the vulnerability for deploying the ransomware on the vulnerable system. Security firm, BitDefender, found attackers deploying Khonsari and Orcus Remote Access Trojan (RAT) after exploiting the Log4Shell Vulnerability. 

We have a dedicated post for Mitigation and resources for Log4Shell Vulnerability and we recommend to go read that. 

Log4j 2.16.0 completely mitigates this issue by removing support for message lookup patterns and disabling JNDI functionality by default.