Log4J-Mitigation-CVE-2021-44228,CVE-2021-45046,CVE-2021-45105,CVE-2021-44832

Please keep an eye on this page as Apache Log4j team is disclosing a lot more CVE and fixing security issues very rapidly.

Update - 28-Dec-2021

CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.

Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6)

Update - 17-Dec-2021

Overnight, it was disclosed by Apache that Log4j version 2.16 is also vulnerable by way of a Denial of Service attack with the impact being a full application crash, the severity for this is classified as High (7.5) CVE-2021-45105 has been issued, and a new fixed version (2.17) has been published by Apache,recommended upgrading to.

Background:

Internet discussion was abuzz about a 0-day vulnerability (one that can yield remote code execution) in Apache’s popular Log4J logging library for Java. This particular vulnerability–tracked as CVE-2021-44228 with the maximum “critical” CVSS score of 10–resides in Log4J’s lookup capability, combined with JNDI (Java Naming and Directory Interface). This issue is widespread because many developers were unaware that Log4J was dangerous to use with unfiltered input.

The most significant impact is that an attacker can cause a string to reach the logger, that when processed by Log4J, executes arbitrary code. The first examples of this used the ${jndi:ldap} path, which could lead to arbitrary code being loaded from a remote URL. This path is partially mitigated by the use of newer Java runtimes that block the URL-based class loader by default. Unfortunately, a modern version of Java may not be enough to prevent exploitation, as the application itself may expose classes that can be used to run arbitrary code.

The JNDI architecture:

Mitigations for Different environments:

Update - 17-Dec-2021

Security Vulnerability CVE-2021-45105

Details:

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default

Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains

a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

Mitigation:

From version 2.17.0 (for Java 8), only lookup strings in configuration are expanded recursively; in any other

usage, only the top-level lookup is resolved, and any nested lookups are not resolved.

In prior releases this issue can be mitigated by ensuring your logging configuration does the following:

In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId}or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).

Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Update - 13-Dec-2021

** Log4j(Release 2.16.0 – 2021-12-13) has two improved features :**

---------------!!Highly recomended to upgrade to available latest version since message lookups are disabled by default.!!------------

https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

Disable JNDI by default. Require log4j2.enableJndi to be set to true to allow JNDI.

Completely remove support for Message Lookups

New Update:

------------------CVE-2021-45046-----------------

Apache Log4j2 Thread Context Message Pattern and Context Lookup Pattern vulnerable to a denial of service attack.

Mitigation:

Log4j 1.x mitigation: Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation: Implement one of the mitigation techniques below.

Java 8 (or later) users should upgrade to release 2.16.0. Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).

Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

------------------CVE-2021-44228-------------------

Mitigation

Log4j 1.x mitigation: Log4j 1.x does not have Lookups so the risk is lower. Applications using Log4j 1.x are only vulnerable to this attack when they use JNDI in their

configuration. A separate CVE (CVE-2021-4104) has been filed for this vulnerability. To mitigate: audit your logging configuration to ensure it has no JMSAppender configured.

Log4j 1.x configurations without JMSAppender are not impacted by this vulnerability.

Log4j 2.x mitigation: Implement one of the mitigation techniques below.

Java 8 (or later) users should upgrade to release 2.16.0.

Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).

Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

 1. Apache Log4j:
        In releases >=2.10** and
        For releases >=2.0-beta9 and <=2.10.0
        
2. pom.xml Fix:
 
3. Azure App Service (Windows and Linux):
 
4. Any Containerized applications:
 
5. Azure Functions:

6. Hotpatch for Apache Log4j

7. How Defender for Cloud finds machines affected by Log4j vulnerabilities

8. Detection on Azure Sentinel and Azure WAF logs

9.Maven plug-in configuration for banning-log4j2 vulnerable versions in future builds

1. Apache Log4j:

CVE-2021-44228: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints.

Versions Affected: all log4j-core versions >=2.0-beta9 and <=2.14.1 Apache Log4j <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. 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.