Windows 安装程序文件读取 0day

几天前，像往常一样，我正在阅读一些谷歌项目的零错误。然后我发现了 James Forshaw 的这篇文章，内容是当特权进程模拟用户加载库时，dos 设备中的 EoP。你可以在 这里 阅读这篇文章，我唯一的问题是 PoC 文件，因为它看起来像 james 向 MSRC 提交了 2 个附件，第一个是实际编译的 PoC 和一个 dll，第二个附件似乎受密码保护

经过一些研究试图找到原始 PoC 源代码，我没有找到有用的东西，所以回答我的问题的唯一方法是反转实际的 PoC。

我真的有一些问题，例如，他是如何管理覆盖原始链接的？他是如何获得登录会话 \Sessions\0\DosDevices\XY <- 他是如何设法获得这些数字的？

没有什么特别的，dll 只会调用“RevertToSelf()”，然后将记事本创建为子进程。

但是对于实际的 PoC，一些操作已经完成。我只会介绍对我们研究领域有影响的代码。

PoC 将首先检查当前的操作系统架构，如果它与 x86 匹配，它将继续，否则将退出。我仍然不知道他为什么这样做，但也许是为了摆脱烦人的 Wow64 重定向。

在做了一些反向之后，我终于回答了我的问题，为了得到当前的 DosDevice 路径是调用 GetTokenInformation

然后它会通过调用 NtCreateSymbolicLinkObject 将 dos 设备符号链接重定向到 PoC 的当前目录，当然它会确保重新创建 C:\Windows\System32 并将前面描述的 dll 放置到 system32 中，名称为 PrintFilterPipelinePrxy.dll，之后 PoC将简单地调用“OpenPrinterW”“StartDocPrinterW”“EndDocPrinter”，然后 dll 将作为后台处理程序服务加载。微软已发布该漏洞的公告 CVE-2015-1644

在查看了 Microsoft 如何修补漏洞后，Microsoft 实施了一项缓解措施，以确保不会因为 DosDevice 链接而重定向 dll 加载行为， 方法是使用 OBJ_IGNORE_IMPERSONATED_DEVICEMAP。但是，如果不使用上述标志，则任何其他文件系统操作都将遵循该链接。

下图将解释事情是如何完成的

很容易，但它可以利用吗？是的，但实际上没有。在极少数情况下，CreateFileW 重定向可能很有用。 现在我只想解决一个问题，我不喜欢 PoC 如何调用 GetTokenInformation 来获取当前进程 Dos Device 所以我做了一些研究并得到了一些好的结果。

您不需要创建实际的 DosDevice 链接，覆盖 C:\ 将为当前用户完成这项工作。

我最初是受到沙盒转义器任意文件读取 PoC 的启发，该 PoC 作为 0day 漏洞 2018 被删除。该错误存在于MsiAdvertiseProduct函数中，调用它将触发以 SYSTEM 权限运行的 Windows 安装程序服务的文件复制。

在这个漏洞中，我将 攻击带有两个参数 的MsiInstallProduct 。

第一个是 szPackagePath，它可以是 URL 或本地文件。第二个参数是 szCommandLine。

调用该函数后，我从进程监视器得到以下输出

第 1 阶段：Windows 安装程序服务将模拟用户并调用OpenAndValidateMsiStorageRec，这将首先检查包是否有效。

第 2 阶段：Windows 安装程序服务将反向并在 C:\Windows\Installer\*.msi 中创建一个新文件

第 3 阶段：它将确保打开的文件与要打开的预期文件匹配，如果匹配，则调用GetFinalPathNameByHandleW，如果不匹配，则复制文件，安装程序服务将模拟用户并尝试复制文件。

当调用CElevate::CElevate((CElevate *)&X, 1);时，该缺陷完全存在于 msi.dll!CopyTempDatabase() 中。提升特权而不是停留在冒充模式

CopyTempDatabase 中有一些检查，例如 CMsiFileCopy::VerifySource，它检查源是否对复制有效，但如果用户模拟不正确，则可能会失败。

由于包清理将在模拟用户时运行，我们可以使用上述技巧将其重定向到有效包，这将欺骗OpenAndValidateMsiStorage 并将其标记为有效包。然后安装程序将检查目标文件是否是预期在我们的情况下打开的文件，是的，因此它将继续将文件复制到 C:\Windodws\Installer\*.msi

我成功实现了利用，但我还有一个问题，当文件被复制到 C:\Windows\installer 时，它可能不是那里唯一的文件，所以获取新创建的文件就像一个编程测验，我花了一段时间才看到我的选项，第一个是ReadDirectoryChangesW它等待并获取任何新创建的文件，这听起来不错但没有用。由于 Windows 安装程序服务会篡改目录的某些参数，并在写入后立即删除新创建的 MSI 包。第二个选项是使用 FindFirstFileW，FindNextFileW 解决了一些问题，我在这里使用的技术是找到创建的最新文件并将其作为我们的目标，由于一些未知的原因，该技术失败并且总是选择错误的文件. 所以我转向另一种技术（这是我最后的希望），这段代码将解释查找新创建文件的过程

我们将首先弃用“C:\”路径，我们将使用 Windows GUI 路径，因此我们不会出现重定向问题，要检索驱动器的 GUI 路径，您可以使用GetVolumeNameForVolumeMountPoint，然后它将在下一个主要使用api 调用。接下来，我们的 PoC 将搜索 \Windows\Installer\*.msi 并将其存储在数组“first_srch[10000]”中，然后您可能会注意到有两个FindFirstChangeNotification调用，根据 Microsoft 文档

“创建更改通知句柄并设置初始更改通知过滤条件。当指定目录或子树中发生与过滤条件匹配的更改时，通知句柄的等待成功。该函数不报告对指定目录本身的更改。“

PoC 将设置 2 个事件，一个用于文件创建，第二个用于文件写入，当第一个事件触发时，PoC 将重新开始搜索 MSI 文件并将存储到一个数组中，PoC 将获取这些数组并比较每个文件名如果在某个索引处有不匹配的内容，那么它就是新创建的文件。之后，我们将等待第二个事件触发，然后简单地复制我们的文件。

Windows 读取文件的可利用性如何？

当 Windows 崩溃时，它会自动在 C:\Windows\memory.dmp 中生成一个 Windows 内核内存转储，并将其 DACL 限制为仅限管理员使用

您可以使用 PoC 读取文件 :)