Log4j严重漏洞修最新修复⽅案参考
CVE-2021-44228，原理上是 log4j-core 代码中的 JNDI 注⼊漏洞。这个漏洞可以直接导致服务器被⼊侵，⽽且由于“⽇志”场景的特性，攻击数据可以多层传导，甚⾄可以威胁到纯内⽹的服务器。log4j 作为 Java 开发的基础公共⽇志类，使⽤范围⾮常⼴，漏洞必定影响深远，想想当年commons-collections反序列化漏洞的影响范围。
Github漏洞公告：
github/advisories/GHSA-jfh8-c2jp-5v3q
影响 < 2.15.0 的所有 2.x 版本。也就是说，除了最新版本之外的所有版本都受影响。
最直接、有效、稳定的修复⽅式是：将 log4j-core 升级到 2.15.0 版本
最直接、有效、稳定的修复⽅式是：将 log4j-core 升级到 2.15.0 版本
最直接、有效、稳定的修复⽅式是：将 log4j-core 升级到 2.15.0 版本
如果实在⽆法升级，可以尝试把漏洞类删掉。其他修复⽅式可以结合使⽤起到⽐较好的快速缓解作⽤，
但受限于不同的环境，可能会产⽣各种各样⽐较⿇烦的问题或者未来的隐患。长期修复⽅案需要保证稳定、可靠、持久有效，这种严重漏洞值得⼀个发布和重启。
2.15.0 版本下载地址：
repo./maven2/org/apache/logging/log4j/log4j-core/2.15.0/
1<dependency>
2 <groupId>org.apache.logging.log4j</groupId>
3 <artifactId>log4j-core</artifactId>
4 <version>2.15.0</version>
5</dependency>
缓解⽅式1：接⼊安全产品
第⼀时间上WAF规则、RASP拦截等措施，给修复争取时间。
但是也要注意⼀些静态规则上的绕过，log4j ⽀持的写法⽐较多，有⾮常多绕过姿势。⽐如：
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}:///poc}
缓解⽅式2：删除漏洞类
通过删除漏洞类进⾏修复的⽅案⽐较稳，也是官⽅推荐的⼀种修复⽅案。直接删除 log4j jar 包中存在漏洞的类：
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
这种修复⽐较⽅便快捷，⼀般业务代码也不会⽤到 jndi lookup 这个功能。不过可能会对基于版本号判定的安全数据采集造成⼀定困扰，⽆法准确统计漏洞的最新受影响情况。建议删除之后在 jar 包后⾯加上⼀定的标记，如： log4j-2.14.1.sec.jar
另外，由于某些原因不想删除的话，可以⾃⼰代码替换原始的 JndiLookup 类，将它加到业务代码中。需要注意的是，必须保证它在 log4j 原类之前加载。
1package org.apache.lookup;
2
3public class JndiLookup {
4 public JndiLookup() {
5 throw new NoClassDefFoundError("JNDI lookup is disabled");
6 }
7}
也可以做成依赖包，在 log4j-core 之前添加，可以实现同样的效果（注意不要引⼊不可信的第三⽅依赖，可能导致潜在安全风险，以下配置来源互联⽹，仅作为⽰例，请勿直接使⽤）：
1<dependency>
2 <groupId>org.glavo</groupId>
3 <artifactId>log4j-patch</artifactId>
4 <version>1.0</version>
5</dependency>
当然也可以通过RASP的⽅式⼲掉漏洞类，Github上有不少RASP的⽆损修复⽅案，⽐如：
github/chaitin/log4j2-vaccine
github/boundaryx/cloudrasp-log4j2
缓解⽅式3：通过配置禁⽤ log4j 的 lookup 功能
禁⽤的⽅式就⽐较多了。然⽽下⾯2、3、4这⼏种⽅式对低于 2.10 版本的 log4j-core 都没有效果，⽽且环境变量和启动参数这种设置，在迁移或者变更的过程中丢失的可能性⽐较⼤。log4j 在 2.15.0 版本中默认就已经关闭了 lookup 功能。
log4j2ponent.properties、l 默认放在 ClassPath 路径下，如：源代码的资源⽬录或者可执⾏程序所在的当前⽬录。1. 设置⽇志输出 Pattern 格式
对于 >=2.7 的版本，在 log4j 中对每⼀个⽇志输出格式进⾏修改。在 %msg 占位符后⾯添加 {nolookups}，这种⽅式的适⽤范围⽐其他三种配置更⼴。⽐如在 l 中配置：
apachelog4j2漏洞1<?xml version="1.0" encoding="UTF-8"?>
2<Configuration status="WARN">
3 <Appenders>
4 <Console name="Console" target="SYSTEM_OUT">
5 <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg{nolookups}%n"/>
6 </Console>
7 </Appenders>
8 <Loggers>
9 <Root level="error">
10 <AppenderRef ref="Console"/>
11 </Root>
12 </Loggers>
13</Configuration>
1public class Test {
2 public static void main(String[] args) {
3 String t = "${jndi:ldap://xxx/xxx}";
4 Logger logger = Logger(LogManager.ROOT_LOGGER_NAME);
5 (t);
6 }
7}
2. 设置JVM系统属性
在 Java 应⽤启动参数中增加
-Dlog4j2.formatMsgNoLookups=true，或者在业务代码中设置系统属性：
1// 必须在 log4j 实例化之前设置该系统属性
2System.setProperty("log4j2.formatMsgNoLookups", "true");
3
4Logger logger = Logger(LogManager.ROOT_LOGGER_NAME);
3. 修改配置⽂件
在配置⽂件
log4j2ponent.properties 中增加：log4j2.formatMsgNoLookups=true，配置⽂件放置于应⽤程序的 ClassPath 路径下。4. 设置进程环境变量
在环境变量中增加：
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
注意！这些配置和属性，并不能在所有场景下⽣效，⽐如在 logstash 中就⽆法⽣效： Solutions and Mitigations: The
widespread flag -Dlog4j2.formatMsgNoLookups=true does NOT mitigate the vulnerability in Logstas
h, as Logstash uses Log4j in a way where the flag has no effect. It is therefore necessary to remove the JndiLookup class from the log4j2 core jar, with the following command:
zip -q -d /logstash-core/lib/jars/log4j-core-2.* org/apache/logging/log4j/core/lookup/JndiLookup.class
Refer: /t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476
缓解⽅式4：升级JDK版本
对于Oracle JDK 11.0.1、8u191、7u201、6u211或者更⾼版本的JDK来说，默认就已经禁⽤了 RMI Reference、LDAP Reference 的远程加载。对于 RCE 来说，可以起到很直接的缓解作⽤，可以作为增强型的加固⽅案。
在⾼版本JDK环境下，JNDI注⼊也还是存在⼀定RCE风险，可以参考这篇⽂章：
/Restrictions-and-Bypass-of-JNDI-Manipulations-RCE.html
另外 log4j 漏洞本⾝除了 RCE，还存在着巨⼤的攻击⾯，⽐如 SSRF、敏感信息泄露等等，威胁⾮常⼤，不要企图仅仅通过升级JDK版本来修复漏洞，建议还是⽼⽼实实升级。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论