Orange：微软Exchange的新攻击面第一部分 - ProxyLogon！

作者声明

这是Orange在发言 :)

文章信息

2021年8月6日 星期五

正文

新的Exchange攻击面系列

微软Exchange作为全球最常见的电子邮件解决方案之一，已成为政府和企业日常运营和安全连接的一部分。今年一月，我们向微软报告了Exchange服务器的一系列漏洞，并将其命名为ProxyLogon。ProxyLogon可能是Exchange历史上最严重和最具影响力的漏洞。

从架构层面研究ProxyLogon时，我们发现它不仅仅是一个漏洞，而是一个全新的、从未被提及过的攻击面。这个攻击面可能导致黑客或安全研究人员发现更多漏洞。因此，我们决定专注于这个攻击面，最终发现了至少8个漏洞。这些漏洞涵盖服务器端、客户端甚至加密错误。我们将这些漏洞串联成3种攻击：

• ProxyLogon：最知名和最具影响力的Exchange利用链
• ProxyOracle：可恢复Exchange用户明文密码的攻击
• ProxyShell：我们在Pwn2Own 2021演示的利用链，接管Exchange并获得20万美元奖金

需要强调的是，我们披露的所有漏洞都是逻辑错误，这意味着它们比任何内存损坏错误都更容易复现和利用。

漏洞披露时间表

[1] 与此新攻击面直接相关的错误 [2] Pwn2Own 2021错误

为什么针对Exchange服务器？

邮件服务器是持有最机密秘密和公司数据的高价值资产。换句话说，控制邮件服务器意味着控制公司的生命线。作为最常用的电子邮件解决方案，Exchange服务器长期以来一直是黑客的首要目标。根据我们的研究，互联网上暴露了超过40万台Exchange服务器。每台服务器代表一家公司，你可以想象当Exchange服务器出现严重漏洞时会有多可怕。

新攻击面在哪里？

Exchange是一个非常复杂的应用程序。自2000年以来，Exchange每3年发布一个新版本。每当Exchange发布新版本时，架构都会发生很大变化。架构的变化和迭代使得升级Exchange服务器变得困难。为了确保新架构与旧架构之间的兼容性，Exchange服务器产生了一些设计债务，导致了我们发现的新攻击面。

我们专注于微软Exchange的客户端访问服务（CAS）。CAS是Exchange的基本组件。回到2000/2003版本，CAS是一个独立的前端服务器，负责所有前端Web渲染逻辑。经过多次重命名、集成和版本差异，CAS已降级为邮箱角色下的服务。

CAS架构

CAS是负责接受来自客户端的所有连接的基本组件，无论是HTTP、POP3、IMAP还是SMTP，并将连接代理到相应的后端服务。

CAS Web建立在Microsoft IIS上。IIS内部有两个网站。“默认网站"是我们之前提到的前端，“Exchange后端"是业务逻辑所在的位置。仔细查看配置后，我们注意到前端绑定端口80和443，后端监听端口81和444。所有端口都绑定到0.0.0.0，这意味着任何人都可以直接访问Exchange的前端和后端。

Exchange通过IIS模块实现前端和后端的逻辑。前端和后端有几个模块来完成不同的任务，如过滤器、验证和日志记录。前端必须包含一个代理模块。代理模块从客户端获取HTTP请求并添加一些内部设置，然后将请求转发到后端。至于后端，所有应用程序都包括重新水合模块，该模块负责解析前端请求，将客户端信息重新填充，并继续处理业务逻辑。

攻击面

在简要介绍了CAS的架构之后，我们现在意识到CAS只是一个编写良好的HTTP代理（或客户端），我们知道实现代理并不容易。所以我想知道：

我能否使用单个HTTP请求分别访问前端和后端的不同上下文，从而引起一些混淆？

如果我们能做到这一点，也许我可以绕过一些前端限制来访问任意后端并滥用一些内部API。或者，我们可以利用混淆上下文来利用前端和后端之间危险HTTP头定义的不一致性来进行更有趣的攻击。

ProxyLogon

第一个利用是ProxyLogon。如前所述，这可能是Exchange历史上最严重的漏洞。ProxyLogon由2个错误串联而成：

• CVE-2021-26855 - 预认证SSRF导致认证绕过
• CVE-2021-27065 - 认证后任意文件写入导致RCE

CVE-2021-26855 - 预认证SSRF

前端中有20多个处理程序对应不同的应用程序路径。在审查实现时，我们发现静态资源处理程序中的GetTargetBackEndServerUrl方法直接通过cookie分配后端目标。

从代码片段中，您可以看到AnchoredRoutingTarget的BackEndServer.Fqdn属性直接从cookie分配。

虽然我们只能控制URL的Host部分，但是等等，操纵URL解析器不正是我擅长的吗？Exchange通过内置的UriBuilder构建后端URL。然而，由于C#没有验证Host，我们可以用一些特殊字符包围整个URL来访问任意服务器和端口。

到目前为止，我们有一个超级SSRF，可以控制几乎所有的HTTP请求并获取所有回复。最令人印象深刻的是，Exchange的前端会为我们生成Kerberos票据，这意味着即使我们在攻击受保护且加入域的HTTP服务时，仍然可以使用Exchange机器帐户的身份验证进行黑客攻击。

CVE-2021-27065 - 认证后任意文件写入

多亏了超级SSRF允许我们无限制地访问后端。接下来是找到一个RCE错误来串联在一起。这里我们利用后端内部API /proxyLogon.ecp来成为管理员。这个API也是我们称之为ProxyLogon的原因。

由于我们利用静态资源的前端处理程序访问ECP后端，ECP后端中的特殊HTTP头msExchLogonMailbox不会被前端阻止。通过利用这种微小不一致，我们可以将自己指定为SYSTEM用户，并通过内部API生成有效的ECP会话。

利用前端和后端之间的不一致，我们可以通过Header伪造和内部后端API滥用访问ECP上的所有功能。接下来，我们必须在ECP接口上找到一个RCE错误来将它们串联在一起。ECP通过/ecp/DDI/DDIService.svc将Exchange PowerShell命令包装为抽象接口。

在验证DDI实现时，我们发现WriteFileActivity的标签没有正确检查文件路径，导致任意文件写入。

有几种路径可以触发任意文件写入漏洞。这里我们使用ResetOABVirtualDirectory.xaml作为示例，并将Set-OABVirtualDirectory的结果写入webroot作为我们的Webshell。

现在我们有一个可工作的预认证RCE利用链。未经身份验证的攻击者可以通过暴露的443端口在Microsoft Exchange服务器上执行任意命令。

结语

作为本系列的第一篇博客，ProxyLogon完美展示了这个攻击面可能有多严重。我们还有更多示例即将发布。敬请期待！