网络安全【漏洞安全】反序列化漏洞深入分析_网络安全binary comparison

前言

本文将介绍下如何 diff WebLogic 的补丁，以及在跟踪补丁的过程中对可能存在的一种绕过黑名单的反序列化手法的介绍。

T3 和 IIOP

以下漏洞均基于 T3 和 IIOP 作为入口触发，所以需要简单分析下 T3 和 IIOP 是如何反序列化的，以及 WebLogic 如何进行修复。

T3 的反序列化是基于原生的反序列化实现。

打了补丁之后：

【一一帮助安全学习，所有资源获取处一一】

①网络安全学习路线

②20 份渗透测试电子书

③安全攻防 357 页笔记

④50 份安全攻防面试指南

⑤安全红队渗透工具包

⑥网络安全必备书籍

⑦100 个漏洞实战案例

⑧安全大厂内部视频资源

⑨历年 CTF 夺旗赛题解析

IIOP 的反序列化是由 WebLogic 自身实现的：

在 this.readIndirectingRepositoryId(codebase); 进行黑名单过滤：

CVE 早期 分析

WebLogic 在早期修复 T3 和 IIOP 的反序列化都是采用黑名单的方式修复，黑名单可以是类名，也可以是包名，以下是截止到 202110 的黑名单的列表，想要跟踪 WebLogic 的 CVE,首先要做的就是看补丁把谁拉进黑名单了。

javaorg.apache.commons.collections.functorscom.sun.org.apache.xalan.internal.xsltc.traxjavassistjava.rmi.activationsun.rmi.serverorg.jboss.interceptor.builderorg.jboss.interceptor.readerorg.jboss.interceptor.proxyorg.jboss.interceptor.spi.metadataorg.jboss.interceptor.spi.modelcom.bea.core.repackaged.springframework.aop.aspectjcom.bea.core.repackaged.springframework.aop.aspectj.annotationcom.bea.core.repackaged.springframework.aop.aspectj.autoproxycom.bea.core.repackaged.springframework.beans.factory.supportorg.python.corecom.bea.core.repackaged.aspectj.weaver.tools.cachecom.bea.core.repackaged.aspectj.weaver.toolscom.bea.core.repackaged.aspectj.weaver.reflectcom.bea.core.repackaged.aspectj.weavercom.oracle.wls.shaded.org.apache.xalan.xsltc.traxoracle.eclipselink.coherence.integrated.internal.queryingoracle.eclipselink.coherence.integrated.internal.cacheorg.codehaus.groovy.runtime.ConvertedClosureorg.codehaus.groovy.runtime.ConversionHandlerorg.codehaus.groovy.runtime.MethodClosureorg.springframework.transaction.support.AbstractPlatformTransactionManagerjava.rmi.server.UnicastRemoteObjectjava.rmi.server.RemoteObjectInvocationHandlercom.bea.core.repackaged.springframework.transaction.support.AbstractPlatformTransactionManagerjava.rmi.server.RemoteObjectcom.tangosol.coherence.rest.util.extractor.MvelExtractorjava.lang.Runtimeoracle.eclipselink.coherence.integrated.internal.cache.LockVersionExtractororg.eclipse.persistence.internal.descriptors.MethodAttributeAccessororg.eclipse.persistence.internal.descriptors.InstanceVariableAttributeAccessororg.apache.commons.fileupload.disk.DiskFileItemorg.jboss.weld.interceptor.builder.MethodReferenceorg.jboss.weld.interceptor.spi.metadata.MethodMetadataoracle.jdbc.pool.OraclePooledConnectioncom.google.common.util.concurrent.AtomicDoubleArraycom.tangosol.internal.util.invokecom.tangosol.internal.util.invoke.lambdacom.tangosol.coherence.rest.util.extractorcom.tangosol.coherence.rest.utilcom.tangosol.util.extractorcom.tangosol.coherence.component.application.consolecom.tangosol.util.extractor.ReflectionExtractorcom.tangosol.internal.util.SimpleBinaryEntrycom.tangosol.util.extractor.ComparisonValueExtractorcom.tangosol.util.extractor.ConditionalExtractorcom.tangosol.util.extractor.ReflectionUpdatercom.tangosol.util.extractor.ScriptValueExtractorcom.tangosol.util.extractor.UniversalExtractorcom.tangosol.util.extractor.UniversalUpdatercom.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.partitionedService.PartitionedCache$Storage$BinaryEntry

复制代码

WebLogic 修复 CVE-2020-14644 的方式是将 com.tangosol.internal.util.invoke.RemoteConstructor 拉入了黑名单，简单跟踪下 RemoteConstructor 的反序列化过程，看看是因为什么原因被拉进黑名单。

