关于ProxyShell的NSA Meeting漏洞分析

作为Microsoft Exchange 2021年4月和5月补丁的一部分，几个可能导致代码执行或电子邮件劫持的重要漏洞得到了修复。任何过时的和公开的Exchange服务器都应该被认为已经受到了破坏，因为这些漏洞已经被利用了一段时间。

由于仅在2021年报告和修补的Exchange漏洞数量众多，使用漏洞名称比使用它们的CVE编号要容易得多，因为它们可能带有错误的日期。众所周知的、最终可能导致代码执行的Exchange漏洞是ProxyShell和NSA Meeting漏洞。

ProxyShell 漏洞利用很复杂，并且依赖于滥用 Exchange PowerShell cmdlet (Get-MailboxExportRequest) 在 Web 可访问位置创建 Web-shell。漏洞利用代码示例已经出现了，使用 PST 编码器对新的有效载荷进行编码并不困难。这个漏洞可以被未经身份验证的攻击者利用，现有的电子邮件地址是不需要的(一个域名应该足够)。

另一方面，NSA Meeting 漏洞利用了一个不安全的反序列化漏洞，这可能导致代码在服务器上执行。由于此漏洞利用不需要在 Web 目录上创建 web-shell，因此对于攻击者来说，避免与 web-shell 相关的攻击指标可能是更好的选择。然而，该漏洞发布后不久的公开漏洞利用并不能自行发挥作用，需要进行一些更改才能完全运行。不幸的是，我们也无法找到一种方法来利用这个漏洞，除非得到验证。因此，在没有凭据的情况下，这只能从横向移动的角度（已经假定已通过身份验证并通过针对‘/owa/integrated/’终端）或跟踪凭据窃取的角度利用。与 Jang 已经发布的文章类似，我们找不到触发有效载荷的不同方法，但考虑到 Exchange 解决方案的大小和复杂性，这是可能的（Exchange 中有几个受影响的类文件，但获取它们是不简单）。

考虑到ProxyShell和NSA Meeting漏洞几乎是同时被修复的，我们想要展示如何将这些漏洞结合起来，为安全研究人员提供不同的检测方法。我们还在本文中介绍了一些在处理类似的漏洞时可能会很有趣的边研究主题。本文的所有代码都应该包含在以下GitHub存储库中：https://github.com/mdsecresearch/NSAMeetingWithProxyShell。

从 YSoSerial.Net 中为当前的公开漏洞设计一个新的工作反序列化小工具并不困难，如下所示：

然而，运行代码而不是命令需要很多复杂的操作，为此，我们采用了以下过程来实现这一目标：

‘%LosFormatterPayload%’值现在可以替换为来自 YSoSerial.Net 项目的任何 LosFormatter 有效载荷。我们现在可以使用它通过运行 ActivitySurrogateDisableTypeCheck 小工具的有效载荷来启用 ActivitySurrogateSelector 小工具。然后就可以使用 ActivitySurrogateSelector 或 ActivitySurrogateSelectorFromFile 小工具在服务器上运行 C# 代码。

完整的 XML 消息示例可以在 GitHub 项目中看到。

结合利用

当两个漏洞都准备好时，结合利用就很容易了。我们只需要使用不同的 PowerShell 命令来实现这一点。

正如@peterjson 在他的博客文章中提到的，一个默认的用户账户，比如‘SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}@TargetExchange.domain’可以用来向‘/autodiscover/autodiscover.xml’发送请求终端以获取有效的 LegacyDN，然后用于向‘/mapi/emsmdb’终端发送请求以获取有效的 SID（与 ProxyLogon 相同）。 SID 值用于在 Exchange 中创建用于内部身份验证的通用访问令牌 (CAT)。这是我们通过 URL 中的‘X-Rps-CAT’参数发送到‘/powershell/’后端终端以进行身份验证的令牌。

尽管我们可以在向‘/ews/Exchange.asmx’终端发送请求以存储 NSA meeting载荷时使用模拟（因为我们已经有了 SID），但我们仍然需要一个帐户来访问‘MeetingPollHandler.ashx’ OWA 上的页面。因此，我们使用‘New-Mailbox’cmdlet 创建新邮箱并登录 OWA。

然后可以触发存储的meeting载荷以利用反序列化漏洞并在服务器上运行代码或命令，而无需创建 web-shell。

以下是它在 .NET中的最终实现的屏幕截图（不幸的是，为了阻止任何潜在的滥用，我们无法发布完整的漏洞利用程序）：

Exchange 远程 PowerShell 限制

以下是使用 PowerShell 远程管理应用程序时的一个常见漏洞：

