大家好，又见面了，我是全栈君，祝每个程序员都可以多学几门语言。

Java安全之Weblogic 2016-0638分析

文章首发先知：Java安全之Weblogic 2016-0638分析

0x00 前言

续上篇文的初探weblogic的T3协议漏洞，再谈CVE-2016-0638， CVE-2016-0638是基于 CVE-2015-4852漏洞的一个绕过。

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

0x01 环境搭建

补丁环境搭建

这里采用上次的weblogic环境，但是在这里还需要打一个补丁包，来修复 CVE-2015-4852漏洞后，对该漏洞进行一个绕过。

CVE-2015-4852的修复补丁为p21984589_1036_Generic,由于在互联网上并没有找到该补丁包，只能通过官网下载，官网下载需要购买对应的服务，所以在这里找了p20780171_1036_Generic和p22248372_1036012_Generic这两个补丁包，p21984589_1036_Generic是前面这两个补丁包的集成。

因为前面搭建是docker的环境，需要将这两个补丁包上传到docker镜像里面去，然后进行安装。

命令整理：

docker cp ../p20780171_1036_Generic  weblogic1036jdk7u21:/p20780171_1036_Generic

docker cp ../p22248372_1036012_Generic  weblogic1036jdk7u21:/p22248372_1036012_Generic

docker exec -it weblogic1036jdk7u21 /bin/bash

cd /u01/app/oracle/middleware/utils/bsu

mkdir cache_dir

vi bsu.sh   编辑MEM_ARGS参数为1024