发现存在 readResolve 方法，该方法会在反序列化后执行。

CVE-2020-14756 分析

WebLogic 修复 CVE-2020-14644 的方式，是将黑名单加进 com.tangosol.util.ExternalizableHelper#readExternalizableLite 方法中。

结合这个信息，可以肯定是在调用这个方法进行反序列化绕过了黑名单，才导致了这次补丁修补。往上追溯，观察下 WebLogic 的黑名单规则和为啥能够绕过黑名单。

以 IIOP 为例子，进入到 WebLogic.iiop.IIOPInputStream#read_value(Class clz) 即开始反序列化操作。在进入反序列化操作前，先进入一个 switch，进入 readIndirectingRepositoryId 方法。

最终来到 getClassFromID 方法，进入黑名单判断。

判断完毕，回到 read_value 方法，进行反序列化操作。

选择不同的反序列化方法，最终执行 readResolve 方法，重新进入到上述轮回。

上述比较抽象，想要理解，必须明白反序列化是一个链式的操作。比如，你有一个类 A，类里面有个属性是类 B，这个时候，在反序列化的过程中，就会先反序列化类 A，之后在填充类 A 的过程中，继续反序列化类 B，类 B 在反序列化完成后，填充到类 A 中，同时整个过程都在一个流中操作，这个时候，只要还是 ObjectOutStream 的 read_value 进行反序列化操作就不能绕过黑名单！

回到 readExternalizableLite 向外拓展，很容易发现继承 ExternalizableLite 接口的都有一个新的反序列化方法 readExternal(DataInput in)，这个方法传入的流是 DataInput。根据补丁也很容易猜想出这个流反序列化过程都是在 ExternalizableHelper#readExternalizableLite 实现的，现在主要是找到一个 ObjectInput 流转换到 DataInput 的反序列化利用链。

找到一个很符合的类 com.tangosol.net.security.PermissionInfo，入口是 ObjectInput，之后会进入 readCollection 方法。

在 readCollection 方法中隐式转换成 DaraInput 流，后面传入 readObject。

在 readObject 方法中进行 ExternalizableHelper 自身实现的反序列化，这样就突破了黑名单，实现了 RCE。

当然，这样的修复方式并不彻底，因为他先判断了流是否是 ObjectInputStream，这就给绕过黑名单给了一个可乘之机，于是诞生了 CVE-2021-2136。

CVE-2021-2136 分析

照例，从补丁中发现 WebLogic 将 com.tangosol.internal.util.SimpleBinaryEntry 类拉进了黑名单，看下这个类是做什么的。

readExternal 方法中，没有啥操作，但是他在 getKey 和 getValue 中出现了高危操作。

跟进 ExternalizableHelper.fromBinary 一看，便明白这是一个二阶反序列化操作。

追踪 BufferInput 可以发现，他并不继承 ObjectInputStream，所以从 fromBinary 进行的反序列化绕过了黑名单的限制。

因为最终的利用方法不在 readExternal 方法中，需要构造一条调用链，同时需要注意 SimpleBinaryEntry 仅在 readExternal 中能获取 binkey 和 binvalue 的值。

根据 PermissionInfo 到 SimpleBinaryEntry 构造一条通路，最终二阶反序列化 RemoteConstructor 类进行 RCE。

String SIGALG = "SHA1withRSA";

复制代码

​总结: 一个渐变的过程

根据上述的漏洞分析,可以发现后续漏洞都是构造条件绕过黑名单触发第一个漏洞，并且从最开始的直接反序列化触发，到后面开始使用二阶反序列化的手段进行利用，好像在进行一种微妙的攻防的对抗，并且从后面 2 个 CVE 中，发现了绕过黑名单的可能性。

如果能将 ObjectInput 转化成其他的数据流并且能进行反序列化，那就可能绕过黑名单。

新的开始

查找 fromBinary 的二阶反序列化的点，JD 搜索整个 coherence.jar 包使用了 fromBinary 的类,配合 tabby 进行搜索，最终发现了一个特点: 继承com.oracle.common.base.Converter 的类,在实现的 convert 方法中,大多数都会使用 fromBinary 方法处理传入的 Object。

回到整个 coherence.jar，继续一顿猛搜，调用了 convert 方法的类,最终找到一个适合的类com.tangosol.coherence.transaction.internal.storage.KeyBackingMap。

接下来，需要找到适合 context。context 需要满足以下几个条件:

1、必须是 BackingMapManagerContext 的子类。

2、getValueFromInternalConverter 或者 getKeyFromInternalConverter 方法必须是正常并且返回的是 Converter 的子类。

3、需要存在 isKeyOwned 方法。

