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
Otherwise, in the configuration, remove references to Context Lookups like
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.
In releases >=2.10**, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true
. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
.
2.pom.xml Fix:
Update the dependency in pom.xml and swap with the latest available version in the dependencies section : https://search.maven.org/artifact/org.apache.logging.log4j/log4j/2.15.0/pom
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<!-- Swap with the below to prove it's fixed -->
<!-- <version>2.17.0</version>-->
</dependency>
</dependencies>
Reference: https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18
3.Azure App Service (Windows and Linux):
If possible, customers should upgrade Log4j to version v2.15.0 and re-deploy applications. This is the primary recommended mitigation. If you are not able to re-deploy your application, then in Log4j versions 2.10 and greater, you can mitigate this behavior by setting the system property “-Dlog4j2.formatMsgNoLookups=true”. On App Service, you can set this property by creating an app setting named JAVA_OPTS with a value of “-Dlog4j2.formatMsgNoLookups=true”. The JAVA_OPTS app setting is passed to your Java application as it starts. If you already have the JAVA_OPTS app setting set, just append “-Dlog4j2.formatMsgNoLookups=true” to the existing value. If you are using Log4J version 2.9 or lower, this system property mitigation will not work and you should upgrade to v2.15.0.
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings <setting-name>="<value>"
az webapp config appsettings set --name <app-name> --resource-group <resource-group-name> --settings JAVA_OPTS="-Dlog4j2.formatMsgNoLookups=true"
4.Any Containerized applications
-
For containerized applications, if the version of Log4j 2 you are using is 2.10.0 or later, there is an environment variable or Java command line option you can use to disable the unsafe substitution behavior. You can add the line:
ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Docker file reference: https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
-
To your Dockerfile, or you can add the equivalent flag "-Dlog4j.formatMsgNoLookups=true"to the command you run in your container, for example:
CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
-
You can also configure the environment variable at runtime, which can be easier, for example for Kubernetes you could add these lines into your configuration.
spec: containers: - name: ... image: ... env: - name: LOG4J_FORMAT_MSG_NO_LOOKUPS value: "true"
5.Azure Functions:
Configuring the system property will depend on your choice of hosting option: dedicated, premium or consumption. As a reminder, the primary recommended mitigation is upgrading Log4J to 2.15.0 and re-deploying your application. If you cannot do that for whatever reason, then you can apply the system property.
- Dedicated and Premium Functions:
Create an app setting named JAVA_OPTS with a value of “-Dlog4j2.formatMsgNoLookups=true”. If you already have the JAVA_OPTS app setting set, just append “-Dlog4j2.formatMsgNoLookups=true” to the existing value.
- Consumption Functions:
Linux: Create an app setting named “languageWorkers__java__arguments” with a value of “-Dlog4j2.formatMsgNoLookups=true”. Windows: Create an app setting named “languageWorkers:java:arguments” with a value of “-Dlog4j2.formatMsgNoLookups=true”. **Note that updating app setting will restart your Web and Function apps, which could affect cold start performance. If you are using Log4J version 2.9 or lower, this system property mitigation will not work and you should upgrade to v2.15.0.
6.Hotpatch for Apache Log4j
How does it work? This tool injects a Java agent into a running JVM process. The agent attempts to patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string “Patched JndiLookup::lookup()”. This is designed to address the CVE-2021-44228 remote code execution vulnerability in Log4j without restarting the Java process.
If you have the possibility of redeploying your Java processes, you can also use it as a static agent, meaning that you can include this patch in your runtime without directly logging in to your servers.
Github : https://github.com/corretto/hotpatch-for-apache-log4j2
7.How Defender for Cloud finds machines affected by Log4j vulnerabilities
Using inventory, you have two powerful ways to determine your exposure:
Software inventory
Vulnerability assessment findings
8.Detection on Azure Sentinel and WAF logs:
Azure WAF Log4j CVE-2021-44228 hunting
Azure WAF matching for Log4j vuln(CVE-2021-44228)
9.Maven plug-in configuration for banning-log4j2 vulnerable versions in future builds:
Maven plug-in configuration to put into your parent POM for avoiding any usages of outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
("Log4Shell"), CVE-2021-45046, and CVE-2021-45105).
Reference: https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
<!-- plug-in configuration to put into your parent POM for avoiding any usages of
outdated log4j2 versions, some of which are subject to the RCE CVE-2021-44228
("Log4Shell"), CVE-2021-45046, and CVE-2021-45105. Make sure to check for the
latest version of log4j2 at
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
...
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-enforcer-plugin</artifactId>
<version>3.0.0</version>
<executions>
<execution>
<id>ban-bad-log4j-versions</id>
<phase>validate</phase>
<goals>
<goal>enforce</goal>
</goals>
<configuration>
<rules>
<bannedDependencies>
<excludes>
<exclude>org.apache.logging.log4j:log4j-core:(,2.17.0)</exclude>
</excludes>
</bannedDependencies>
</rules>
<fail>true</fail>
</configuration>
</execution>
</executions>
</plugin>
...
Contributing:
Happy to recieve contributions from the community. Contribution guidelines:
-->Please make a PR.
-->Please be sure to include a reference source for more context
There may be several different environments and other ways to fix ,feel free to open a pull request :
References:
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
https://github.com/justincormack/log4jpoc
https://www.rumble.run/blog/finding-log4j/
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay
https://docs.oracle.com/javase/jndi/tutorial/getStarted/overview/index.html
https://logging.apache.org/log4j/2.x/security.html
https://aws.amazon.com/blogs/opensource/hotpatch-for-apache-log4j/