WebLogic漏洞复现（2）-T3协议反序列化
WebLogic漏洞复现（2）-T3协议反序列化
参考：
- https://www.freebuf.com/vuls/364212.html
- https://blog.csdn.net/m0_51330619/article/details/120254124
- https://mp.weixin.qq.com/s?__biz=MzU5NDgxODU1MQ==&mid=2247485058&idx=1&sn=d22b310acf703a32d938a7087c8e8704
背景知识
在复现之前先搞清楚 Java 安全常见的几个概念：
| 名词 | 概念 |
|---|---|
| JNDI | Java 命名和目录接口（Java Naming and Directory Interface），提供统一 API 访问多种命名服务（RMI、LDAP、DNS 等）。通过 lookup() 按名称查找资源，实现应用与资源之间的解耦。 |
| LDAP | 轻量级目录访问协议（Lightweight Directory Access Protocol），采用树状目录结构存储数据，用于用户认证、权限管理和资源查询。属于跨平台标准协议，默认端口 389（加密连接为 636）。 |
| RMI | Java 原生远程方法调用机制（Remote Method Invocation），允许不同 JVM 之间像本地方法一样调用远程对象，通过 Stub/Skeleton 实现透明通信，默认使用 JRMP 协议，常见注册端口为 1099。 |
| JRMP | Java 远程方法协议（Java Remote Method Protocol），是 RMI 的底层通信协议，定义客户端与服务端之间的通信格式和数据传输规范。基于 TCP/IP，仅支持 Java 到 Java 的通信，并负责对象序列化传输。 |
| T3 | Oracle WebLogic 专有二进制协议，基于 JRMP 扩展设计，用于 WebLogic 集群节点通信、EJB 远程调用以及 JNDI 服务查找，默认端口 7001。 |
在 Java 安全中有一种经典利用手段就是 JNDI 注入，如 fastjson、log4j 都爆出来过，JNDI 注入的核心就是：用户可控输入 → JNDI.lookup() → 恶意协议服务 → 加载远程类 → 执行恶意代码。
关于T3协议
T3 协议是 WebLogic 应用服务器的私有传输协议，承载其 RMI 服务通信，由于直接信任并反序列化客户端传入的 Java 对象数据且无安全校验，存在严重的反序列化 RCE 风险。
总结爆出来的 T3 反序列化漏洞可分为下面两类：
一、JNDI注入类
利用反序列化触发 JNDI.lookup()，使目标主动连接攻击者的 LDAP/RMI 服务器，下载并加载恶意类执行命令。代表漏洞：CVE-2017-3248、CVE-2023-21839。特点：需目标能外连，JDK 8u191+ 后限制远程类加载，利用难度增加。
二、纯反序列化RCE类
利用 Gadget 链（如 CC 库或 WebLogic 内部类）在反序列化过程中直接触发 Runtime.exec() 执行命令，无需外连。代表漏洞：CVE-2015-4852、CVE-2017-10271、CVE-2018-2893。特点：本地执行不受 JDK JNDI 限制，但依赖目标存在特定类，可通过类黑名单修复。
Weblogic WLS Core Components 反序列化RCE（CVE-2018-2628）
受影响的版本：
- 10.3.6.0
- 12.1.3.0
- 12.2.1.2
- 12.2.1.3
漏洞原理：CVE-2018-2628 是 Oracle WebLogic Server WLS Core Components 组件中存在的一个高危反序列化漏洞，攻击者无需身份认证即可通过 T3 或 IIOP 协议向服务器发送精心构造的恶意序列化数据，利用 weblogic.wsee.service.WorkListService 等类在反解析过程中实例化任意对象链（Gadget Chain），从而在目标服务器上执行任意系统命令，导致服务器被完全接管。
环境搭建
依旧是 vulhub 起 docker 就行：
漏洞利用
攻击者首先启动恶意 JRMP 监听器等待连接，随后向目标 WebLogic 的 T3 端口发送包含远程引用（指向攻击者监听地址）的序列化数据包，诱导目标服务器主动回连攻击者，攻击者借此机会下发真正的恶意利用链载荷，目标在二次反序列化过程中最终执行预设的系统命令。
先启动 JRMP 监听：
1 | |
ysoserial.jar 我的版本是比较新的，不同版本有不同的利用差异：
然后利用 exploit.py 脚本，向目标 WebLogic（http://your-ip:7001）发送数据包（注意用 python2）：
1 | |
看 JRMP 回显已经连接上了：
最终利用成功：
WebLogic CVE-2023-21839
受影响的版本：
- 12.2.1.3.0
- 12.2.1.4.0
- 14.1.1.0.0
漏洞原理：WebLogic CVE-2023-21839 是一个高危的远程代码执行（RCE）漏洞，其核心原理在于 WebLogic Server 在处理 T3/IIOP 协议请求时，对 JNDI 查找操作缺乏足够的安全验证。攻击者可以通过构造恶意的 T3/IIOP 数据包，诱导服务器向攻击者控制的恶意 JNDI 服务（如 LDAP 或 RMI）发起 lookup 请求；由于 WebLogic 内部类（如 ForeignOpaqueReference）在反序列化或解析远程对象引用时存在逻辑缺陷，服务器会加载并执行恶意服务返回的恶意字节码，从而在未经身份验证的情况下实现远程命令执行，导致服务器被完全接管。
环境搭建
漏洞利用
DNSLog 探测
通过 T3 协议向目标服务器发送构造恶意的 ForeignOpaqueReference 对象，诱导其在服务端执行 JNDI 查找并主动连接攻击者指定的 LDAP 地址；由于该 LDAP 地址指向一个由 DNSLog 平台生成的唯一子域名，一旦目标服务器尝试解析该域名，攻击者控制的 DNS 服务器便会记录下查询请求。
exp 链接：https://github.com/DXask88MA/Weblogic-CVE-2023-21839
运行以下命令：
1 | |
探测成功，确认漏洞存在。
反弹Shell
在网上找了一些 JNDI 注入的 jar 不太会用，后面找项目自己编译了一个。
项目地址：https://github.com/zzwlpx/JNDIExploit
先在 vps2 上启动一个 LDAP 服务：
1 | |
vps2 还需要开启监听：
1 | |
然后用 vps1 执行攻击操作：
1 | |
此时查看 LDAP 服务器，成功反弹 shell：
反弹 shell 成功：
WebLogic反序列化漏洞（CVE-2021-2394）
受影响的版本：
- Oracle WebLogic Server 12.2.1.3.0
- Oracle WebLogic Server 12.2.1.4.0
- Oracle WebLogic Server 14.1.1.0.0
漏洞原理：CVE-2021-2394 是一个 WebLogic IIOP 协议下的反序列化远程代码执行漏洞，其核心原理是攻击者利用未被列入黑名单的 FilterExtractor 和 SerializationHelper 类构建利用链，在反序列化过程中通过 SerializationHelper.readAttributeAccessor 方法触发二次反序列化，从而绕过官方针对前序漏洞（如 CVE-2020-14825）设置的类过滤机制，最终导致恶意对象（如 JNDI 注入或命令执行链）被加载并执行任意代码。
环境搭建
可以沿用上一个漏洞环境。
漏洞利用
其实漏洞利用的手法比较相似，都需要起一个 LDAP 用于靶机远程加载。
在 vps 上起一个 LDAP 服务：
1 | |
然后监听 7777 端口：
1 | |
最后利用现有的 POC 进行攻击发包（POC 地址：https://github.com/lz2y/CVE-2021-2394/releases/tag/2.0）：
1 | |
最终利用成功：
