生活让我们兜兜转转离别再相遇,漏洞也是。2022我们又与Exchange相遇,此为 反序列化漏洞分析系列第二篇。
Exchange 发布 2022 年三月份补丁,包含一个 RCE 漏洞,diff 2022.1.7 的 KB5008631 和 2022.3.7 的 KB5012698,尝试寻找漏洞。
Exchange Server 2016 CU22 <= Jan22SU 15.1.2375.18 15.01.2375.018
Exchange Server 2016 CU21 <= Jan22SU 15.1.2308.21 15.01.2308.021
Exchange Server 2019 CU11 <= Jan22SU 15.2.986.15 15.02.0986.015
Exchange Server 2019 CU10 <= Jan22SU 15.2.922.20 15.02.0922.020
Exchange Server 2013 CU23 <= Jan22SU 15.0.1497.28 15.00.1497.028
微软官方发布的影响版本如上,但如果能找到其他的反序列化触发点,可能将影响更多版本。
根据不同的反序列化触发点,条件不同。比如使用 CVE-2021-42321 的触发点,条件为:
1.普通用户权限2./ews 可用
CVE-2022-23277 是针对 ChainedSerializationBinder.GlobalDisallowedTypesForDeserialization
黑名单的完全绕过,利用该漏洞可以反序列化任意恶意类。
Exchange 中,.Net 反序列化是 RCE 的重灾区,因此重点关照下 ChainedSerializationBinder
。
diff 补丁,第一眼看到新增了很多黑名单:
理论上来说,从新增的黑名单里可以逆向出一些 Gadgets 链,不过微软在这里修复了一个更大的漏洞。往下看,在 LoadType()
的结尾,新增了 type == null
时抛出异常的操作:
LoadType()
在 ValidateTypeToDeserialize(type)
前调用,如果其返回的 type 为空,那么就不会调用 ValidateTypeToDeserialize(type)
进行黑名单检查:
漏洞的关键在于如何让 LoadType()
返回的 type
为空。type
由字符串直接拼接,字符串来自于反序列化数据,用户完全可控。但是如果随意设置 typeName
和 assemblyName
,数据将无法被正确反序列化。经测试发现,可以通过00截断 typeName
,让 GetType()
返回空,并且不会影响反序列化过程。
至此,程序不会进入 ValidateTypeToDeserialize(type)
,导致黑名单被完全绕过,形同虚设。
CVE-2022-23277 完全绕过了黑名单,只要找到任意稳定的反序列化触发点即可利用,比如 CVE-2021-42321。
如分析所示,对 type
为空的情况进行异常处理。
Exchange 历史上存在比较知名的反序列化漏洞仅三四个,且各漏洞合集并不能覆盖所有大版本、小版本累积更新、安全更新,比如 CVE-2021-42321 只影响 2016 CU21/22 和 2019 CU10/11。鉴于 CVE-2022-23277 对引入 ChainedSerializationBinder()
后的所有 Exchange 版本都将造成影响,如果能挖掘出更多的反序列化触发点,也许能影响历史上更多版本 Exchange。
这么做是有意义的,毕竟实战中有遇到过低版本的 Exchange 反而无法利用的情况。
红队武器化展示:
默安科技刃甲网络攻击干扰压制系统已升级最新规则,支持对利用该漏洞的攻击监测与自动化阻断。
如有相关需求,请致电:0571-57890068