Weblogic安全漫谈(二)

前言

继本系列上篇从CVE-2015-4852入手了解T3协议的构造后，本篇继续分析开启T3反序列化魔盒后的修复与绕过。

Weblogic对于10.3.6推出了p20780171和p22248372用于修复CVE-2015-4852，在补丁详情中又提示了p21984589是它的超集，所以可以直接装这个合集。跟着压缩包里自带的

README.txt

走就行，注意一点是要改一下

bsu.sh

中的内存限制，不然会遇到

Java heap space OutOfMemoryError

。

unzip p21984589_1036_Generic.zip -d /u01/app/oracle/middleware/utils/bsu/cache_dir/

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

sed -i 's/512/1024/' bsu.sh

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

. /u01/app/oracle/middleware/wlserver/server/bin/setWLSEnv.sh
/java/bin/java weblogic.version

补丁在重写的

ServerChannelInputStream#resolveClass

中新增了类名黑名单，加入了CC链比较关键的包。

梳理一下：

1. 原生反序列化依然存在，流程中的各个关键方法可用。
2. CC链在黑名单以外的部分，仍然可以用作调用链。
3. 黑名单类不在ServerChannelInputStream做反序列化就不受限制。

根据第三点先获取所有用到

readObject

的地方，用

Serializable.class.isAssignableFrom(clazz)

筛出可被序列化的类，筛出数据可控的二次反序列化。找到的两个可用类刚好对应两个CVE。

CVE-2016-0638

看到

weblogic.jms.common.StreamMessageImpl#readExternal

，完成父类

readExternal

后读到的字节是十进制1时会进入存在

readObject

的分支。

跟进中间会经过的

createPayload

方法，读到的整数大于

CHUNK_LINK_THRESHOLD

会做一些处理。中间这块的处理看不太懂，我们假设它不满足判断继续往后走，一直跟到

Chunk.createOneSharedChunk

。

虽然中间一些

Chunk

的判断和操作由于笔者太菜了看不懂，但到了这里就能看出，这个先前读到的被一路传过来的整数是后段数据长度。后面这段数据被完整读出并封装赋值给

this.payload

，随后进行第二次反序列化。

按照同样的数据顺序重写

StreamMessageImpl

的

writeExternal

，写入相应格式的CC链序列化payload，再经过一次正常新建类对象并经过第二次序列化，最后用上一篇的EXP打出去就行。

readExternal:1433, StreamMessageImpl (weblogic.jms.common)
readExternalData:1814, ObjectInputStream (java.io)
readOrdinaryObject:1773, ObjectInputStream (java.io)

resolveClass:110, InboundMsgAbbrev$ServerChannelInputStream (weblogic.rjvm)
readNonProxyDesc:1589, ObjectInputStream (java.io)
readClassDesc:1494, ObjectInputStream (java.io)
readOrdinaryObject:1748, ObjectInputStream (java.io)
readObject0:1327, ObjectInputStream (java.io)

CVE-2016-3510

看到

weblogic.corba.utils.MarshalledObject#readResolve

，是比上一个品相更好的二次反序列化类。

this.objBytes

属性来自构造函数传入的对象，直接将payload对象作为参数给进去就行。

readResolve:58, MarshalledObject (weblogic.corba.utils)
invoke0:-1, NativeMethodAccessorImpl (sun.reflect)
invoke:39, NativeMethodAccessorImpl (sun.reflect)
invoke:25, DelegatingMethodAccessorImpl (sun.reflect)
invoke:597, Method (java.lang.reflect)
invokeReadResolve:1056, ObjectStreamClass (java.io)
readOrdinaryObject:1784, ObjectInputStream (java.io)
readObject0:1327, ObjectInputStream (java.io)

补丁在上述两个类反序列化前单独添加了检查，随后进入下一个对RMI的利用阶段。

CVE-2017-3248

与此前《攻击JavaRMI概述》中唯一不同的一点是，第一步触发反序列化时的通讯协议，从Java原生的JRMP协议变为了Weblogic的T3协议。生成一个JRMPClient的payload用于在目标反序列化时发起JRMP请求，其它攻击流程一致。

CVE-2018-2628

ysoserial

的

RMIRegistryExploit

设计用于攻击Java原生RMI注册端，用了给

JRMPClient

的payload套上Registry动态代理的方式，来兼容Java原生registry.bind方法的参数要求。

而这大概就是Weblogic企图靠

InboundMsgAbbrev

重写

resolveProxyClass

作为CVE-2017-3248的修复方式原因之一。我们是用自己的EXP作为T3客户端，不存在参数类型兼容的问题，直接去掉动态代理类的包装即可绕过检查（或者使用不同的接口代理）。

不过与此同时补丁也给CC包加上了手动开关，基本断了这条链的生路。所以这一阶段的Sink链大多基于7u21/8u20。

CVE-2018-2893

据参考文章，在

cpuapr2018

补丁中黑名单新增了

sun.rmi.server.UnicastRef

。看到

java.rmi.server.RemoteObjectInvocationHandler

会使用父类的

RemoteObject

，读到

refClassName

时就会做一次神奇的第二次反序列化，自带绕过特效。

要素察觉！CVE-2016-0638和CVE-2016-3510也是二次反序列化绕过黑名单，不过

MarshalledObject

被去掉了Serializable接口，

StreamMessageImpl

则仍然可用于绕过。

CVE-2018-3245

在

cpujul2018

补丁中黑名单继续增加了：

java.rmi.activation
sun.rmi.server
java.rmi.server.UnicastRemoteObject
java.rmi.server.RemoteObjectInvocationHandler

RemoteObject

不在黑名单的子类们仍然可用，直到

cpuoct2018

将基类纳入黑名单。