前言

生活让我们兜兜转转离别再相遇，漏洞也是。2022我们又与Exchange相遇，此为 反序列化漏洞分析系列第二篇。

0x01 漏洞简介

Exchange 发布 2022 年三月份补丁，包含一个 RCE 漏洞，diff 2022.1.7 的 KB5008631 和 2022.3.7 的 KB5012698，尝试寻找漏洞。

1.1 影响版本

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

微软官方发布的影响版本如上，但如果能找到其他的反序列化触发点，可能将影响更多版本。

1.2 所需条件

根据不同的反序列化触发点，条件不同。比如使用 CVE-2021-42321 的触发点，条件为：

1.普通用户权限2./ews 可用

0x02 漏洞详情

CVE-2022-23277 是针对 ChainedSerializationBinder.GlobalDisallowedTypesForDeserialization 黑名单的完全绕过，利用该漏洞可以反序列化任意恶意类。

2.1 漏洞分析

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)，导致黑名单被完全绕过，形同虚设。

2.2 漏洞利用

CVE-2022-23277 完全绕过了黑名单，只要找到任意稳定的反序列化触发点即可利用，比如 CVE-2021-42321。

0x03 修复方式

如分析所示，对 type 为空的情况进行异常处理。

0x04 总结

Exchange 历史上存在比较知名的反序列化漏洞仅三四个，且各漏洞合集并不能覆盖所有大版本、小版本累积更新、安全更新，比如 CVE-2021-42321 只影响 2016 CU21/22 和 2019 CU10/11。鉴于 CVE-2022-23277 对引入 ChainedSerializationBinder() 后的所有 Exchange 版本都将造成影响，如果能挖掘出更多的反序列化触发点，也许能影响历史上更多版本 Exchange。

这么做是有意义的，毕竟实战中有遇到过低版本的 Exchange 反而无法利用的情况。

红队武器化展示：