Weblogic Coherence 组件漏洞总结分析

阅读量179375

发布时间 : 2021-08-09 15:30:42

 

作者:白帽汇安全研究院@kejaly 校对:白帽汇安全研究院@r4v3zn

前言

Coherence 组件是 WebLogic 中的一个核心组件,内置在 WebLogic 中。关于 Coherence 组件的官方介绍:https://www.oracle.com/cn/java/coherence/

近些年,weblogic Coherence 组件反序列化漏洞被频繁爆出,苦于网上没有公开对 weblogic Coherence 组件历史反序列化漏洞的总结,导致很多想入门或者了解 weblogic Coherence 组件反序列化漏洞的朋友不知道该怎么下手,于是本文便对 weblogic Coherence 组件历史反序列化漏洞做出了一个总结和分析。

关于 Coherence 组件反序列化漏洞利用链的架构,我把他分为两个,一个是基于 ValueExtractor.extract 的利用链架构,另一个则是基于 ExternalizableHelper 的利用链架构。

 

前置知识

想理清 WebLogic 的 Coherence 组件历史反序列化漏洞需要首先了解一些 Coherence 组件反序列化漏洞中经常会涉及的一些接口和类。他们在 Coherence 组件反序列化漏洞利用中经常出现。

ValueExtractor

com.tangosol.util.ValueExtrator 是一个接口:

在 Coherence 中 很多名字以 Extrator 结尾的类都实现了这个接口:

这个接口中声明了一个 extract 方法,而 ValueExtractor.extract 正是 Coherence 组件历史漏洞( ValueExtractor.extract 链部分 )的关键。

ExternalizableLite

Coherence 组件中存在一个 com.tangosol.io.ExternalizableLite,它继承了 java.io.Serializable,另外声明了 readExternalwriteExternal 这两个方法。

com.tangosol.io.ExternalizableLite 接口 和 jdk 原生的 java.io.Externalizable 很像,注意不要搞混了。

ExternalizableHelper

上面提到的 com.tangosol.io.ExternalizableLite 接口的实现类的序列化和反序列化操作,都是通过 ExternalizableHelper 这个类来完成的。

我们可以具体看 ExternalizableHelper 这个类是怎么对实现 com.tangosol.io.ExternalizableLite 接口的类进行序列化和反序列化的,这里以 readObject 方法为例,writeObject 读者可自行去查看:

如果传入的DataInput 不是 PofInputStream 的话(Coherence 组件历史漏洞 涉及到的 ExternalizableHelper.readObject 传入的 DataInput 都不是 PofInputStream),ExternalizableHelper#readObject 中会调用 ExternalizableHelper#readObjectInternal 方法:

readObjectInternal 中会根据传入的中 nType 进行判断,进入不同的分支:

对于实现 com.tangosol.io.ExternalizableLite 接口的对象,会进入到 readExternalizableLite 方法:

可以看到在 readExternalizableLite 中 1125 行会根据类名加载类,然后并且实例化出这个类的对象,然后调用它的 readExternal() 方法。

 

漏洞链

ValueExtractor.extract

我们在分析反序列化利用链的时候,可以把链分为四部分,一个是链头,一个是危险的中间的节点(漏洞点),另一个是调用危险中间节点的地方(触发点),最后一个则是利用这个节点去造成危害的链尾。

在 Coherence 组件 ValueExtractor.extract 利用链架构中,这个危险的中间节点就是 ValueExtractor.extract 方法。

漏洞点

ReflectionExtractor

ReflectionExtractor 中的 extract 方法含有对任意对象方法的反射调用:

配合 ChainedExtractorConstantExtractor 可以实现类似 cc1 中的 transform 链的调用。

涉及 CVE

CVE-2020-2555,CVE-2020-2883

MvelExtractor

MvelExtrator 中的 extract 方法,会执行任意一个 MVEL 表达式(RCE):

而在序列化和反序列化的时候 m_sExpr 会参与序列化和反序列化:

所以 m_xExpr 可控,所以就导致可以利用 MvelExtrator.extrator 来达到执行任意命令的作用。

涉及 CVE

