weblogic漏洞属于什么类型

Weblogic漏洞不是漏洞单一类型，它横跨了反序列化、属于什类远程代码执行、漏洞SSRF、属于什类文件上传、漏洞权限绕过等多个类别。属于什类但如果你非要给一个最核心的漏洞归类，反序列化漏洞是属于什类Weblogic历史上最致命、影响最广的漏洞那一类。从CVE-2015-4852到CVE-2019-2725，属于什类再到CVE-2020-2551，漏洞这条线贯穿了Weblogic过去十年的属于什类安全噩梦。

为什么反序列化在Weblogic上这么严重？漏洞因为Weblogic的T3协议和IIOP协议天生就允许传输序列化对象。T3是属于什类Weblogic自研的通信协议，用于JNDI、漏洞EJB等远程调用。问题在于，T3协议在反序列化数据时，没有对输入做足够严格的校验。攻击者可以构造一个恶意序列化对象，通过T3端口（默认7001）发送给Weblogic，服务端反序列化时就会触发任意代码执行。这不需要认证，不需要用户交互，直接打。

2015年那个CVE-2015-4852，利用的是Commons Collections库。当时Java生态里大量应用都依赖这个库，Weblogic也不例外。攻击者用ysoserial工具生成一个Commons Collections链的payload，直接往T3端口一发，服务器就执行命令了。这个漏洞爆发后，Oracle紧急发了补丁，但补丁只是黑名单过滤，很快就被绕过。2017年的CVE-2017-3248，攻击者换了一条利用链，用JRMP协议绕过黑名单。2018年的CVE-2018-2628，又是T3反序列化，又是绕过补丁。这种猫鼠游戏反复上演，每次Oracle修完，安全研究员总能找到新的绕过方式。

2019年的CVE-2019-2725是个转折点。这个漏洞影响的是Weblogic的wls9-async组件，走的是HTTP协议，不是T3。攻击者通过访问一个特定的URL路径，发送XML格式的恶意请求，就能触发反序列化。这个漏洞的利用门槛更低，因为HTTP端口通常比T3端口更容易暴露在公网。当时FOFA和Shodan上能扫出大量暴露在外的Weblogic实例，漏洞公开后几天内，全球就有成千上万台服务器被挖矿木马入侵。

除了反序列化，Weblogic还有另一类高频漏洞：SSRF。CVE-2014-4210是个典型例子，UDDI组件存在SSRF，攻击者可以借助它探测内网。这类漏洞单独利用危害有限，但配合内网其他服务就能形成攻击链。还有文件上传漏洞，比如CVE-2018-2894，Weblogic的Web Service测试页面存在任意文件上传，攻击者上传JSP文件就能获取shell。权限绕过类漏洞也不少，CVE-2020-14882允许未授权访问控制台，再配合CVE-2020-14883就能实现远程代码执行。

从攻击面来看，Weblogic的漏洞主要集中在几个组件上：T3协议、IIOP协议、wls9-async、UDDI、控制台。T3和IIOP是重灾区，因为协议设计之初就没把安全放在首位。Oracle的补丁策略也值得吐槽，很多补丁只是临时封堵，没有从根本上解决反序列化的问题。比如T3协议，Oracle在补丁里增加了黑名单类过滤，但Java反序列化链千变万化，黑名单永远跟不上。后来Oracle干脆在较新版本里默认关闭了T3协议，或者要求T3必须认证，这才算从架构上缓解了问题。

实际应急响应中，我见过太多Weblogic被入侵的案例。有一台服务器被挖矿，排查发现攻击者通过T3反序列化上传了门罗币矿机。还有一次，攻击者利用CVE-2019-2725拿到了shell，然后在内网横向移动，最终控制了整个域环境。这些案例的共同点是：Weblogic版本老旧，补丁没打全，T3端口直接暴露在公网。很多运维人员根本不知道T3是什么，也不知道7001端口意味着什么。

如果你现在还在用Weblogic，第一件事是确认版本，第二件事是打补丁，第三件事是限制T3端口的访问。如果业务不需要T3，直接关掉。如果必须用，至少要在网络层做访问控制。别指望Oracle的补丁能一劳永逸，Weblogic的漏洞历史告诉我们，这个中间件的攻击面太宽了，任何一次疏忽都可能变成入侵入口。