关于ZAKER 免费视频剪辑 合作 加入

关于 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.ObjectModelConfigurationAuthorizationPowerShellWebServiceExposedCmdlets.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.FrontEndHttpProxyHttpProxyEwsAutodiscoverProxyRequestHandler.cs ’类中的‘ ResolveAnchorMailbox ( ) ’方法。我们将向以下 URL 发送请求并在有趣的函数中放置一个断点:

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

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

C:Program FilesMicrosoftExchange ServerV15FrontEndHttpProxybinMicrosoft.Exchange.FrontEndHttpProxy.ini

其内容是:

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

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

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

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

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

现在我们需要找到位于‘ HttpProxyEwsAutodiscoverProxyRequestHandler.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 标签以 '

以上内容由"嘶吼RoarTalk"上传发布 查看原文
一起剪

一起剪

ZAKER旗下免费视频剪辑工具

一起剪
相关标签