CVE-2020-2883

UniversalExtractor

UniversalExtractor(Weblogic 12.2.1.4.0 独有) 中的 extract 方法,可以调用任意类中的的 getis 开头的无参方法,可以配合 jdbsRowset,利用 JDNI 来远程加载恶意类实现 RCE。

具体细节可以参考:https://nosec.org/home/detail/4524.html

涉及 CVE

CVE-2020-14645,CVE-2020-14825 , CVE-2020-14841

LockVersionExtractor

oracle.eclipselink.coherence.integrated.internal.cache.LockVersionExtractor 中的 extract() 方法,可以调用任意 AttributeAccessorgetAttributeValueFromObject 方法,赋值 AccessorMethodAttributeAccessor 进而可以实现调用任意类的无参方法。

具体细节可参考:https://cloud.tencent.com/developer/article/1740557

MethodAttributeAccessor.getAttributeValueFromObject,本质是利用MethodAttributeAccessor.getAttributeValueFromObject中存在任意无参方法调用,在 CVE-2021-2394 中也利用到了。

涉及 CVE

CVE-2020-14825 , CVE-2020-14841

FilterExtractor.extract

filterExtractor.extract 中存在任意 AttributeAccessor.getAttributeValueFromObject(obj) 的调用,赋值 this.attributeAccessor 为上面说的MethodAttributeAccessor 就可以导致任意无参方法的调用。

关于 readAttributeAccessor 的细节可以看 CVE-2021-2394:https://blog.riskivy.com/weblogic-cve-2021-2394-rce%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/https://www.cnblogs.com/potatsoSec/p/15062094.html

涉及 CVE

CVE-2021-2394

触发点

上面例举出了很多危险的 ValueExtractor.extract 方法,接下来再看看哪里存在调用 ValueExtractor.extract 方法的地方。

Limitfiler

Limitfiler 中 Limitfiler.toString 中存在任意 ValueExtractor.extract 方法调用:

由于 this.m_comparator 参与序列化和反序列化,所以可控:

我们只需要赋值 this.m_comparator 为 恶意的 ValueExtractor 就可以实现任意 ValueExtractor .extract 方法的调用。toString 方法,则可以利用 CC5 中用到的 BadAttributeValueExpException 来触发。

涉及 CVE

CVE-2020-2555

ExtractorComparator

ExtractorComparator.compare ,其实是针对 CVE-2020-2555 补丁的绕过,CVE-2020-2555 的修复方法中修改了 Limitfiler.toString 方法,也就是说修改了一个调用 ValueExtractor.extract 方法的地方。 而 CVE-2020-2883 则找到另一个调用 ValueExtractor.extract 的地方,也就是 ExtractorComparator.compare

ExtratorComparator.compare 中存在任意(因为 this.m_extractor 参与序列化和反序列化) ValueExtractorextract 方法调用。