围绕上述条件一顿猛搜，最终找到一个适合的类com.tangosol.coherence.component.util.daemon.queueProcessor.service.grid.ReplicatedCache$BackingMapContext。

getConverterFromInternal 方法中，调用了 this.getService 方法。查看这个方法，返回的是一个 ReplicatedCache 对象。

查看 ReplicatedCache 类，可以被反序列化。

构造好了 KeyBackingMap 的反序列化条件，接下来是寻找到达 KeyBackingMap.put 的利用链，看到 map.put，就记起了 CC5 的利用链。

马上构造一个利用链发送给 WebLogic，结果很让人遗憾，C** 不在当前的 ClassLoader。陷入了僵局，重新思考整个利用链，发现只卡死在 lazyMap 这个类中，lazyMap 必须要 Transformer 类，导致反序列化时进入黑名单。

只能回到 coherence.jar 包中，继续搜索替换 lazyMap 的类。这个类必须满足以下条件：

1、可反序列化

2、继承 Map

3、get 方法能调用另一个 map 的 put 方法

这个时候，想起了师傅，师傅给了一条绕过 LazyMap 的类。

复现师傅的思路，通过 tabby 工具,果然找到了 DeltaMap 类。

构造好新的 gadget，本地测试成功。

发送给没打白名单补丁的 WebLogic12c 成功。

使用 IIOP 反序列化失败 !!

跟踪失败的原因，发现在 IIOP 反序列化父类的时候，会进入 OnInit 进行类的初始化，初始化过程出错就会中断反序列化过程。

     题外话

初入计算机行业的人或者大学计算机相关专业毕业生，很多因缺少实战经验，就业处处碰壁。下面我们来看两组数据：

• 2023届全国高校毕业生预计达到1158万人，就业形势严峻；

• 国家网络安全宣传周公布的数据显示，到2027年我国网络安全人员缺口将达327万。

一方面是每年应届毕业生就业形势严峻，一方面是网络安全人才百万缺口。

6月9日，麦可思研究2023年版就业蓝皮书（包括《2023年中国本科生就业报告》《2023年中国高职生就业报告》）正式发布。

2022届大学毕业生月收入较高的前10个专业

本科计算机类、高职自动化类专业月收入较高。2022届本科计算机类、高职自动化类专业月收入分别为6863元、5339元。其中，本科计算机类专业起薪与2021届基本持平，高职自动化类月收入增长明显，2022届反超铁道运输类专业（5295元）排在第一位。

具体看专业，2022届本科月收入较高的专业是信息安全（7579元）。对比2018届，电子科学与技术、自动化等与人工智能相关的本科专业表现不俗，较五年前起薪涨幅均达到了19%。数据科学与大数据技术虽是近年新增专业但表现亮眼，已跻身2022届本科毕业生毕业半年后月收入较高专业前三。五年前唯一进入本科高薪榜前10的人文社科类专业——法语已退出前10之列。

“没有网络安全就没有国家安全”。当前，网络安全已被提升到国家战略的高度，成为影响国家安全、社会稳定至关重要的因素之一。

网络安全行业特点

1、就业薪资非常高，涨薪快 2021年猎聘网发布网络安全行业就业薪资行业最高人均33.77万！

2、人才缺口大，就业机会多

2019年9月18日《中华人民共和国中央人民政府》官方网站发表：我国网络空间安全人才 需求140万人，而全国各大学校每年培养的人员不到1.5W人。猎聘网《2021年上半年网络安全报告》预测2027年网安人才需求300W，现在从事网络安全行业的从业人员只有10W人。

行业发展空间大，岗位非常多

网络安全行业产业以来，随即新增加了几十个网络安全行业岗位︰网络安全专家、网络安全分析师、安全咨询师、网络安全工程师、安全架构师、安全运维工程师、渗透工程师、信息安全管理员、数据安全工程师、网络安全运营工程师、网络安全应急响应工程师、数据鉴定师、网络安全产品经理、网络安全服务工程师、网络安全培训师、网络安全审计员、威胁情报分析工程师、灾难恢复专业人员、实战攻防专业人员…

职业增值潜力大

网络安全专业具有很强的技术特性，尤其是掌握工作中的核心网络架构、安全技术，在职业发展上具有不可替代的竞争优势。

随着个人能力的不断提升，所从事工作的职业价值也会随着自身经验的丰富以及项目运作的成熟，升值空间一路看涨，这也是为什么受大家欢迎的主要原因。

从某种程度来讲，在网络安全领域，跟医生职业一样，越老越吃香，因为技术愈加成熟，自然工作会受到重视，升职加薪则是水到渠成之事。

       如果你对网络安全入门感兴趣，那么你点击这里

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/小丑西瓜9/article/detail/450737