thedevappsecguy/log4j-mitigation-cve-2021-44228--cve-2021-45046--cve-2021-45105--cve-2021-44832Log4J CVE-2021-44228 : Mitigation Cheat Sheet
更新 - 2021年12月28日
CVE-2021-44832：当攻击者控制配置时，Apache Log4j2 通过 JDBC Appender 易受 RCE 攻击。
已在 Log4j 2.17.1 (Java 8)、2.12.4 (Java 7) 和 2.3.2 (Java 6) 中修复
更新 - 2021年12月17日
昨夜，Apache 披露 Log4j 版本 2.16 也存在拒绝服务攻击的安全漏洞，影响是应用程序完全崩溃，严重程度被归类为高 (7.5)。已发布 CVE-2021-45105，Apache 已发布新修复版本 (2.17)，建议升级。
背景：
互联网讨论热议 Apache 流行的 Java 日志库 Log4J 中的一个 0-day 漏洞（可能导致远程代码执行）。此漏洞被追踪为 CVE-2021-44228，CVSS 评分最高为“严重”10 分，存在于 Log4J 的查找功能与 JNDI（Java 命名和目录接口）结合中。此问题影响广泛，因为许多开发人员不知道 Log4J 与未经过滤的输入一起使用是危险的。
最严重的影响是，攻击者可以使字符串到达日志记录器，当 Log4J 处理该字符串时，会执行任意代码。最初的示例使用了 ${jndi:ldap} 路径，这可能导致从远程 URL 加载任意代码。较新版本的 Java 运行时默认阻止基于 URL 的类加载器，可以部分缓解此路径。然而，由于应用程序本身可能暴露可用于执行任意代码的类，因此现代 Java 版本可能不足以阻止漏洞利用。
JNDI 架构：
不同环境的缓解措施：
更新 - 2021年12月17日
安全漏洞 CVE-2021-45105
详情：
Apache Log4j2 版本 2.0-alpha1 至 2.16.0 未针对自引用查找导致的不可控递归提供保护。当日志配置使用非默认的 Pattern Layout 并包含 Context Lookup（例如 $${ctx:loginId}）时，攻击者若能够控制 Thread Context Map (MDC) 输入数据，则可以构造包含递归查找的恶意输入数据，导致 StackOverflowError 并终止进程。这也被称为 DOS（拒绝服务）攻击。
缓解措施：
从版本 2.17.0（适用于 Java 8）开始，只有配置中的查找字符串会递归展开；在其他任何用法中，仅解析顶级查找，嵌套查找不会被解析。
在先前版本中，可以通过确保日志配置执行以下操作来缓解此问题：
在日志配置的 PatternLayout 中，将 Context Lookups（如 ${ctx:loginId} 或 $${ctx:loginId}）替换为 Thread Context Map 模式（%X、%mdc 或 %MDC）。
否则，在配置中删除对 Context Lookups（如 ${ctx:loginId} 或 $${ctx:loginId}）的引用，前提是这些引用源自应用程序外部的来源，例如 HTTP 标头或用户输入。
更新 - 2021年12月13日
** Log4j (发布 2.16.0 – 2021-12-13) 具有两项改进特性：**
---------------!!强烈建议升级到可用最新版本，因为消息查找默认处于禁用状态。!!------------
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
默认禁用 JNDI。需要将 log4j2.enableJndi 设置为 true 以允许 JNDI。
完全移除了对消息查找的支持
新更新：
------------------CVE-2021-45046-----------------
Apache Log4j2 Thread Context Message Pattern 和 Context Lookup Pattern 易受拒绝服务攻击。
缓解措施：
Log4j 1.x 缓解措施：Log4j 1.x 不受此漏洞影响。
Log4j 2.x 缓解措施：实施以下缓解技术之一。
Java 8（或更高版本）用户应升级到 2.16.0 版本。 需要 Java 7 的用户应升级到 2.12.2 版本（当它可用时，正在进行中，预计很快可用）。
否则，从类路径中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
请注意，只有 log4j-core JAR 文件受此漏洞影响。仅使用 log4j-api JAR 文件而未使用 log4j-core JAR 文件的应用程序不受此漏洞影响。
------------------CVE-2021-44228-------------------
缓解措施
Log4j 1.x 缓解措施：Log4j 1.x 没有查找功能，因此风险较低。使用 Log4j 1.x 的应用程序仅在配置中使用 JNDI 时容易受到此攻击。已为此漏洞提交单独的 CVE（CVE-2021-4104）。缓解措施：审计日志配置，确保没有配置 JMSAppender。
没有 JMSAppender 的 Log4j 1.x 配置不受此漏洞影响。
Log4j 2.x 缓解措施：实施以下缓解技术之一。
Java 8（或更高版本）用户应升级到 2.16.0 版本。
需要 Java 7 的用户应升级到 2.12.2 版本（当它可用时，正在进行中，预计很快可用）。
否则，从类路径中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
请注意，只有 log4j-core JAR 文件受此漏洞影响。仅使用 log4j-api JAR 文件而未使用 log4j-core JAR 文件的应用程序不受此漏洞影响。
1. Apache Log4j：
在版本 >=2.10** 中以及
对于版本 >=2.0-beta9 且 <=2.10.0
2. pom.xml 修复：
3. Azure App Service (Windows 和 Linux)：
4. 任何容器化应用程序：
5. Azure Functions：
6. Apache Log4j 热补丁
7. Defender for Cloud 如何查找受 Log4j 漏洞影响的机器
8. Azure Sentinel 和 Azure WAF 日志检测
9. 用于在未来构建中禁止 Log4j2 易受攻击版本的 Maven 插件配置
1. Apache Log4j：
CVE-2021-44228：Apache Log4j2 JNDI 功能未针对攻击者控制的 LDAP 和其他 JNDI 相关端点提供保护。
受影响版本：所有 log4j-core 版本 >=2.0-beta9 且 <=2.14.1 Apache Log4j <=2.14.1 中用于配置、日志消息和参数的 JNDI 功能未针对攻击者控制的 LDAP 和其他 JNDI 相关端点提供保护。当消息查找替换启用时，能够控制日志消息或日志消息参数的攻击者可以执行从 LDAP 服务器加载的任意代码。从 Log4j 2.15.0 开始，此行为默认禁用。
在版本 >=2.10 中，可以通过设置系统属性 log4j2.formatMsgNoLookups 或 环境变量 LOG4J_FORMAT_MSG_NO_LOOKUPS 为 true 来缓解此行为。对于版本 >=2.7 且 <=2.14.1，可以修改所有 PatternLayout 模式，将消息转换器指定为 %m{nolookups} 而不是仅使用 %m。
对于版本 >=2.0-beta9 且 <=2.10.0，缓解措施是从类路径中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class。
2.pom.xml 修复：
更新 pom.xml 中的依赖项，并将依赖项部分替换为可用最新版本： 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>
<!-- 替换为以下内容以证明已修复 -->
<!-- <version>2.17.0</version>-->
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.14.1</version>
<!-- 替换为以下内容以证明已修复 -->
<!-- <version>2.17.0</version>-->
</dependency>
</dependencies>
参考：https://github.com/justincormack/log4jpoc/blob/main/pom.xml#L18
3.Azure App Service (Windows 和 Linux)：
如果可能，客户应升级 Log4j 到 v2.15.0 并重新部署应用程序。这是推荐的缓解措施。如果您无法重新部署应用程序，在 Log4j 版本 2.10 及更高版本中，可以通过设置系统属性 “-Dlog4j2.formatMsgNoLookups=true” 来缓解此行为。在 App Service 上，可以通过创建名为 JAVA_OPTS 的应用设置，值为 “-Dlog4j2.formatMsgNoLookups=true” 来设置此属性。JAVA_OPTS 应用设置会在 Java 应用程序启动时传递给该应用程序。如果您已经设置了 JAVA_OPTS 应用设置，只需将 “-Dlog4j2.formatMsgNoLookups=true” 追加到现有值即可。如果您使用的是 Log4J 版本 2.9 或更低版本，此系统属性缓解措施不起作用，您应升级到 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.任何容器化应用程序
对于容器化应用程序，如果您使用的 Log4j 2 版本是 2.10.0 或更高版本，可以使用环境变量或 Java 命令行选项来禁用不安全的替换行为。您可以添加以下行：
ENV LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Docker 文件参考： https://github.com/lhotari/Log4Shell-mitigation-Dockerfile-overlay/blob/master/Dockerfile
或者，您可以添加等效标志 "-Dlog4j.formatMsgNoLookups=true" 到您在容器中运行的命令中，例如：
CMD ["java", "-Dlog4j.formatMsgNoLookups=true", "-jar", "..."]
您还可以在运行时配置环境变量，这更简单，例如对于 Kubernetes，您可以将以下行添加到配置中。
spec:
containers:
- name: ...
image: ...
env:
- name: LOG4J_FORMAT_MSG_NO_LOOKUPS
value: "true"
5.Azure Functions：
配置系统属性取决于您选择的托管选项：专用、高级或按需。再次提醒，推荐的缓解措施是升级 Log4J 到 2.15.0 并重新部署应用程序。如果由于某种原因无法这样做，则可以应用系统属性。
- 专用和高级 Functions：
创建名为 JAVA_OPTS 的应用设置，值为 “-Dlog4j2.formatMsgNoLookups=true”。如果您已经设置了 JAVA_OPTS 应用设置，只需将 “-Dlog4j2.formatMsgNoLookups=true” 追加到现有值。
- 按需 Functions：
Linux：创建名为 “languageWorkers__java__arguments” 的应用设置，值为 “-Dlog4j2.formatMsgNoLookups=true”。 Windows：创建名为 “languageWorkers:java:arguments” 的应用设置，值为 “-Dlog4j2.formatMsgNoLookups=true”。 **注意：更新应用设置将重新启动您的 Web 和 Function 应用，这可能会影响冷启动性能。如果您使用的是 Log4J 版本 2.9 或更低版本，此系统属性缓解措施不起作用，您应升级到 v2.15.0。
6.Apache Log4j 热补丁
如何工作？
此工具将 Java agent 注入到正在运行的 JVM 进程中。该 agent 尝试修补所有已加载的 org.apache.logging.log4j.core.lookup.JndiLookup 实例的 lookup() 方法，使其无条件返回字符串 “Patched JndiLookup::lookup()”。这旨在解决 Log4j 中的 CVE-2021-44228 远程代码执行漏洞，而无需重新启动 Java 进程。
如果您有可能重新部署 Java 进程，也可以将其用作静态 agent，这意味着您可以在运行时包含此补丁，而无需直接登录到您的服务器。
Github ： https://github.com/corretto/hotpatch-for-apache-log4j2
7.Defender for Cloud 如何查找受 Log4j 漏洞影响的机器
通过清单功能，您有两种强大的方法来确定您的暴露情况：
软件清单
漏洞评估发现
8.Azure Sentinel 和 WAF 日志检测：
Azure WAF Log4j CVE-2021-44228 搜寻
Azure WAF 匹配 Log4j 漏洞 (CVE-2021-44228)
9.用于在未来构建中禁止 Log4j2 易受攻击版本的 Maven 插件配置：
Maven 插件配置，放入您的父 POM 中，以避免使用任何过时的 log4j2 版本，其中一些版本受 RCE CVE-2021-44228 ("Log4Shell")、CVE-2021-45046 和 CVE-2021-45105 影响。
参考：https://gist.github.com/gunnarmorling/8026d004776313ebfc65674202134e6d
<!-- 插件配置，放入您的父 POM 中，以避免使用任何
过时的 log4j2 版本，其中一些版本受 RCE CVE-2021-44228
("Log4Shell")、CVE-2021-45046 和 CVE-2021-45105 影响。请确保检查
log4j2 的最新版本，网址为
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>
...
贡献：
欢迎社区的贡献。贡献指南：
-->请提交 PR。
-->请务必包含参考来源以提供更多上下文
可能有几种不同的环境和修复方法，请随时打开拉取请求：
参考：
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/