Comparator.compare 方法,则可以通过 CC2 中用到的PriorityQueue.readObject` 来触发。

另外在 weblogic 中, BadAttributeValueExpException.readObject 中也可以实现调用任意 compartor.compare方法:

涉及 CVE

CVE-2020-2883,修复方法是将 ReflectionExtractorMvelExtractor 加入了黑名单 。

CVE-2020-14645 使用 com.tangosol.util.extractor.UniversalExtractor 绕过,修复方法将 UniversalExtractor 加入黑名单。

CVE-2020-14825,CVE-2020-14841 使用 oracle.eclipselink.coherence.integrated.internal.cache.LockVersionExtractor.LockVersionExtractor 进行绕过。

ExternalizableHelper

在分析ExternalizableHelper 利用链架构的时候,我们依然可以把链分为四部分,一个是链头,一个是危险的中间的节点(漏洞点),另一个是调用危险中间节点的地方(触发点),最后一个则是利用这个节点去造成危害的链尾。

ExternalizableHelper 利用链架构中,这个危险的中间节点就是 ExternalizableLite.readExternal 方法。

weblogic 对于反序列化类的过滤都是在加载类时进行的,因此在 ExternalizableHelper.readExternalizableLite 中加载的 class 是不受黑名单限制的。

具体原因是:weblogic 黑名单是基于 jep 290 ,jep 290 是在 readObject 的时候,在得到类名后去检查要反序列化的类是否是黑名单中的类。而这里直接使用的 loadClass 去加载类,所以这里不受 weblogic 黑名单限制。(也可以这么理解: jep 290 是针对在反序列化的时候,通过对要加载类进行黑名单检查。而这里直接通过 loadClass 加载,并没有通过反序列化,和反序列化是两码事,当然在后续 readExternal 的时候还是受 weblogic 黑名单限制,因为走的是反序列化那一套)

weblogic 黑名单机制可以参考:https://cert.360.cn/report/detail?id=c8eed4b36fe8b19c585a1817b5f10b9e,https://cert.360.cn/report/detail?id=0de94a3cd4c71debe397e2c1a036436f,https://www.freebuf.com/vuls/270372.html

漏洞点

PartialResult

com.tangosol.util.aggregator.TopNAggregator.PartialResultreadExternal 会触发任意 compartor.compare 方法。

大致原理:

在 182 行会把comparator 作为参数传入 TreeMap 的构造函数中。

然后186 行,会调用 this.add ,this.add 会调用 this.m_map.put 方法,也就是说调用了 TreeMap 的 put 方法,这就导致了 comparator.compare()的调用。

具体分析见:https://mp.weixin.qq.com/s/E-4wjbKD-iSi0CEMegVmZQ

然后调用 comparator.compare 就可以接到 ExtractorComparator.compare 那里去了,从而实现 rce 。

涉及 CVE

CVE-2020-14756 (1月)

ExternalizableHelper 的利用第一次出现是在 CVE-2020-14756 中。利用的正是 ExternalizableHelper 的反序列化通过 loadClass 加载类,所以不受 weblogic 之前设置的黑名单的限制。具体利用可以参考:https://mp.weixin.qq.com/s/E-4wjbKD-iSi0CEMegVmZQ

CVE-2020-14756 的修复方法则是对 readExternalizable 方法传入的 Datainput 检查,如果是 ObjectInputStream 就调用 checkObjectInputFilter() 进行检查,checkObjectInputFilter 具体是通过 jep290 来检查的。

CVE-2021-2135 (4月)

上面补丁的修复方案 只是检查了 DataInputObjectInputStream 的情况, 却没有过滤其他 DataInput 类型 。

那我们只需要找其他调用 readExternalizableit 函数的地方,并且传入的参数不是 ObjectInputStream 就可以了。【ObjectInputStream 一般是最常见的,通常来说是 readObject =>readObjectInternal =>readExternalizableite 这种链,也就是上游是常见的 readObject, 所以补丁就可能只注意到ObjectInputStream 的情况。】

所以CVE-2021-2135 绕过的方法就是设置传入 readExternalizableite 函数的参数类型为 BufferInput 来进行绕过。

ExternalizableHelper 中调用 readObjectInternal 的地方有两处,一处是 readObjectInternal , 另一处则是 deserializeInternal 。而 deserializeInternal 会先把 DataInput 转化为 BufferInut

所以只要找调用 ExternalizableHelper .deserializeInternal 的地方。

ExternalizableHelper.fromBinary (和 ExternalizableHelper.readObject 平级的关系 )里就调用了 deserializeInternal , 所以只需要找到一个地方用 来 ExternalizableHelper.fromBinary 来反序列化就可以接上后面的(CVE-2020-14756)利用链了。

然后就是找 调用了 ExternalizableHelper.fromBinary 的方法的地方。SimpleBinaryEntry 中的 getKeygetValue方法中存在 ExternalizableHelper.fromBinary 的调用,所以就只要找到调用 getKeygetValue 的地方就可以了。

然后在 com.sun.org.apache.xpath.internal.objects.XString重写的equals方法里调用了 tostring ,在 tostring 中调用了 getKey 方法。

ExternalizableHelper#readMap 中会调用 map.putmap.put 会调用 equals 方法。

com.tangosol.util.processor.ConditionalPutAllreadExteranl 中调用了 ExternalizableHelper#readMap 方法。

然后再套上 AttributeHolder 链头就可以了。

具体可以参考:https://mp.weixin.qq.com/s/eyZfAPivCkMbNCfukngpzg

4月漏洞修复则是:

1.添加simpleBianry 到黑名单。

2.设置了白名单:

private static final Class[] ABBREV_CLASSES = new Class[]{String.class, ServiceContext.class, ClassTableEntry.class, JVMID.class, AuthenticatedUser.class, RuntimeMethodDescriptor.class, Immutable.class};

filterExtractor

filterExtractor.reaExternal 方法中的 readAttributeAccessor() 方法会直接 new 一个 MethodAttributeAccessor 对象。

随后在 filterExtractor.extract 函数中会因为调用 this.attributeAccessor.getAttributeValueFromObject 进而导致任意无参方法的调用。

涉及 CVE

CVE-2021-2394 (4月)

在4月的补丁中,对 ois 的 DataInput 流进行了过滤,所以直接通过 newInstance 实例化恶意类的方式已经被阻止(CVE-2021-2135 通过 bufferinputStream 进行了绕过),所以需要重新寻找其他不在黑名单中的 readExternal 方法。

CVE-2021-2394 中就是利用 filterExtractor.readExternal 来进行突破。

具体可以参考:https://blog.riskivy.com/weblogic-cve-2021-2394-rce%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/https://www.cnblogs.com/potatsoSec/p/15062094.html

触发点

ExternalizableHelper.readExternal 的触发点有 ExternalizableHelper.readObjectExternalizableHelper.fromBinary 这两个。其中 CVE-2021-2135 则就是因为在 CVE-2020-14756 的修复方法中,只注意到了 ExternalizableHelper.readObject ,只在ExternalizableHelper.readObject 里面做了限制,但是没有考虑到 ExternalizableHelper.fromBinary 从而导致了绕过。

ExternalizableHelper.readObject可以利用 com.tangosol.coherence.servlet.AttributeHolder来触发,com.tangosol.coherence.servlet.AttributeHolder 实现了 java.io.Externalizabe 接口,并且他的readExternal 方法 调用了 ExternalizableHelper.readObject(in)

ExternalizableHelper.fromBinary 的触发则较为复杂一些,具体可以参考:https://mp.weixin.qq.com/s/eyZfAPivCkMbNCfukngpzg

 

后记

weblogic Coherence 反序列化漏洞很多都是相关联的,对于某个漏洞,很可能就是用到了之前一些漏洞的链子。其实不仅仅 weblogic ,java 其他反序列化链也是如此,很多情况都是一个链会用到其他链的一部分。所以在学习中,把一个组件或者一个库的漏洞总结起来一起分析还是比较重要的,最后希望这篇文章能帮助到其他一起学反序列化的朋友们。

 

参考

https://nosec.org/home/detail/4524.html

https://cloud.tencent.com/developer/article/1740557

https://blog.riskivy.com/weblogic-cve-2021-2394-rce%E6%BC%8F%E6%B4%9E%E5%88%86%E6%9E%90/

https://www.cnblogs.com/potatsoSec/p/15062094.html

https://cert.360.cn/report/detail?id=c8eed4b36fe8b19c585a1817b5f10b9e

https://cert.360.cn/report/detail?id=0de94a3cd4c71debe397e2c1a036436f

https://www.freebuf.com/vuls/270372.html

https://mp.weixin.qq.com/s/E-4wjbKD-iSi0CEMegVmZQ

https://mp.weixin.qq.com/s/eyZfAPivCkMbNCfukngpzg

本文由白帽汇安全研究院原创发布

转载,请参考转载声明,注明出处: https://www.anquanke.com/post/id/249677

安全客 - 有思想的安全新媒体

分享到:微信
+10赞
收藏
白帽汇安全研究院
分享到:微信

发表评论

内容需知
合作单位
  • 安全客
  • 安全客
Copyright © 北京奇虎科技有限公司 三六零数字安全科技集团有限公司 安全客 All Rights Reserved 京ICP备08010314号-66