Back
Summary
Shortly after the Apache Software Foundation (ASF) released the bug fix for the vulnerability known as Log4Shell or LogJam (CVE-2021-44228), a new vulnerability was discovered in Log4j Java-based logging library, tracked as CVE-2021-45046.
While Log4Shell had the maximum CVSS score of 10, this new vulnerability is rated as 3.7, affecting all versions of Log4j between 2.0-beta9 and 2.12.1, as well as between 2.13.0 and 2.15.0.
The fix addressing Log4Shell was incomplete in certain non-default configurations, which could allow an attacker to craft malicious input data using JNDI Lookup, resulting in denial of service (DoS) or worse, according to Apache.
CVE-2021-45046
This new vulnerability may allow attacks through the Thread Context Map (MDC) input data when the configuration uses a non-default Pattern Layout with either:
- Context Lookup pattern, example: “$${ctx:loginId}”
- Thread Context Map pattern, example: “%X”, “%mdc” or “%MDC”
A crafted malicious input data could trigger a JNDI Lookup that results in denial of service (DoS) attack.
Conclusion
While many organizations are still dealing with Log4Shell (CVE-2021-44228), CVE-2021-45046 should further intensify efforts to update systems. We strongly recommend anyone using Log4j to update to the latest version or follow all of the mitigation steps recommended by Apache.
Protection
Netskope Threat Labs is actively monitoring this campaign and will ensure coverage for all known threat indicators and payloads.
Update/Patch
The fix for CVE-2021-45046 was released in Log4j 2.12.2 and Log4j 2.16.0. Both vulnerabilities (CVE-2021-44228 and CVE-2021-45046) can also be mitigated by removing the JndiLookup class from the classpath.
Example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Furthermore, as of Log4j 2.15.0, the message lookups feature was disabled by default, but it still works in configuration. This feature can be disabled by setting system property “log4j2.formatMsgNoLookups” to “true”.
Netskope Private Access
If you are running internal applications that cannot be immediately patched, you can mitigate the risk of exploitation by limiting access to the app. A private access solution, such as Netskope Private Access, can be used to make private apps invisible to external attackers who seek to exploit vulnerable services. Furthermore, a private access solution can restrict access to a private app internally, such that only authorized users are able to access the app, reducing the risk that a compromised user or device could be used to exploit vulnerable services.
Read the blog