HashRun安全团队大量收人中(只限新疆本地)
本文由HashRun安全团队_APT小组编写
微信公众号:渊龙Sec安全团队
为国之安全而奋斗,为信息安全而发声!
如有问题或建议,请公众号留言
如果你觉得本文对你有帮助,欢迎在文章底部赞赏我们
前情提要
12月9日夜,这个漏洞突然得到广泛关注,从中国时间12月10日凌晨开始,各大安全厂家甚至在凌晨1、2点“起床”进行应急响应和修复,这是迄今为止绝无仅有的!
修复之前受影响的厂商有:
Apache,百度,滴滴,京东,腾讯,NSA,谷歌,苹果, Steam,推特,网易,亚马逊,特斯拉,领英,CloudFlare,IBM,VMWare,ghidra,UniFi,Elastic,PaloAlto,Blender,Webex,Minecraft 等等等等,简直数不胜数
漏洞概述
Apache Log4j是一个基于Java的日志记录组件。
该日志组件被广泛应用于业务系统开发,用以记录程序输入输出日志信息。大多数情况下,开发者可能会将用户输入导致的错误信息写入日志中。Log4j是属于Java的基本组件,只要使用Java,基本上都会受到该漏洞影响!
2021年11月24日,阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。
网址:https://logging.apache.org/log4j/2.x/security.html
由于Log4j2组件在处理程序日志记录时存在JNDI注入缺陷,未经授权的攻击者利用该漏洞,可向目标服务器发送精心构造的恶意数据,触发Log4j2组件解析缺陷,实现目标服务器的任意代码执行,获得目标服务器权限。
漏洞详情
Log4j 远程代码执行漏洞
-
漏洞编号:CVE-2021-44228
-
漏洞危害:高危、远程代码执行
-
公开程度:漏洞细节已公开
-
利用条件:无权限要求
-
交互要求:0 click
-
CVSS评分:10(最高级)
由于Apache Log4j2某些功能存在递归解析功能,攻击者可直接构造恶意请求,触发远程代码执行漏洞。漏洞利用无需特殊配置
漏洞影响版本:
Apache log4j2 2.0 - 2.14.1 版本均受影响!
可能的受影响应用包括但不限于如下:
Log4j2 + ?= RCE !
-
Spring-Boot-strater-log4j2
-
Apache Struts2
-
Apache Solr
-
Apache Flink
-
Apache Druid
-
ElasticSearch
-
flume
-
dubbo
-
Redis
-
logstash
-
kafka
-
ghidra
-
Spring-Boot-strater-log4j2
-
我的世界(Minecraft)
-
VMware系列
漏洞自查
-
相关用户可根据jar解压后是否存在”org/apache/logging/log4j“相关路径结构,判断是否使用了存在漏洞的组件,若存在相关Java程序包,则很可能存在该漏洞
-
检查本地应用是否存在log4j组件,若存在,可通过查看log4j-core包或log4j-api包中pom.xml查看具体使用版本,若版本号为小于2.15.0,则存在该漏洞。
漏洞复现
首先准备好我们的恶意类
打开我们的受害程序,这里使用Minecraft spigot 1.17.1服务端
使用娣呴洦澶х铔�(这块是payload)程序打开我们的代理并引导我们的程序加载目标类
用python的http.server模块来给我们的程序提供恶意类
代码分析
根据spigot在卡死时提供的stack trace,我们能够很清楚地查找问题出在哪
首先呢我们来到logger.processLogEvent方法
这里发现predicate.allow会调用callAppenders方法,也就是把${}这类字符串进行魔改
然后log已经提前备好了LoggerConfigPredicate.ALL作为predicate来调用
接下来我们看看ALL里写了什么
由此可见那个callAppenders一定会被调用,进入我们的下一步
然后在MessagePatternConverter#format中发现针对${字符串的解析
并进入到StrSubstitutor#replace进行解析
最终在其内部发现resolveVariable方法
resolveVariable方法内调用了resolver.lookup,而resolver被确定为Interpolator
在Interpolator中发现了针对jndi的解析
最终调用了JndiManager#lookup进行解析,进入漏洞触发流程
这里的lookup会调用java内部的lookup,触发漏洞。
漏洞修复方案
此处参考阿里云的官方修复方案
网上有一大堆互相抄来抄去的修复方案,很多甚至都是无效的,具体请看这篇文章:甲方需谨慎对待log4shell漏洞的修复
-
排查应用是否引入了Apache log4j-core Jar包,若存在依赖引入,且在受影响版本范围内,则可能存在漏洞影响。Apache官方已发布补丁,请尽快升级Apache Log4j2所有相关应用到最新的 log4j-2.15.0 版本
https://logging.apache.org/log4j/2.x/download.html
-
升级已知受影响的应用及组件,如 spring-boot-starter-log4j2/Apache Struts2/Apache Solr/Apache Druid/Apache Flink
-
临时缓解方案。可升级jdk版本至6u211 / 7u201 / 8u191 / 11.0.1以上,可以在一定程度上限制JNDI等漏洞利用方式。对于大于2.10版本的Log4j,可设置 log4j2.formatMsgNoLookups 为 True,或者将 JndiLookup 类从 classpath 中去除
总结
其实这种漏洞个人在主观上认为它不只是Apache log4j2的漏洞,更像是大批开发者犯了类似于格式化字符串的错误,包括mc, Apache Solr, Apache Flink, Apache Druid和srping-boot-strater-log4j2都犯下了类似的错误,应了那两句:编码不规范,报错两行类
我们团队内大多为高中和大学生组成
有意加入的小伙伴dd~
下方为HashRun团队公开群
原文始发于微信公众号(渊龙Sec安全团队):Log4j2 高危漏洞分析与总结
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论