CVE-2020-14756 漏洞利用以及分析

Andrew 2021-02-15
专栏 - 观点观察 发布于 2021-02-15 01:48:10 阅读 346 评论 0

0x01利用思路

weblogicT3协议反序列化漏洞一直是一个比较热门也比较好用的漏洞,weblogic针对该漏洞的解决方案就是不断填充黑名单,在高版本jdk下配合jep290机制实现黑名单,在低版本下配合resolveClass进行防御,所以安全人员对于T3反序列化的利用也是一直在寻找黑名单之外的利用链。

CVE-2020-14756 这个漏洞的利用比较巧妙,通过利用weblogic coherence组件中的类,绕过了黑名单机制的检测,重新能够利用黑名单中的类,造成代码执行。

0x02漏洞分析

weblogiccoherence.jar中,存在着一个比较特殊的接口com.tangosol.io.ExternalizableLite,他继承了Serializable接口。
图片

readExternalwriteExternal方法
图片

ExternalizableLite接口的对象可以在com.tangosol.util.ExternalizableHelper里被序列化。
图片

这里的nType是在writeObject写入的,是可控的
图片

readExternalizableLite方法的具体内容为:

这里会加载传入的对象,对象需要是ExternalizableLite的实现类
图片

这里直接调用class.forName还原对象
图片
之后,会继续调用对象的readExternal方法,这样一来,后续的流程就绕过了ObjectInputStream对于对象的还原,而weblogic的黑名单检测也主要是针对ObjectInputStream的,所以,现在只需要找到后续的利用链就可以造成代码执行。

漏洞发现者使用了com.tangosol.util.aggregator.TopNAggregator.PartialResult这个类。这里会利用ExternalizableHelper还原m_comparator参数,是一个Comparator类型的对象。
图片

然后调用了instantiateInternalMap方法,传入m_comparator
图片
首先实例化SortedBag.WrapperComparator,赋值f_comparator,然后返回TreeMap对象
图片

接着,调用add方法,在add方法里调用super.add,即SortedBag.add,继续调用put方法。

图片
put方法里,调用了compare方法
图片
而这里又会调用WrapperComparatorcompare方法

图片
这个f_comparator就是之前已经赋值过的。
图片
所以,最终的利用就在f_comparator这里,f_comparator从前面可以知道,需要是一个Comparator类型,这里使用的是 MvelExtractor 这是之前黑名单里的一个类,在CVE-2020-2555中有使用,不过现在我们不受黑名单的限制,MvelExtractor 没有compare方法。于是调用父类AbstractExtractorcompare方法。
图片
然后又会调用子类MvelExtractorextract方法。

序列化入口一

到现在我们的入口是TopNAggregator$PartialResult,他的readExternal(DataInput in)不是标准的readExternal(ObjectInput in),序列化的过程中是不会自动调用到该方法的,所以还需要找一个入口,这里作者发现了AttributeHolder

这里不但会将ObjectInput转为DataInput,还会主动调用ExternalizableHelper.readObject。所以我们只需要m_oValueTopNAggregator$PartialResult即可完成利用。
图片

调用栈
图片

序列化入口二

另外一个入口是com.tangosol.net.security.PermissionInfo,我们看他的readExternal方法,将输入流传入readCollection方法里,PermissionInfoExternalizableHelper的子类,所以这里PermissionInfo没有readCollection方法,直接调用其父类ExternalizableHelper的方法。
图片
判断输入流类型之后,调用了readObject
在调用readCollection的时候,将ObjectInput转为了DataInput
图片
走到这里,就和之前的流程一模一样了。
图片
调用栈
图片

0x03 12.1.3版本问题

经测试,12.1.3 利用存在如下问题

图片
从前面的分析可以知道,类的加载是在loadClass方法里,利用class.forName去加载类。
图片
这里的loader就很关键了,决定了哪些类可以加载,哪些类没发加载,这里的loader是调用getContextClassLoader获得的一个线程上下文类加载器。
图片

这里的线程上下文类加载器是默认的 AppClassLoader,在loaders里发现JarLoader加载了的coherence组件的依赖只有coherence.jarcoherence-web.jar,而MvelExtractorcoherence-rest.jar里,所以没有办法加载。
图片
图片

以下是一些尝试(未成功):
于是我这里先是考虑了另一个在黑名单的类,ReflectionExtractor,这个类在coherence.jar包下,不过在构造利用这个反射执行链的时候,需要反序列化Runtime.class对象,而Runtime.class对象不是ExternalizableLite的实现类,根据nType,在序列化的时候会调用readSerializeable方法
图片

该方法还是会走ObjectInputStream的反序列化流程,即使是通过修改nType让他走readExternalizable,后面还是会有类型转换报错。
图片

所以这样是不行的,12.1.3版本很多类都利用不了,比如RemoteConstructorUniversalExtractorLockVersionExtractor这些类在 12.1.3 版本中都没有,已知的利用链在 12.1.3 来说是没有办法进行利用的。

0x04官方修复之梅开二度

(补丁只能针对实现了jep290jdk
根据补丁来看:
图片

对输入流的类型进行了判断,如果是ObjectInputStream,那么会去调用checkObjectInputFilter方法,方法如下:

图片

这里会获取filter,在ExternalizableHelper的静态代码块里初始化了filter
首先会获取是否存在ObjectInputFilter,来判断jdk环境中是否存在jep290
图片

然后通过getObjectInputFilter/getInternalObjectInputFilter方法去获取serialFilter,之后,调用checkInput,对当前序列化的类进行检测。

不过,对于没有实现jep290jdk版本而言,这个修补是没有作用的,因为低版本jdk不存在ObjectInputFilter,所以说filter参数就为null,也就是说checkObjectInputFilter方法直接返回true
图片

既然为true,那么还是能进行类的实例化。
图片

原创: ob1t0 补天平台
原创链接:https://mp.weixin.qq.com/s/QT3K__1EMXC0uqB...

本作品采用《CC 协议》,转载必须注明作者和本文链接
讨论数量: 0
(= ̄ω ̄=)··· 暂无内容!
请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!