如何使用流氓 PowerShell 代码破解未打补丁的 Exchange 服务器

就在不到两个月前，一些令人担忧的错误消息爆出：Microsoft Exchange 中公布了两个零日漏洞。

正如我们 当时建议，这些漏洞，官方指定 CVE-2022-41040 和 CVE-2022-41082:

[是] 两个 [可以] 链接在一起的零日漏洞，第一个漏洞被远程使用以打开足够的漏洞来触发第二个漏洞，这可能允许在 Exchange 服务器本身上执行远程代码 (RCE)。

第一个漏洞让人联想到麻烦且被广泛滥用的 ProxyShell 安全漏洞 从 2021 年 XNUMX 月开始，因为它依赖于 Exchange 自动发现功能中的危险行为， 微软描述的 作为协议 “由 Outlook 和 EAS [Exchange ActiveSync] 客户端用来查找和连接到 Exchange 中的邮箱”.

幸运的是，任何远程用户（无论是否登录）都可以在 ProxyShell 攻击中利用的自动发现错误功能是 一年多以前打过补丁.

不幸的是，ProxyShell 补丁没有做足够的工作来关闭对经过身份验证的用户的利用，导致新的 CVE-2022-40140 零日漏洞，如果误导的话，它很快就会简洁明了， 配音 代理非Shell.

没有那么危险，但仍然很危险

显然，ProxyNotShell 远没有原来的 ProxyShell 危险，因为它需要所谓的身份验证访问，所以它不会被来自任何地方的任何人滥用。

但很快发现，在许多 Exchange 服务器上，知道任何用户的登录名和密码就足以通过身份验证并发动这种攻击，即使该用户自己需要使用双因素身份验证 (2FA) 才能正确登录以访问他们的电子邮件。

作为 Sophos 专家 Chester Wisniewski 把它 当时：

如果您想这样称呼它，它就是一个“身份验证过程中的漏洞”。 这是喜忧参半。 这确实意味着自动化的 Python 脚本不能只扫描整个互联网并可能在几分钟或几小时内利用世界上的每台 Exchange 服务器，正如我们在 2021 年看到的 ProxyLogon 和 ProxyShell 所发生的那样。 […]

您需要一个密码，但不幸的是，找到一个在任何给定 Exchange 服务器上有效的电子邮件地址和密码组合可能并不难。 到目前为止，您可能还没有被利用，因为要成功登录到 Outlook Web Access [OWA] 需要他们的 FIDO 令牌，或者他们的身份验证器，或者您可能使用的任何第二个因素。

但是这种攻击不需要第二个因素。 [...] 仅获取用户名和密码组合是一个非常低的障碍。

您可能还记得，我们中的许多人都认为（或至少希望）微软会急于修复 ProxyNotShell 漏洞，因为距离 XNUMX 月的星期二补丁还有两周时间。

但我们很失望地发现，可靠的修复显然是 比预期的更复杂，十月来了又去，ProxyNotShell 仅通过变通方法解决，而不是通过适当的补丁解决。

即使是 XNUMX 月的补丁星期二也没有直接提供所需的修复，尽管补丁 尽管如此出来 在同一天作为特定于 Exchange 的安全更新的一部分，可以单独获取和安装：

概念验证揭示

现在尘埃落定，每个人都有时间修补他们的 Exchange 服务器（至少他们没有忘记的服务器），零日计划 (ZDI) 的研究人员最初负责任地向其披露了这些漏洞以提交给微软， 有解释 如何利用漏洞。

坏消息是 ZDI 团队现在有效地提供了解释如何攻击 Exchange 服务器的概念验证 (PoC)，具体取决于您对公开漏洞披露的看法。

当然，好消息是：

• 我们现在可以自己研究和理解这些错误。 这不仅有助于我们所有人确保我们采取的总体预防措施（不仅限于修补）可能会提供我们期望的保护，而且还会告知我们将来希望避免的编程做法，因此我们不不要陷入在我们自己的服务器端代码中发现此类错误的困境。
• 我们现在没有理由不应用补丁。 如果我们拖延了更新，ZDI 对攻击为何有效的解释清楚地表明，治愈绝对比疾病更可取。

产品思路

ZDI的 解释 这个漏洞的故事讲述了将漏洞转化为可行的漏洞所需的所有部分链接在一起是多么复杂的故事。

它也值得一读，以帮助您理解为什么深入研究现有漏洞可以帮助揭示漏洞可能被滥用的其他方式，可能会提示额外的补丁、敦促配置更改以及促进新的编程实践，这些实践可能仅通过修复可能并不明显原来的洞。

解释必然是复杂且技术性很强的，并引导您通过一系列冗长的步骤，最终实现远程代码执行 (RCE)。

如果您决定阅读 ZDI 报告，希望能帮助您更轻松地了解高级细节，这里有一个希望不太简化的摘要，其中列出了相反的步骤……

......所以你会提前知道为什么故事会按照它的方向​​进行：

• 第 4 步。远程诱骗 Exchange 实例化您选择的 .NET 对象，并使用您选择的初始化参数。

在现代编码中，一个 实例化对象 是分配的内存块的行话，在使用时使用所需的数据和资源自动初始化，并绑定到可以对其进行操作的一组特定函数。 (实例化 只是一个花哨的词 创建信息图.)

