Loading

weblogic漏洞分析之CVE-2016-0638

weblogic漏洞分析之CVE-2016-0638

一、环境搭建:

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

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

  1. 下载补丁p20780171_1036_Generic和p22248372_1036012_Generic
  2. 解压补丁后,复制补丁到Docker中:
docker cp ./p22248372_1036012_Generic/ d1b6be39e32e:/home/
docker cp ./p20780171_1036_Generic d1b6be39e32e:/home/
  1. 安装补丁:
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
  1. 重启服务:
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中,新增了个判断

image-20210815220532722

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

image-20210815225307222

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

image-20210815225013787

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

image-20210815225512109

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

image-20210815225632794

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

img

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

image-20210815235957543

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

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

image-20210816000107816

以下是ServerChannelInputStream类的继承图

image-20210816000425993

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

image-20210816002224971

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

三、绕过黑名单

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

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

image-20210816202447836

四、漏洞分析

攻击机

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

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

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

image-20210816203509390

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

image-20210816203734577

跟进setDataBuffer,对this.bufferthis.length进行了赋值操作

image-20210816203953967

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

image-20210816204039904

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

image-20210816204211519

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

image-20210816205329212

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

image-20210816205531249

服务端

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

image-20210816210055983

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

image-20210816210228053

接下来就会到StreamMessageImpl#readExternal方法

image-20210816210356974

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

image-20210816210503659

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

image-20210816210724953

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

image-20210816210952349

总结

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

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

posted @ 2021-08-17 16:59  yyhuni's  阅读(287)  评论(0编辑  收藏  举报