如果我们可以运行一些 cmdlet，为什么我们不能在服务器上运行任何我们想要的东西？这个漏洞的简单答案是，对于 Exchange 服务器，大多数远程 PowerShell 环境应将其 LanguageMode 设置为‘NoLanguage’或‘RestrictedLanguage’。微软在4月份的补丁中修补了一些缺失的补丁，所以可能会有一些感兴趣的人：

下面的截图显示了我们在处理这个设置时可以收到的一个错误消息示例：

在Exchange中，公开的cmdlet也受到限制，如在不同的文件中列出的：

Microsoft.Exchange.Configuration.ObjectModel\Configuration\Authorization\PowerShellWebServiceExposedCmdlets.cs

因此，当我们尝试在服务器上运行命令时会收到以下错误消息：

需要注意的是，它实际上是在服务器上寻找文件，但无法执行：

如何简单地查看 Exchange 代理请求？

虽然 socat 工具似乎非常适合监控 Exchange 服务器前端和后端之间的通信，但我们选择了 mitmproxy 工具，因为它需要花费更少的设置时间并且有一个漂亮的 Web 界面来监控请求及其响应.

以下是我们配置mitmproxy来研究它的前端和后端之间的Exchange IIS通信的步骤：

1.在 Exchange 服务器上安装 Windows 版本的 mitmproxy；

2.在 IIS 上编辑 Exchange Back End Home 站点的绑定：

3.将端口号从 444 更改为 4444：

4.运行以下命令以使用 mitmproxy 作为反向代理：

mitmweb.exe --mode reverse:https://localhost:4444 --listen-port 444 --no-http2 --ssl-insecure --set keep_host_header

5.在现代浏览器（例如 Google Chrome）中监控服务器上的请求/响应（在 IE 中效果不佳）：

使用 dnSpy 进行调试

在服务器上调试像Exchange这样的应用程序，以查看一些输入是如何处理的，这总是很有用的。下面是使用dnSpy调试Exchange服务器的一些简单技巧。

假设我们要调试‘Microsoft.Exchange.FrontEndHttpProxy\HttpProxy\EwsAutodiscoverProxyRequestHandler.cs’类中的‘ResolveAnchorMailbox()’方法。我们将向以下 URL 发送请求并在有趣的函数中放置一个断点：

/autodiscover/autodiscover.json?test@test.com/ews/Exchange.asmx?&Email=autodiscover/autodiscover.json%3ftest@test.com

在深入调试之前，建议为 DLL 创建一个 INI 文件，以使其调试更容易，以便你可以查看所有变量并浏览它们。在本文的示例中，我们需要创建以下文件：

C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\bin\Microsoft.Exchange.FrontEndHttpProxy.ini

其内容是：

你可能需要重新启动 IIS 进程或相关的应用程序池。

IIS为Exchange服务器中的不同路径(应用程序)使用多个应用程序池：

我们需要知道哪个应用程序池负责运行我们有趣的功能，以便我们可以调试它。虽然出于调试目的在一个应用程序池下运行所有内容可能有其自身的好处，这可以立即查看所有内容，但根据我们需要调试的功能，可能会收到太多噪音（显然我们的服务器也不会是真正的副本）。幸运的是，我们知道我们将要访问的路径，并且通过在 IIS 中查看其基本设置很容易看到相关的应用程序池：

现在我们需要做的就是打开 dnSpy（64 位）并通过‘调试 > 附加到进程’菜单将其附加到正确的进程中，如下所示：

将 dnSpy 附加到正确的进程后，我们需要单击‘模块’面板并找到包含我们想要调试的有趣函数的 DLL。在这种情况下，我们的 DLL 文件是‘Microsoft.Exchange.FrontEndHttpProxy.dll’：

现在我们需要找到位于‘HttpProxy\EwsAutodiscoverProxyRequestHandler.cs’的有趣函数（‘ResolveAnchorMailbox’）来添加断点：

现在一切准备就绪，可以发送我们的请求以查看断点是否有效：

其余部分与正常调试类似，但并行线程会带来一些惊喜。

如何绕过 WAF 规则？

由于我们在处理 IIS 上的 ASP.NET 应用程序时利用这些漏洞，因此可以使用请求编码、参数污染和其他技术特定技术来逃避仅依赖于检测 URL 或正文中的特定输入参数的防火墙的请求。

虽然除了‘text/xml; 'Content-Type' 标头中的 charset=utf-8' 将被 Exchange 服务器拒绝，'x-up-devcap-post-charset' 标头和在 'User-Agent' 标头中使用 'UP'可以节省修改字符集的时间(详见此链接)。

以下请求显示了作为 ProxyShell 漏洞利用获取 LegacyDN 值的一部分的示例：

