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链比较关键的包。

Weblogic安全漫谈(二)_第1张图片

Weblogic安全漫谈(二)_第2张图片

梳理一下:

  1. 原生反序列化依然存在,流程中的各个关键方法可用。

  2. CC链在黑名单以外的部分,仍然可以用作调用链。

  3. 黑名单类不在ServerChannelInputStream做反序列化就不受限制。

根据第三点先获取所有用到readObject的地方,用Serializable.class.isAssignableFrom(clazz)筛出可被序列化的类,筛出数据可控的二次反序列化。找到的两个可用类刚好对应两个CVE。

CVE-2016-0638

看到weblogic.jms.common.StreamMessageImpl#readExternal,完成父类readExternal后读到的字节是十进制1时会进入存在readObject的分支。

Weblogic安全漫谈(二)_第3张图片

跟进中间会经过的createPayload方法,读到的整数大于CHUNK_LINK_THRESHOLD会做一些处理。中间这块的处理看不太懂,我们假设它不满足判断继续往后走,一直跟到Chunk.createOneSharedChunk

Weblogic安全漫谈(二)_第4张图片

虽然中间一些Chunk的判断和操作由于笔者太菜了看不懂,但到了这里就能看出,这个先前读到的被一路传过来的整数是后段数据长度。后面这段数据被完整读出并封装赋值给this.payload,随后进行第二次反序列化。

Weblogic安全漫谈(二)_第5张图片

按照同样的数据顺序重写StreamMessageImplwriteExternal,写入相应格式的CC链序列化payload,再经过一次正常新建类对象并经过第二次序列化,最后用上一篇的EXP打出去就行。

Weblogic安全漫谈(二)_第6张图片

 

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对象作为参数给进去就行。

Weblogic安全漫谈(二)_第7张图片

 

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)

Weblogic安全漫谈(二)_第8张图片

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

CVE-2017-3248

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

CVE-2018-2628

ysoserialRMIRegistryExploit设计用于攻击Java原生RMI注册端,用了给JRMPClient的payload套上Registry动态代理的方式,来兼容Java原生registry.bind方法的参数要求。

Weblogic安全漫谈(二)_第9张图片

而这大概就是Weblogic企图靠InboundMsgAbbrev重写resolveProxyClass作为CVE-2017-3248的修复方式原因之一。我们是用自己的EXP作为T3客户端,不存在参数类型兼容的问题,直接去掉动态代理类的包装即可绕过检查(或者使用不同的接口代理)。

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

Weblogic安全漫谈(二)_第10张图片

CVE-2018-2893

据参考文章,在cpuapr2018补丁中黑名单新增了sun.rmi.server.UnicastRef。看到java.rmi.server.RemoteObjectInvocationHandler会使用父类的RemoteObject,读到refClassName时就会做一次神奇的第二次反序列化,自带绕过特效。

Weblogic安全漫谈(二)_第11张图片

Weblogic安全漫谈(二)_第12张图片

要素察觉!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将基类纳入黑名单。

你可能感兴趣的:(安全,java,开发语言,Weblogic,webgl,web安全,网络)