weblogic漏洞分析之CVE-2016-0638

一、环境搭建：

这里使用前一篇文章的环境，然后打上补丁

上一篇文章：https://www.cnblogs.com/yyhuni/p/15137095.html

下载补丁p20780171_1036_Generic和p22248372_1036012_Generic
解压补丁后，复制补丁到Docker中：

docker cp ./p22248372_1036012_Generic/ d1b6be39e32e:/home/

docker cp ./p20780171_1036_Generic d1b6be39e32e:/home/

安装补丁：

docker exec -it d1b6be39e32e /bin/bash

cd /root/Oracle/Middleware/utils/bsu

mkdir cache_dir

cp /home/p20780171_1036_Generic/* ./cache_dir/

cp /home/p22248372_1036012_Generic/* ./cache_dir/

vi bsu.sh   编辑MEM_ARGS参数为1024

./bsu.sh -install -patch_download_dir=/root/Oracle/Middleware/utils/bsu/cache_dir/ -patchlist=EJUW -prod_dir=/root/Oracle/Middleware/wlserver_10.3 -verbose

./bsu.sh -install -patch_download_dir=/root/Oracle/Middleware/utils/bsu/cache_dir/ -patchlist=ZLNA -prod_dir=/root/Oracle/Middleware/wlserver_10.3 -verbose

重启服务：

docker restart d1b6be39e32e

这时候，使用原先的poc已经是失效了，说明补丁成功打上

二、补丁分析

配置好weblogic的远程调试端口后，复制jar包，导入idea

详细步骤看前面一篇文章：https://www.cnblogs.com/yyhuni/p/15137095.html

补丁位置：

weblogic.rjvm.InboundMsgAbbrev.class :: ServerChannelInputStream

weblogic.rjvm.MsgAbbrevInputStream.class

weblogic.iiop.Utils.class

第一个位置在InboundMsgAbbrev中，新增了个判断

重点在ClassFilter.isBlackListed判断是否存在黑名单中，跟进方法

方法isBlackListed中对className和pkgName都进行了黑名单判断，匹配到了则返回true。黑名单list

在值为org.apache.commons.collections.functors.ChainedTransformer时候抛出了异常

补丁的第二个位置MsgAbbrevInputStream也是做了同样的判断

现在来进行一遍流程分析，先看下之前的整个调用栈

POC伪造的T3协议数据包，发送到服务器，服务器反序列化处理到了InboundMsgAbbrev#readObject方法中

switch分发节点，到了case0中，调用了(new InboundMsgAbbrev.ServerChannelInputStream(in))的readObject方法来进行的反序列化

计算得出为InboundMsgAbbrev类中的一个内部类ServerChannelInputStream

以下是ServerChannelInputStream类的继承图

其继承了ObjectInputStream，并重写了resolveClass方法

weblogic反序列化类时候调用的是ServerChannelInputStream的readObject方法，而在执行到resolveClass方法的时候调用的是ServerChannelInputStream重写的resolveClass方法，在方法中对其做了黑名单过滤导致无法执行后面的readObject、readExternal、readResolve方法。

三、绕过黑名单

要想绕过黑名单，则需要寻找一个不在黑名单的类。要知道，ObjectInputStream在执行readObject方法的时候，除了会调用反序列化类的readObject方法外，还会调用readExternal、readResolve，详细调用过程可以看https://www.cnblogs.com/yyhuni/p/15127416.html

所以weblogic.jms.common.StreamMessageImpl类就被挖掘了出来。其StreamMessageImpl#readExternal中，会调用var5的readObject方法，而var5是一个ObjectInputStream对象

四、漏洞分析

攻击机

这里使用weblogic_cmd构造的poc：https://github.com/5up3rc/weblogic_cmd

-H "192.168.202.129" -C "touch /tmp/success" -B -os linux

这里把CC1的利用链，进行了序列化后传入了streamMessageImpl方法

跟进streamMessageImpl方法，new了一个StreamMessageImpl对象，这个对象也就是构造payload的关键，然后把序列化转换后的byte数组传入了setDataBuffer方法

跟进setDataBuffer，对this.buffer和this.length进行了赋值操作

随后把获得的StreamMessageImpl对象又进行了一次序列化操作（序列话后的payload传入对象，再把对象进行了序列化）

StreamMessageImpl对象序列化会调用writeExternal方法

在StreamMessageImpl对象的writeExternal方法中进行了重写，把之前的payload给write进了ObjectOutputStream对象中

最后返回给了byte[] payload，然后进行了T3协议构造并且发送给了服务器

服务端

在服务端接受到payload，随后进行了反序列化操作，跳转到InboundMsgAbbrev#resolveClass方法中，进行黑名单判断

黑名单中并没有StreamMessageImpl这个类，返回false，走入else中

接下来就会到StreamMessageImpl#readExternal方法

switch中由前面构造payload时候写入，case为1

此时的var4就是CC1的承载了payload的AnnotationInvocationHandler序列化后的BufferInputStream

最后调用了var5.readObject就触发了AnnotationInvocationHandler#readObject方法了

总结

在这里用了StreamMessageImpl类来绕过黑名单检查，把AnnotationInvocationHandler序列化后通过重写的writeExternal方法给write进了ObjectOutputStream对象中，调用StreamMessageImpl类的readExternal传入了参数并执行了参数的readObject方法从而触发了调用链

参考：https://xz.aliyun.com/t/8443