- 当前位置：首页 > 休闲 > weblogic漏洞原理
游客发表
Weblogic漏洞原理
2017年圣诞节，漏洞有安全团队发现Oracle WebLogic的原理wls-wsat组件存在一个反序列化漏洞，攻击者构造一个SOAP请求就能在服务器上执行任意命令。漏洞三年后，原理CVE-2020-2551、漏洞CVE-2020-2555、原理CVE-2020-2883接连爆出，漏洞WebLogic成了企业内网里最容易被撕开的原理口子。这些漏洞背后，漏洞本质上都指向同一件事：WebLogic对序列化数据的原理信任过了头。
反序列化：把刀递给攻击者
Java序列化机制允许把对象转成字节流，漏洞方便网络传输或持久化。原理反序列化就是漏洞反过来，把字节流还原成对象。原理问题在于，漏洞如果这个字节流被攻击者控制，他可以在还原过程中触发任意类的构造函数、readObject方法、readResolve方法。WebLogic的T3协议、IIOP协议、XMLDecoder、wls-wsat组件，都直接或间接地接收外部序列化数据。
举个具体例子。T3协议是WebLogic用来和客户端通信的私有协议，默认监听7001端口。客户端发来的数据包经过反序列化处理，如果攻击者把恶意序列化数据塞进T3握手包，WebLogic会老老实实执行其中的readObject逻辑。2015年的CVE-2015-4852就是这么被打穿的——commons-collections库里的InvokerTransformer可以反射调用任意方法，攻击者用LazyMap链构造出Runtime.exec("rm -rf /")。
XMLDecoder：另一个入口
wls-wsat组件暴露的/bea_wls9_async_response/AsyncResponseService路径，接受SOAP请求。SOAP body里的XML被XMLDecoder解析，而XMLDecoder本身设计就允许通过
XMLDecoder的坑在于它太灵活了。开发者本意是方便配置，但没限制可实例化的类。Java的反射机制加上XMLDecoder的宽松策略，等于把执行命令的能力包装成了XML文本。
IIOP与Coherence
IIOP协议用于CORBA通信，WebLogic默认开启。攻击者通过IIOP发送序列化数据，触发反序列化。CVE-2020-2551就是IIOP协议下的反序列化漏洞，利用的是WebLogic自带的coherence.jar里的com.tangosol.util.extractor.ReflectionExtractor。这条链不需要额外的第三方库，只要目标WebLogic版本在受影响范围内，直接就能打。
Coherence组件的问题在于它为了方便分布式计算，允许通过序列化传输可执行代码。ReflectionExtractor能调用任意方法，组合成链后触发Runtime.exec。Oracle的补丁一开始只是黑名单过滤，攻击者换个类名就绕过了，后来才改成更严格的校验。
补丁与绕过：猫鼠游戏
Oracle的补丁策略通常是加黑名单，禁止反序列化某些危险类。但Java生态太庞大，gadget链层出不穷。2018年补丁禁了commons-collections的InvokerTransformer，攻击者就用commons-beanutils的BeanComparator。2020年补丁禁了ReflectionExtractor，攻击者又找到ToStringBean。每次补丁都像在漏水的桶上贴胶布。
更麻烦的是，WebLogic的补丁经常不完整。CVE-2020-2883补丁发布后，安全研究员很快发现可以用com.tangosol.util.extractor.MultiExtractor绕过。Oracle只好再发补丁。这种反复拉锯让运维人员很头疼——你永远不知道下一个绕过什么时候来。
为什么WebLogic总出问题
WebLogic的代码库太老了。很多组件是二十年前写的，那时候Java反序列化攻击还没成为主流。T3、IIOP、XMLDecoder这些功能设计时没考虑安全边界。Oracle又为了兼容性，不敢大刀阔斧地改。结果就是，每次安全研究员的注意力转回来，总能找到新入口。
企业里WebLogic通常跑在核心业务上，权限高、内网可达。一旦被反序列化打穿，攻击者直接拿到服务器权限，横向移动轻而易举。这也是为什么WebLogic漏洞在野利用一直很活跃——性价比太高了。
要防住，最直接的办法是别把WebLogic暴露在公网。T3协议可以关，IIOP可以禁，wls-wsat组件可以删。如果非要用，至少上WAF做序列化数据检测。但说到底，只要WebLogic还在用那些老组件，反序列化的根就还在。