由@garethheyes在Burp套件中的HackVertor扩展负责对上述示例请求进行编码(HackVertor标签以' <@ '开始)。

编码后的实际请求如下所示：

URL编码不同于普通的。net请求编码，因为它被代理了，因此后端和前端不会以相同的方式解析它。有趣是，这种编码破坏了 mitmproxy 工具的报告部分，该工具用于在我们的测试期间监控 Exchange 服务器前端和后端之间的连接！

此示例显示了 .NET 中的请求可以进化到何种程度，以避免简单的检测。代码和实现也可用于隐藏或混淆有效载荷。此处的一个示例是将‘Email’参数 (Microsoft.Exchange.HttpProxy.Common\Common\ExplicitLogonParser.cs) 中的‘..’转换为‘@’：

解析漏洞或忽略任意字符串（例如在‘/powershell/’路径之后）也可以用来避免简单的检测。

这就是WAF不能真正阻止这种攻击的原因，一个合适的补丁是解决这些漏洞的唯一解决方案。微软最近修复了离线地址簿(OAB)模块中的另一个漏洞，该漏洞可能被滥用于在' C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\OAB\ '路径中创建web shell。也许这也可以用来创建另一个攻击变体。访问OAB路径中创建的文件的请求看起来像这样：

从.NET中的’ text/plain ’到’ application/x-www-form-urlencoded ’

在处理ProxyShell漏洞时，我们注意到，当服务器以以下错误消息响应时，将' Content-Type '标头设置为' application/x-www-form-urlencoded '或' multipart/form-data '无法发送正常的POST请求：调用 HttpRequest.Form、Files、InputStream 或 BinaryRead 后，不支持此方法或属性。

虽然使用其他现成的具有不同扩展名的 web-shell，例如 '.asmx' 或 '.svc' 来在对象中使用 XML 或 JSON 并不难，但使用我们的老式ASPX web shell(如ASPXSpy!)会更有趣。

最简单的解决方案是在 web-shell 中的所有 HTML 'Form' 标签上使用'enctype=’text/plain’' 属性，而不是使用 JavaScript 和 XHR 重写它。但是，.NET 不会解析‘text/plain’请求，因此无法使用‘Request.Form’读取传入参数。我们通过使用以下 .NET 代码解决了这个漏洞，该代码使用正则表达式简单地解析‘plain/text’ 请求，然后使用反射来填充‘Request.Form’对象：

在旧的ASPX web-shell(或在' OnPreInit '方法中)开始运行上述代码后，它将使用一个简单的' text/plain '请求，这在ProxyShell中是允许的。唯一的限制是文件上传，因为上面的实现不支持‘multipart/form-data’，并且浏览器不使用‘text/plain’发送文件。

虽然微软已经解决了上述最严重的漏洞，并且无法再利用报告的漏洞，但仍有一些未解决的漏洞可能会在未来被滥用：

1. ProxyShell 漏洞利用的Proxy bit仍然存在。例如，如果我们发送一个请求到：

它仍然在端口 444 上将请求发送到后端：

/ews/Exchange.asmx?&Email=autodiscover/autodiscover.json%3ftest@test.com

尽管此请求现在未经身份验证，但如果未经身份验证的用户可以访问某些包含漏洞的终端，那么这个请求仍然是有用的。

2.当请求中存在‘Cookie: securitytoken=foobar’时，ProxyToken 漏洞利用的Proxy bit仍然可以将未经身份验证的请求传输到后端的/ecp/’路径。

3. Calendar路径虽在 2021 年 4 月被修复，但未经身份验证的请求仍会使用以下模式到达后端的‘/ow/‘路径：

/owa/calendar/foobar@exchange.local/foobar/MeetingPollHandler.ashx/.html

或者

/owa/calendar/foobar@exchange.local/foobar/owa14.aspx/.js

4. ‘EntitySerializer.Deserialize’ 方法是 NSA meeting漏洞中确定的反序列化漏洞的根源，它仍然存在，可能会影响另一个功能。除此之外，‘SchematizedObject’类已被许多其他类扩展，这些类将来可能会以类似的方式导致反序列化漏洞。此类本身正在扩展‘PropertyChangeTrackingObject’类，该类包含‘EntityLoggingData’和‘EntitySerializationData’内部类，其中一些成员定义为‘Dictionary

安全建议

除了使 Exchange 服务器保持最新版本和监控网络流量外，还必须在服务器上使用文件监控工具来检测可疑的文件创建事件，尤其是在 Web 目录和 .NET 临时文件中。

更改文件权限或默认安装路径以及使用 WAF 可能会减慢某些入侵者的速度，同时监控警报以检测潜在攻击。然而，这些都不是完整的解决方案，因为所有这些都可能被绕过。