WebLogic反序列化漏洞的实例分析

今天就跟大家聊聊有关WebLogic反序列化漏洞的实例分析，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。2018年4月18日，Oracle官方发布了4月份的安全补丁更新CPU（Critical Patch Update），更新中修复了一个高危的 WebLogic 反序列化漏洞CVE-2018-2628。攻击者可以在未授权的情况下通过T3协议对存在漏洞的 WebLogic 组件进行远程攻击，并可获取目标系统所有权限。Weblogic 10.3.6免费云主机域名.0Weblogic 12.1.3.0Weblogic 12.2.1.2Weblogic 12.2.1.3这里简单的说下几个有公开利用方式的Weblogic反序列化漏洞。2015年11月6日，FoxGlove Security 安全团队的 @breenmachine 发布的一篇博客中介绍了如何利用Java反序列化和 Apache Commons Collections 这一基础类库来攻击最新版的 WebLogic、WebSphere、JBoss、Jenkins、OpenNMS 这些大名鼎鼎的Java应用，实现远程代码执行。CVE-2015-4852就是利用 Weblogic 中的Commons Collections 库来实现远程代码执行。查看了CVE-2015-4852的补丁（p21984589_1036_Generic），发现 Weblogic 采用的黑名单的形式来修复这个漏洞。
但是这种修复方式很被动，存在被绕过的风险，只要发现可用并且未在黑名单之外的反序列化类，那么之前的防护就会被打破，系统遭受攻击。而后的漏洞也证明了这一点。Weblogic的反序列化的点有着三个,黑名单ClassFilter.class也作用于这三个位置。weblogic.rjvm.InboundMsgAbbrev.class::ServerChannelInputStreamweblogic.rjvm.MsgAbbrevInputStream.classweblogic.iiop.Utils.class有人发现利用weblogic.jms.common.StreamMessageImpl的readExternal()也是可以进行反序列化操作的，而且这个不受黑名单限制，所以可以绕过了之前的补丁。原理是将反序列化的对象封装进了weblogic.corba.utils.MarshalledObject，然后再对MarshalledObject进行序列化，生成 payload 字节码。反序列化时MarshalledObject不在 WebLogic 黑名单里，可正常反序列化，在反序列化时MarshalledObject对象调用readObject时对MarshalledObject封装的序列化对象再次反序列化，这样就逃过了黑名单的检查。Java远程消息交换协议 JRMP 即 Java Remote MessagingProtocol ，是特定于 Java 技术的、用于查找和引用远程对象的协议。这是运行在 Java 远程方法调用 RMI 之下、TCP/IP 之上的线路层协议。这个漏洞就是利用 RMI 机制的缺陷，通过 JRMP 协议达到执行任意反序列化 payload 的目的。使用 ysoserial 的JRMPLister，这将会序列化一个RemoteObjectInvocationHandler，该RemoteObjectInvocationHandler使用UnicastRef建立到远端的 TCP 连接获取RMI registry。 此连接使用 JRMP 协议，因此客户端将反序列化服务器响应的任何内容，从而实现未经身份验证的远程代码执行。首先我们来看以下 CVE-2017-3248 这个漏洞的补丁（p24667634_1036_Generic），在weblogic.rjvm.InboundMsgAbbrev$ServerChannelInputStream.class多了一个resolveProxyClass ，这个resolveProxyClass只是对 RMI 接口类型进行了判断，判断 RMI 接口是否为java.rmi.registry.Registry，是的话抛出错误。

仿照JRMPClient写一个JRMPClient2，重新编译。生成 payload：可以对比以下JRMPClient和JRMPClient2生成的 payload。

除了 RMI 接口不一样，其他都是一样的。JRMPLister开启我测试的 Weblogic 版本是10.3.6.0.170117，即已修复了CVE-2017-3248漏洞，在我本地的环境中，CommonsCollections这个 payload 已经失效了。Weblogic 的commons-collections.jar版本已经升级，所以我这里 payload 用的是Jdk7u21（这个 payload 只有在 JRE 版本小于等于 1.7u21 才起作用）。在commons-collections.jar版本没有升级的 Weblogic 中，使用CommonsCollections这个 payload 是可以的。使用 t3 协议脚本发送 p_client2，可以看到JRMPLister有请求过来了，客户端命令也执行成功了。
作为对比，将JRMPClient生成的 p_client 也发送过去，可以看到报错信息Unauthorized proxy deserialization，正是黑名单拦截抛出的错误。可见java.rmi.activation.Activator是绕过了CVE-2017-3248的补丁了。这种方式是我在复现漏洞时尝试 payload 的时候发现的，绕过的方式和CVE-2016-0638有关。StreamMessageImpl这个点在反序列化的时候没有resolveProxyClass检查。所以可以使用StreamMessageImpl将RemoteObjectInvocationHandler序列化，以此来绕过resolveProxyClass函数。相当于使用CVE-2016-0638的利用方式加上CVE-2017-3248的 payload 来绕过补丁。将JRMPClient生成的 payloadObject 用StreamMessageImpl封装生成新的 payload——p_stream。使用脚本发送，可以看到，成功执行了命令。

初步比对补丁(p27395085_1036_Generic)，发现WeblogicFilterConfig.class的黑名单多了一个sun.rmi.server.UnicastRef。但是根据我的实际测试，命令还是可以执行成功，貌似补丁没起作用。

看完上述内容，你们对WebLogic反序列化漏洞的实例分析有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注云编程开发博客行业资讯频道，感谢大家的支持。

相关推荐: RMIScout怎么使用

这篇文章主要介绍“RMIScout怎么使用”，在日常操作中，相信很多人在RMIScout怎么使用问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”RMIScout怎么使用”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！RMISco…