对象可能由操作系统本身管理和控制，以帮助避免 C 等语言中常见的内存管理不善错误，您通常需要自己分配内存，手动填写相关数据字段，并记住完成后释放正在使用的内存和资源，例如网络套接字或磁盘文件。

对象通常有一个与之关联的编程函数，称为 构造函数，它会在创建新对象时自动执行，以分配正确的内存量和正确的系统资源集。

通常，您需要将一个或多个参数作为参数传递给构造函数，以表示您希望对象在启动时如何配置。

简单地说，如果你实例化，比如说，一个 TextString 对象（我们正在编造这些名称，但你明白了）使用本身是文本字符串的参数，例如 example.com:8888...

......你可能最终会分配一个内存缓冲区来保存你的文本，初始化后它会保存你传入的相同值，即原始文本 example.com:8888.

在这种情况下，当您远程触发构造函数时，作为数据传递给对象构造函数的文本字符串不会立即构成任何明显的网络安全威胁，除了可能通过反复请求越来越大的字符串来拒绝服务 (DoS)尝试耗尽内存。

但是如果你要实例化，比如说，一个 ConnectedTCPClient 使用完全相同的文本字符串参数的对象 example.com:8888，您最终可能会得到一个准备好保存临时数据的内存缓冲区，以及一个由操作系统分配的准备好与服务器交换数据的网络套接字 example.com 通过 TCP 端口 8888.

您可以在那里看到远程代码执行的风险，即使您永远无法将任何数据发送到打开的套接字，因为您已经欺骗服务器将其呼叫到您控制的位置。

你甚至可能会找到一个对象，比如说， RunCmdAndReadOutput，其中您作为参数发送的文本字符串，从字面上看，是您希望在创建对象后立即自动运行的命令，因此您可以稍后收集其输出。

即使您永远无法恢复命令的输出，仅仅实例化这样一个对象仍然会让您选择要运行的命令，从而为您提供通用的远程代码执行并带来仅受服务器进程本身访问权限限制的风险.

当然，一旦进入最后阶段，攻击就变得如此简单，而这是您不应该能够做到的，因为 Exchange 有一个严格的允许列表，阻止您选择任何旧对象进行实例化。

理论上，只有安全或低风险的对象才能通过 PowerShell 远程创建，因此实例化我们想象中的 TextString 以上，或 SimpleIntegerValue，可能被认为是可以接受的，而 ConnectedTCPClient 或者 RunCmdAndReadOutput 绝对不会。

但 ZDI 研究人员注意到，在触发最后一步之前，他们可以这样做：

• 第 3 步。远程欺骗 Exchange，使其认为通过安全测试的低风险对象实际上是您选择的其他对象。

即便如此，您可能希望 Exchange 阻止远程创建甚至是低风险对象，以进一步减少威胁。

但研究人员发现他们可以：

• 步骤 2. 远程欺骗 Exchange 使用其 PowerShell Remoting 基于外部控制的初始化参数创建对象的功能。

这是可能的，因为类似 ProxyShell 的漏洞只是半修补：

• 步骤 1. 远程欺骗 Exchange 接受并处理带有代码的 Web 请求 username:password 字段也进入请求。

即使请求中指定的用户实际上并未登录，并且需要通过某种 2FA 过程才能访问他们自己的邮箱，知道他们的攻击者 username:password 组合将具有足够的身份验证信息来诱骗 Exchange 接受可用于启动上述步骤 2 至 4 中描述的攻击链的 Web 连接。

笼统地说，任何有效的 username:password 考虑到仅需要“身份验证”以防止 Exchange 预先拒绝 HTTP 请求，组合就可以了。

怎么办呢？

请注意，此攻击仅适用于：

• 如果您有本地 Exchange 服务器。 微软声称很快锁定了自己的云服务，因此 Exchange Online 不受影响。 确保你 知道您的 Exchange 服务器在哪里. 即使您现在使用 Exchange Online，您可能仍在运行本地服务器，这可能是迁移过程中错误遗留下来的。
• 如果您的服务器未打补丁。 请确保您有 应用了 2022-11-08 的 Exchange 软件更新 至 关闭漏洞 漏洞需要。
• 如果您的服务器仍然接受基本身份验证，也称为旧版身份验证。 请确保您有 阻止了旧版身份验证的所有方面 所以你的服务器不会接受 username:password 上面提到的标头，并且首先不会接受有风险的自动发现协议请求。 这个 阻止攻击者 欺骗服务器接受他们的诱杀对象实例化技巧，即使该服务器没有打补丁。

您还可以 跟踪 我们的官方预防、补救和响应建议，Sophos 客户可以通过 Sophos X-Ops Twitter 源（@SophosXOps).

已发布有关 CVE-2022-41040 和 CVE-2022-41082 的新信息： https://t.co/pHUVBjUeDI 1/3

— Sophos X-Ops (@SophosXOps) 2022 年 11 月 21 日

---

详细了解 Exchange 身份验证和 OAUTH2

与保罗·达克林和切斯特·维斯涅夫斯基
介绍和结尾音乐 伊迪丝·马奇.

---