利用 Seagate 服务创建 SYSTEM shell (CVE-2022-40286)

这篇文章涵盖的主题与我通常的内容略有不同：应用程序漏洞发现和漏洞利用开发。

原文链接：https://www.x86matthew.com/view_post?id=windows_seagate_lpe

近年来，我没有花太多时间在这个领域进行实验，但在过去几周的一些与工作相关的项目之后，我的兴趣重新燃起了。

我上网找了一个随机的驱动程序/服务来利用——我想找到一家知名公司的产品，而不是太晦涩难懂的东西。

我发现的第一个软件包称为“Seagate Media Sync”，这是一个将媒体文件复制到无线希捷硬盘的工具。我安装了产品，正如预期的那样，这创建了一个名为MediaAggreService.exe的后台SYSTEM服务：

该工具还安装了一个 UI 程序，该程序与交互式用户在同一会话中运行：

特权提升的常见攻击向量始于低特权进程 (UI) 和高特权服务（或驱动程序）之间的内部通信。调查此问题的第一步是从我们可以监控的 UI 中触发合法通信。不幸的是，UI 程序仅提供非常有限的功能，因为我没有相应的 Seagate 硬件：

Process Explorer 显示该服务包含名为MEDIA_AGGRE_PIPE.PIP的命名管道的句柄- 我怀疑该管道用于通信UI ( stxmediamanager.exe ) 和服务 ( MediaAggreService.exe )。

回顾 UI，我们可以单击的唯一按钮似乎是“刷新”——希望这会触发一些与我们可以监控的服务的通信。我们可以将调试器附加到 UI 进程并在CreateFile和WriteFile函数上设置断点以确认这一理论：

如上所示，当单击“刷新”时，UI 进程使用CreateFile打开到命名管道的连接。我们可以通过检查对WriteFile的后续调用来记录消息数据的内容。

写入数据块#1：

写入数据块#2：

有根据的猜测告诉我，第一条消息是一个 4 字节长度的字段，表示消息正文的大小。第二条消息包含实际的命令数据。在此示例中，它正在发送一条消息正文长度为 8 字节的命令 – 初始 4 字节长度值与预期的第二个WriteFile调用的nNumberOfBytesToWrite参数匹配。我们现在可以检查服务进程中的接收端。在MediaAggreService.exe中的ConnectNamedPipe函数上设置断点应该在 UI 客户端调用CreateFile时触发： 我们现在可以在ReadFile上设置断点

功能。这显示了与预期一样从客户端发送的数据：

现在我们已经在服务中找到了读取命令数据的代码，我们可以按照执行流程查看接下来会发生什么。由于我们只能访问 UI 中的单个“刷新”命令，因此需要进行一些静态分析以查看可用的其他命令。

在花了一些时间分析代码之后，我可以看到每个命令都以 16 位签名 ( 0x4B5C ) 开头。其后是 16 位“主要”命令 ID，然后是 32 位“次要”命令 ID。每个“主要”命令 ID 都朝着不同的 switch 语句前进——我在下面评论了反汇编：

如上所示，该服务似乎只支持 2 个“主要”命令 ID – 0x10和0x20。考虑到这些信息，我们现在可以解码我们之前记录的原始“刷新”命令：

在快速查看两个主要命令组的代码后，我注意到0x10命令组包含一个调用名为MXOSRVSetRegKey的内部函数的条目。该条目的“次要”命令 ID 为0x400。

顾名思义，MXOSRVSetRegKey函数似乎设置了一个注册表值，如果该键不存在，则首先创建它。

对该代码的初步分析表明，该命令可能允许我们通过客户端进程远程创建/修改注册表字符串值。基本密钥似乎被硬编码为HKEY_LOCAL_MACHINE（在RegCreateKeyExW调用中推送 0x80000002 ）。对这些函数进行逆向工程后，我可以看到该命令期望接收以下格式的消息数据：

上面的命令只支持字符串值——类型字段被硬编码为REG_SZ（在RegSetValueExW调用中按 1 ）。 我还发现了另一个命令 ID ( 0x410 )，它允许我们以相同的方式设置REG_DWORD值。此命令接收以下格式的消息数据：

从上面命令数据的布局我们可以看出，我们可以推断这两个命令共享一个共同的数据结构。我们可以用 C 结构来表示它们，如下所示：

假设以上所有内容都是正确的，这意味着，正如怀疑的那样，任何用户都可以通过向希捷服务管道发送命令来将任意注册表值写入HKEY_LOCAL_MACHINE中的任何键。如果这是真的，这意味着我们有一条明确的利用途径。这可能看起来很奇怪，但是像这样的“功能”比您想象的要普遍得多。

我们现在有足够的信息来编写自定义管道客户端来测试我们的理论：

上面的代码连接到MEDIA_AGGRE_PIPE.PIP管道并尝试在HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\x86matthew中创建一个注册表值- 我们将作为普通用户执行这个程序：

正如我们在上面看到的，这段代码正常工作并创建了目标注册表值。具有写入HKEY_LOCAL_MACHINE的能力为利用提供了很多可能性 – 在这种情况下，我们将通过向HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services注册表项添加一个条目来创建自定义服务。

而不是部署单独的 exe 以用作SYSTEM服务负载，我们将把这个功能结合到主要的漏洞利用可执行文件中。exe 将首先检查它是否以SYSTEM用户身份运行 – 如果不是，它将执行默认行为并尝试通过 Seagate 管道创建新服务，如上所述。否则，如果 exe 检测到它作为SYSTEM服务运行，它将部署主要有效负载 – 这将创建一个 TCP 绑定外壳用于演示目的。

总而言之，利用概念验证工具将执行以下步骤：

1.使用CreateFile通过命名管道\.\pipe\MEDIA_AGGRE_PIPE.PIP连接到希捷服务。

2.使用GetModuleFileName 获取当前exe的文件路径.
3. 通过将逆向工程的注册表命令发送到希捷命名管道来创建新的 Windows 服务。使用当前 exe 作为进程路径，将新条目添加到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services 。
4. 重新启动计算机。
5. Windows 将在启动时自动启动我们新创建的“服务”。漏洞利用可执行文件将检测到它以SYSTEM身份运行并侦听端口 1234 上的 TCP 连接。
6. 当用户连接到localhost:1234时，漏洞利用服务将以SYSTEM身份启动新的cmd.exe进程，并重定向 stdin/stdout到客户端套接字。

演示 执行漏洞利用：

重启后：

连接到localhost:1234：

作为参考，此漏洞已分配给 CVE-2022-40286。

完整代码如下：