Java安全之Weblogic 2016-3510 分析

Java安全之Weblogic 2016-3510 分析

首发安全客：Java安全之Weblogic 2016-3510 分析

0x00 前言

续前面两篇文章的T3漏洞分析文章，继续来分析CVE-2016-3510漏洞，该漏洞同样是基于，前面的补丁进行一个绕过。

Java安全之初探weblogic T3协议漏洞

Java安全之Weblogic 2016-0638分析

0x01 工具分析

这里还须要拿出上次的weblogic_cmd的工具来看一下CVE-2016-3510的命令执行payload怎么去进行构造。

来到源码中的Main这个入口点这里，前面的TYPE须要修改成marshall,由于此次是须要使用到MarshalledObject来进行封装对象。

填入参数，打个断点测试一下。

前面的都分析过了，在此略过，主要是这张图片里面的地方传入命令，而且生成payload，跟踪进行查看。

这里的blindExecutePayloadTransformerChain方法是返回构造利用链的Transformer[]数组内容，这里主要来跟踪serialData方法。

该方法中是将刚刚构造好的Transformer[]数组传入进来，联合下面的代码构形成了一个恶意的对象，而后调用BypassPayloadSelector.selectBypass方法处理这个恶意的对象。跟踪查看该方法的实现。

这个位置调用了marshalledObject方法处理payload，跟踪查看。

marshalledObject内部使用了MarshalledObject的构造方法，将payload做为参数传递进去。而后获得该值。这里payload就构造好了。

跟踪进MarshalledObject里面进行查看。

这个地方又new了一个MarshalledObject.MarshalledObjectOutputStream对象，跟踪查看。

MarshalledObject.MarshalledObjectOutputStream继承了ObjectOutputStream对象，而且调用的是父类的构造器。这就和直接new一个ObjectOutputStream没啥区别。

var1是咱们传递进来的payload，在这里使用的是CC1的利用链，var1也就是一个恶意的AnnotationInvocationHandler对象。var2是ByteArrayOutputStream对象，var3至关因而一个ObjectOutputStream对象。在这里会将var1 的内容进行序列化后写入到var2里面。

而序列化后的对象数据会被赋值给MarshalledObject的this.objBytes里面。

执行完成，退回到这一步事后，则是对构造好的MarshalledObject对象调用Serializables.serialize方法进行序列化操做。

0x02 漏洞分析

在前面并无找到CVE-2016-0638漏洞的补丁包，那么在这里也能够直接来看到他的利用方式。

前面CVE-2016-0638这个漏洞是基于前面的补丁将payload序列化事后封装在weblogic.jms.common.StreamMessageImpl类里面，而后进行反序列化操做，StreamMessageImpl类会调用反序列化后的对象的readobject方法达成命令执行的操做。而补丁包应该也是在ClassFileter类里面将上次咱们利用的weblogic.jms.common.StreamMessageImpl类给进行拉入黑名单中。

那么在该漏洞的挖掘中又找到了一个新的类来对payload进行封装，而后绕过黑名单的检测。

而此次使用得是weblogic.corba.utils.MarshalledObject类来进行封装payload，将payload序列化事后，封装到weblogic.corba.utils.MarshalledObject里面，而后再对MarshalledObject进行序列化MarshalledObject,MarshalledObject不在WebLogic黑名列表里面，能够正常反序列化，在反序列化时MarshalledObject对象调用readObject时，对MarshalledObject封装的序列化对象再次反序列化，这时候绕过黑名单的限制，对payload进行反序列化操做触发命令执行。

下面来直接看到weblogic.corba.utils.MarshalledObject#readResolve方法的位置

这地方就有意思了，前面在分析工具的时，咱们得知构造的绕过方式是将payload序列化放在这个this.objBytes中，而在此若是调用MarshalledObject.readResolve方法就能够对被封装的payload进行反序列化操做。达到执行命令的效果。

在这里还须要思考到一个问题readResolve这个方法会在何时被调用呢？

在Weblogic从流量中的序列化类字节段经过readClassDesc-readNonProxyDesc-resolveClass获取到普通类序列化数据的类对象后，程序依次尝试调用类对象中的readObject、readResolve、readExternal等方法。而上一个CVE-2016-0638的漏洞就是借助的readExternal会被程序所调用的特色来进行绕过。咱们此次使用的是readResolve这个方法，这个方法也是同理。

后面也还须要知道一个点，就是反序列化操做事后，readResolve具体是如何触发的？下来来断点查看就清楚了。

先在InboundMsgAbbrev.ServerChannelInputStream#resolveClass方法先打一个断点，payload发送完成后，在该位置停下。

在这这里能够看到传递过来的是一个MarshalledObject对象，不在黑名单中。

那么下面在readResolve上下个断点看一下调用栈。

在这里面会被反射进行调用，再前面的一些方法因为不是源代码进行调式的跟踪不了。

回到weblogic.corba.utils.MarshalledObject#readResolve方法中查看

和前面说的同样，这里new了一个ByteArrayInputStream对象，对this.objBytes进行读取，前面说过咱们的payload封装在this.objBytes变量里面，而这时候new了一个ObjectInputStream而且调用了readObject方法进行反序列化操做。那么这时候咱们的payload就会被进行反序列化操做，触发CC链的命令执行。

先来查看docker容器里面的内容

而后执行来到下一行代码中。

readobject执行事后，再来查看一下docker里面的文件有没有被建立。

文件建立成功，说明命令可以执行。

0x03 结尾

本文内容略少，缘由是由于不少内容都是前面重复的，并不须要拿出来从新再叙述一遍。这样的话并无太大的意义，若是没有分析过前面的两个漏洞，建议先从前面的CVE-2015-4852和CVE-2016-0638这两个漏洞调试分析起，调试分析完前面的后面的这些绕过方式理解起来会比较简单。