weblogic漏洞分析之CVE-2016-0638
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方法从而触发了调用链