cp /p20780171_1036_Generic/* cache_dir/

./bsu.sh -install -patch_download_dir=/u01/app/oracle/middleware/utils/bsu/cache_dir/ -patchlist=EJUW -prod_dir=/u01/app/oracle/middleware/wlserver/

cp /p22248372_1036012_Generic/* cache_dir/

./bsu.sh -install -patch_download_dir=/u01/app/oracle/middleware/utils/bsu/cache_dir/ -patchlist=ZLNA  -prod_dir=/u01/app/oracle/middleware/wlserver/ –verbose

重启weblogic服务。

/u01/app/oracle/Domains/ExampleSilentWTDomain/bin/startWebLogic.sh

这里看到weblogic 2015-4852的payload打过去，并没有像以往一样，创建一个文件。那么就说明补丁已经打上了，已经能够修复该漏洞了。这里是切换了JDK7u21和cc1的利用链依旧没打成功。

远程调试

接下来还是需要将里面的依赖包给拷一下。

mkdir wlserver1036

mkdir coherence_3.7

docker cp weblogic1036jdk7u21:/u01/app/oracle/middleware/modules ./wlserver1036

docker cp weblogic1036jdk7u21:/u01/app/oracle/middleware/wlserver/server/lib ./wlserver1036

docker cp weblogic1036jdk7u21:/u01/app/oracle/middleware/coherence_3.7/lib ./coherence_3.7/lib

下面来对该补丁进行一个绕过。

0x02 补丁分析

补丁作用位置：

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

在分析漏洞前，先来看到一下，上一个漏洞点的补丁是怎么进行修复的。

在这其实看到该resolveClass方法的位置，前面加多一个判断。

前面判断className是否为空，ClassName的长度是否为零，但是重点是ClassFilter.isBlackListed方法。

这里先打一个 CVE-2015-4852 exp过来,在该位置打个断点，跟踪进该方法，查看怎么进行防护。

跟进进来后，先别急着看后面的，因为下面还有一个静态代码块，静态代码块中代码优先执行，需要先来查看静态代码块内容。

这里前面有两个判断，判断中都调用了两个方法，来看看这两个方法的实现。

一个是判断是否为weblogic.rmi.disableblacklist，一个是判断是否为weblogic.rmi.disabledefaultblacklist,写法有点奇怪，可能是因为是class文件的缘故。

这两个判断为true的话，就会执行来到下一步调用updateBlackList将后面的一系列黑名单的类传入到里面去。

updateBlackList该方法从名字得知，就是一个黑名单列表添加的一个方法，将黑名单内容添加到一个HashSet里面去。查看具体实现。

StringTokenizer 构造方法：为指定的字符串构造一个字符串tokenizer。

hasMoreTokens方法：返回与 hasMoreTokens方法相同的值。

nextToken 方法：返回此字符串tokenizer字符串中的下一个令牌。

总体的来理解就是构造一个字符串，然后遍历里面的值，然后调用processToken方法将该值传递进去。

再来看到processToken方法。

里面判断如果开头是+号,则截取第一位后面的值添加到黑名单的这个HashSet里面去。如果是-号则移除，如果开头不是前面的+ -号则直接添加到黑名单里面去。

到这里静态代码块就已经分析完成了，总的来说其实就是将一些危险的类，添加到了黑名单里的一个步骤。

黑名单列表为：

+org.apache.commons.collections.functors,
+com.sun.org.apache.xalan.internal.xsltc.trax,
+javassist,+org.codehaus.groovy.runtime.ConvertedClosure,
+org.codehaus.groovy.runtime.ConversionHandler,
+org.codehaus.groovy.runtime.MethodClosure

返回刚刚的ClassFilter.isBlackListed方法进行跟踪

最后这里调用了contains方法判断 这个pkgName存不存在黑名单中，存在的话这里返回true。

返回到resolveClass方法可以看到这里为true，就会直接抛异常。

如果不存在于黑名单中，会来到else这个分支的代码块中调用父类的resolveClass方法。

而这一个点，只是过滤的一个点，下面来看看过滤的点都有哪些。

再来看下一个点MsgAbbrevInputStream的位置

这里也是调用ClassFilter.isBlackListed方法进行过滤，和前面的是一样的。以此类推。

0x03 工具分析

在CVE-2016-0638里面用到了weblogic_cmd工具，github地址。

下面来看看该工具的实现，再谈漏洞的绕过方式。

下载该源码后，导入IDEA中，配置命令参数。

这里如果报错找不到sun.tools.asm包的话，需要将Tools.jar包手动添加一下。在这我是使用jdk1.6进行执行的，使用1.8版本会找不到sun.org.mozilla.javascript.internal.DefiningClassLoader类

在Main的类中打个断点进行执行。

前面都是代码都是进行一个配置，这里断点选择落在该方法中。

选择跟踪

继续跟踪WebLogicOperation.blindExecute方法。

前面判断了服务器类型，重点在SerialDataGenerator.serialBlindDatas方法中，payload由该方法进行生成。跟进查看一下该方法如何生成payload。

在这先选择跟踪blindExecutePayloadTransformerChain方法。

在这里又看到了熟悉的面孔，CC链的部分代码。

回到刚刚的地方，跟踪serialData方法

在这里就看到了CC链后面的一段代码，这组合成了一条CC1利用链。但是在后面调用了BypassPayloadSelector.selectBypass方法来处理在原生的利用链中本该直接进行序列化的对象。

跟进该方法进行查看。

这里面还会去调用Serializables.serialize，依旧先跟踪最里层的方法。

这传入一个obj对象和out对象，进行了序列化操作。然后将序列化后的数据写到out对象中。

执行完成后，返回上一个点，刚才分析得知返回的是序列化后的数据。所以在处调用streamMessageImpl方法传递的参数也是序列化的数据。

跟踪查看。

内部是new了一个weblogic.jms.common.StreamMessageImpl的实例，然后调用setDataBuffer方法将序列化后的对象和序列化后的长度传递进去。

执行完这步后，回到这个地方

后面的这个方法是进行序列化操作的，这里又对 streamMessageImpl的实例对象进行了一次序列化。该方法在前面查看过了，这里就不跟进去看了。

而最后来到了这里。

而后面这个方法就是构造特定的数据包，使用T3协议发送payload。

0x04 漏洞分析

那么如果需要绕过的话，我们需要找一个类，他的类在内部的readObject方法创建了自己的InputStream的对象,但是又不能为黑名单里面过滤掉的ServerChannelInputStream和MsgAbbrevInputStream里面的readObject方法。然后调用该readObject 方法进行反序列化，这时候就可以达成一个绕过的效果。

在师傅们的挖掘中寻找到了weblogic.jms.common.StreamMessageImpl#readExternal()，StreamMessageImpl类中的readExternal方法可以接收序列化数据作为参数，而当StreamMessageImpl类的readExternal执行时，会反序列化传入的参数并调用该参数反序列化后对应类的这个readObject方法。

绕过原理如下：

将反序列化的对象封装进了 StreamMessageImpl，然后再对 StreamMessageImpl 进行序列化，生成 payload 字节码。反序列化时 StreamMessageImpl 不在 WebLogic 黑名单里，可正常反序列化，在反序列化时 StreamMessageImpl 对象调用 readObject 时对 StreamMessageImpl 封装的序列化对象再次反序列化，这样就逃过了黑名单的检查。

在此先再来思考一个问题，weblogic.jms.common.StreamMessageImpl#readExternal()该方法是怎么被调用的呢？在前面分析原生readObject方法的时候发现，其实readObject方法的底层还会去调用很多其他方法。

在Weblogic从流量中的序列化类字节段通过readClassDesc-readNonProxyDesc-resolveClass获取到普通类序列化数据的类对象后，程序依次尝试调用类对象中的readObject、readResolve、readExternal等方法。而在这里readExternal就会被调用。

那么下面来调试分析一下该漏洞。

还是先在weblogic.rjvm.InboundMsgAbbrev#ServerChannelInputStream.resolveClass地方打个断点，然后使用weblogic_cmd工具打一个payload过去，先来查看一下传输过来的数据。

这里可以看到获取到的ClassName是weblogic.jms.common.StreamMessageImpl的对象，而不在再是AnnotationInvocationHandler对象。StreamMessageImpl不在黑名单中，这里的判断不会进行抛异常。

下个断点直接落在StreamMessageImpl.readExternal中跟踪一下。

看到调用栈这里就应验了我们前面所提到的关于StreamMessageImpl.readExternal调用问题。

这里的var4为正常反序列化后的数据，而后面会new一个ObjectInputStream类传递var4参数进去。然后再调用readObject方法

执行完这一步后，命令就已经执行成功。后面的是对CC链执行命令的一个基本认知，在此不做赘述。

参考文章

https://xz.aliyun.com/t/8443#toc-6

https://www.anquanke.com/post/id/224343#h3-6

0x05 结尾

其实摸清楚补丁的一个套路过后，再去基于补丁分析后面的漏洞会比较清晰。因为补丁无非就是再从ClassFilter里面添加黑名单列表，这也是为什么weblogic修修补补又爆洞的原因，并没有从根本原因去进行修复。