微信号:OraNews

介绍:分享数据库技术、新闻与信息,尤其是和Oracle数据库相关的内容,文章内容来自原创、专栏作者投稿或读者投稿.

修而未复:说说WebLogic那修不完的Java反序列化漏洞

2018-05-26 08:50 田东云

编者说明:这篇文章初稿写在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可能会对部分第三方类库功能产生影响,所以这个方案也是存在一定风险的。

最后,如果当前WebLogic版本有最新(4月17日)的PSU,虽然解决这个Java反序列化漏洞不给力,但最好还是打上吧,聊胜于无啊!


如果您在配置Connection Filters时需要帮助,请致电:400-660-8755,云和恩墨公司对此漏洞提供多种修复方案(配置Connection Filters只是其中一种)及完善的WebLogic安全加固解决方案,并可结合用户系统环境,推荐最优解决方案。

另外,如果近期在进行Oracle数据库和IPv6改造时需要服务支持,也都可以致电我们。


数据驱动,成就未来,云和恩墨,不负所托!





云和恩墨

数据驱动,成就未来。整合业界顶尖的技术与合作伙伴资源,围绕数据及相关领域,提供解决方案和专业服务。
IT基础架构
分布式存储 | zData一体机 | 容灾方案
数据架构
Oracle DB2 MySQL NoSQL
专项服务:架构/安全/优化/升级/迁移
运维服务:运维服务  代维服务
人才培养:个人认证  企业内训
软件产品:SQL审核、自动化运维、数据恢复
应用架构
应用和中间件:数据建模 | SQL审核和优化 | 中间件服务

 
数据和云 更多文章 当SQL Server爱上Linux:AVAILABILITY_MODE 和 DataGuard& 前世今生:蚂蚁金服自研数据库OceanBase的道路与思考 罗海雄:仅仅使用AWR做报告? 性能优化还未入门(含PPT) 备份恢复:如何让xtrabackup恢复速度提升20倍? 实战课堂:一则CPU 100%的故障分析处理知识和警示
猜您喜欢 【抽奖】结果公布(20180312抽奖结果) NGINX 宣布支持 gRPC,可在下个版本 1.13.10 中使用 来看看硅谷的工程师统计,你才知道程序员的薪酬有多高 【干货】UI设计高大上?搞定这些细节吧! 【EGO会员访谈—张新波】团队沟通与人才招聘,两座大山如何抗?