修而未复：说说WebLogic那修不完的Java反序列化漏洞
编者说明：这篇文章初稿写在Oracle CPU补丁发布之后，考虑到文章内容的影响，并未在当时发布，WebLogic 的 Java 反序列化漏洞，已经修复了多次，最终的修复仍然未彻底解决问题。
背景
当地时间4月17日，北京时间4月18日凌晨，Oracle官方如约发布了4月份的关键补丁更新（Critical Patch Update，简称：CPU），其中包含一个高危的Weblogic反序列化漏洞CVE-2018-2628，该漏洞的危险分值更是达到了9.8分（最高10分）：
通过该漏洞，攻击者可以在未授权的情况下远程执行任意代码。
ps. 该漏洞由国内两位安全领域的专家xxlegend和loopx9 提交，前者还披露了该漏洞和补丁公布的时间线：
2017/07/19：发现问题 2017/11/23：报告给Oracle官方 2017/11/29：Oracle官方接收 2017/11/30：Oracle官方分配Bug号(S0947640)，正式进入主线版本修复 2017/11/30：索要公司域名邮箱 2018/04/14：分配CVE ID - CVE-2018-2628 2018/04/17：Oracle发布补丁
一石激起千层浪，国内的安全厂商-绿盟于4月18日发布了该漏洞的通告和修复方案，一些部委也于当天进行了跟进通知，相关人员也都行动起来了。
CVE-2018-2628漏洞POC测试
4月18日一大早看到了绿盟发的通知，里面有poc和exp的演示过程：
4月19日晚上，我们在一个阿里云ECS主机上新装了PSU-180417的WebLogic 10.3.6测试环境进行攻击模拟.
测试出来的结果真让人大跌眼镜，不过也在预料之中。
测试结果如下：
Oracle此次发布的CVE-2018-2628漏洞的补丁无效，无法彻底解决该利用方式。
Oracle发布的多个WebLogic反序列化漏洞补丁反复被绕过，这都源于Oracle当年修复CVE-2015-4852那个轰动一时的Java反序列化漏洞时采用的黑名单方式。
至此，基于Weblogic t3协议引起远程代码执行的反序列化漏洞全家福（年代久远的就不再考究了）：
CVE-2015-4852
CVE-2016-0638
CVE-2016-3510
CVE-2017-3248
CVE-2018-2628
从2015年一直修到2018年，反复修，反复被绕过，基于t3协议的Java反序列化漏洞还在继续。
基于wls-wsat服务组件的引起远程代码执行的反序列化漏洞：
CVE-2017-3506
CVE-2017-10271
2018年1月1日-3日大面积爆发的基于CVE-2017-10271的Java反序列化漏洞植入门罗币挖矿程序攻击的事件被大家所熟知，但很多人不知道的是，这个漏洞的前身是CVE-2017-3506，都是来源于wls-wsat 这个组件，攻击人员只是将用于CVE-2017-3506漏洞的exp脚本简单修改一下，就又能攻击利用了，才有了后来的CVE-2017-10271。
还有当年Oracle Tuxedo（银行业用户用的较多的一个交易中间件）10gR3版本GWTDOMAIN程序里一个函数的Bug，反复修复都没解决。
由此可见，近几年O记出的补丁有多不走心了！
CVE-2018-2628漏洞利用方式分析
从POC测试用例来看，CVE-2018-2628漏洞可被利用主要暴漏出了两方面的问题：
①基于WebLogic t3(s)、RMI/JRMP协议来执行存在反序列化漏洞的Java类的通道
该通道影响的WebLogic版本范围：
并非像文章第一节里面那个表格里公布的4个版本（10.3.6、12.1.3、12.2.1.2、12.2.1.3），只是这4个版本还在宽限期内，正常情况下，Oracle只对处在宽限期内的WebLogic版本提供补丁。
此漏洞实际影响的WebLogic版本范围（9.0及以后所有版本）：
从9.0（由于8.1等之前版本年代久远，这里不再提及）到最新的12.2.1.3（说好的12.2.1.4也跳票了？）一共20多个版本，无一例外，都受到影响，范围很大。
②存在反序列化漏洞的Java类（专业术语：Gadget，本次使用的JRE 7u21，像Commons Collections等Gadget已被当年啊针对CVE-2015-4852号漏洞的22248372补丁修复）
该Gadget影响的WebLogic版本范围：
使用了Java SE 6u45及之前Update、Java SE 7u21及之前Update版本的WebLogic Server环境（集中在WLS 10.3.0 - 12.1.3版本）。
JRE 7u21这个反序列化漏洞（Gadget）在Java SE 7u25 (2013-06-18)、Java SE 8(2014-03-18)及之后发布的Java SE/RE版本中修复。类似的Gadget还有Java SE 8u20.
此漏洞POC测试用例中用来生成Payload Object的方式有两种：
① JRMPClient2.class (Byusing java.rmi.activation.Activator)
② JRMPClient3.class (Wrapjava.rmi.registry.Registry in weblogic.jms.common.StreamMessageImpl)
其中第①种方式在网上较为多见，第②种方式只是有人提过。生成Payload Object的程序已在Github中开源（5月3日创建的Private项目，目前已设为Public），地址为：
https://github.com/tdy218/ysoserial-cve-2018-2628
修复方案
新的安全补丁不能解决CVE-2018-2628漏洞的问题，但解决这个问题有多种方式。
绿盟在4月18日发的有关此漏洞的安全通告中也给出了配置WebLogic NetworkConnection Filters的解决方案，但绿盟毕竟只是安全厂商，如果按照那个文章中提到的规则配置，可能会引发比这个Java反序列化漏洞更严重的问题（业务中断、监控中断、WebLogicServer之间的连接出错...）。
WebLogic NetworkConnection Filters的配置步骤，这里就不贴了，对于WebLogic域数量较少的环境，可以直接在WebLogic Console控制台中配置，对于数据较多的环境，需要写Jython脚本去配置了。这里重点说下Connection Filters的规则，Connection Filters有点儿像一个（WebLogic内部的）防火墙，像防火墙一样，有一定的规则。根据之前的配置经验，总结出一下三点内容供参考：
1
t3/t3s协议的用途
t3/t3s协议是当年BEA（WebLogic被收购前的公司名）公司为WebLogic开发的、基于TCP协议的，用于远程JNDI调用（EJB、JDBC、JMS等）、基于JMX协议的Java和WLST/Jython监控、WebLogic Server之间的RJVM通信等方面的自定义的应用层协议。既然用途这么广，所以规则配置错误，会影响到相关的组件。
2
Connection Filters规则配置原则
先将允许的IP地址或网段设置为allow，然后将除此之外的所有IP地址或网段设置为deny，同时跟上t3、t3s协议，前面allow的规则不需要跟协议（表示允许所有协议的连接）。
3
Connection Filters规则示例及解读
一般写法示例（第二、第三个域用*号代替，意在简化配置，用户可根据自己的需要进行精准的控制）：
127.0.0.1 * * allow
10.10.5.68 * * allow
10.10.3.0/255.255.255.0 * * allow 或 10.10.3.0/24 * * allow
0.0.0.0/0 * * deny t3 t3s
解读
第一条（127.0.0.1 * * allow）表示允许本机回环地址所有协议的连接，第二条（10.10.5.68 * * allow）表示允许来自10.10.5.68地址任何协议的访问请求，第三条（10.10.3.0/255.255.255.0 * * allow）表示允许10.10.3.0网段所有协议的连接，最后一条（0.0.0.0/0 * * denyt3 t3s）表示禁止除上面三条规则以外所有IP地址或网段t3、t3s协议的连接。
注意：需要先搞清楚目标WebLogic环境使用t3或t3s协议的地方，然后在测试环境进行业务的功能测试，最后再由业务和运维人员监控确认没问题后，方可在生产环境配置。
5月8日，Oracle在其官方知识库中还添加了一篇文章：
April 2018 Critical Patch Update: Additional Information about theOracle WebLogic Server Vulnerability CVE-2018-2628 (Doc ID 2395745.1) ，以帮助大家应对目前这种CVE-2018-2628补丁无效的情况（主要就是让升级JDK版本到最新的Java SE 6u191、Java SE 7u181 and Java SE 8u172），但升级JDK可能会对部分第三方类库功能产生影响，所以这个方案也是存在一定风险的。