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现在安全了吗？
当然不是，本文就是为了证明这一点！由于微软只修复了有问题的代码，我们在POC 2021和HITCON 2021的演讲中提出了几种攻击和可能的弱点。
也许您已经听说我们的第一个预测已经在最近的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前端
- 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的前端。由于中继身份验证的身份是拥有Token-Serialization权限的Exchange的机器账户，我们可以模拟任何用户！这里我们以中继从EX01到EX02前端EWS服务的NTLM身份验证作为展示。我们通过自定义httpattack.py实现了中继到前端EWS的攻击！以下是一个简单的概述：
- 在ATTACKER服务器上运行ntlmrelayx.py以等待NTLM身份验证。
- 使用printerbug.py强制EX01启动到ATTACKER的SMB连接。
- 在ATTACKER上接收SMB连接，并将NTLM blob中继到EX02。
- 完成NTLM握手以完全访问EWS端点。
|
|
理论上，我们可以通过EWS操作接管目标邮箱。这里我们提供了一个演示来转储管理员邮箱下的秘密。
修补前端
微软分配了CVE-2021-33768，并在2021年7月发布了一个补丁来修复前端可中继的问题。由于以前端机器账户登录不是常规操作，通过在前端代理处理程序上添加检查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操作任何用户的邮箱。整个攻击可以说明为以下步骤：
- 为RPC I/O建立到EX02的RCP_IN_DATA和RCP_OUT_DATA通道。
- 在EX01上触发PrinterBug并中继到EX02以完成NTLM握手。
- 在HTTP头中附加X-CommonAccessToken头以指示我们在两个HTTP头上都是Exchange管理员。
- 通过基于MS-OXCRPC和MS-OXCROPS在MS-RPCH上的大量编码工作与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截图已经暗示了一切，并且足以重现。过程可以说明如下：
- 强制EX01启动连接，并将NTLM中继到EX02的Endpoint Mapper（端口135）以获取MMC20.Application的接口。
- 再次强制EX01，并将NTLM中继到EPMapper分配的动态端口，并在iMMC->Document->ActiveView下调用ExecuteShellCommand(…)。
- 运行任意命令以获取乐趣和利润！
编写整个漏洞利用很有趣，就像将dcomexec.py和ntlmrelayx.py混合在一起。对于那些想更深入了解DCOM机制的人，建议亲手编写自己的漏洞利用代码！
修补DCOM
微软分配了CVE-2021-26414，并在2021年6月修补了这个DCOM中继。然而，由于兼容性，服务器端的强化默认禁用。服务器管理员必须通过创建以下注册表项手动激活补丁。如果服务器管理员没有仔细阅读文档，他的Exchange Server在6月补丁后可能仍然易受攻击。
|
|
至于何时在服务器端强制执行保护？根据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回复说他们目标将