Microsoft Store游戏提权漏洞分析（CVE-2020-16877）-安全客

0x00 前言

本文描述了Windows特权提升漏洞（CVE-2020-16877），我在6月向微软报告了这一问题，该问题在10月进行了修复。通过这一漏洞，攻击者可以直接利用Windows处理Microsoft Store游戏过程中的缺陷实现攻击，最终在Windows 10系统上从普通用户提升到Local System权限。

0x01 简介

早在今年6月，有一个公告引起了我的注意，微软刚刚在游戏子系统中增加了对各种游戏MOD的支持。由于好奇心，我开始探索Windows中的这个新功能，最终发现了一个实现中存在的缺陷，可以利用该缺陷进行特权提升攻击。

本篇文章是由我贴在显示器上的多个便利贴整合而成，详细介绍了我发现该漏洞的过程。

在我们开始研究这一功能之前，首先需要具备一些Windows应用程序和游戏模块的背景知识。如果大家已经熟悉这些概念，可以直接跳过下一章节。

0x02 关于Windows游戏和MOD

如果大家对视频游戏不太了解，实际上MOD是“modification”的缩写，是指玩家或粉丝对视频游戏做出的修改，他们会修改视频游戏的一个或多个方面，例如外观或行为。MOD的变化可以是细微调整，也可以是彻底的大改，这会让游戏变得非常有趣。

通常，Microsoft Store游戏都是以Windows应用程序形式部署的通用Windows平台（UWP）应用程序。

根据微软的官方文档，UWP应用程序满足以下特点：

1、安全性：UWP应用程序会声明它们访问哪些设备资源和数据。用户必须授权该访问。UWP应用程序使用清单来指定所需的功能，例如访问麦克风、特定位置、网络摄像头、USB设备、文件等等。

2、能够在运行Windows 10的所有设备上使用通用的API。

3、可以在Windows 10运行的所有设备上，使用Microsoft Store来获取这些应用程序。

4、能够自由安装和卸载，不会对主机产生风险，不会在卸载后留下残留文件。

我们可以将UWP应用程序视为沙盒应用程序，在应用程序包（Appx）的清单中定义了其功能（例如：文件系统访问、网络访问等）。

Appx是用于在Windows 10、Xbox One、HoloLens和Windows 10 IoT和新版本上分发和安装应用程序的文件格式。与传统的桌面应用程序不同，Appx是UWP应用程序唯一支持的安装系统。

Windows应用程序存储在系统上一个特殊的“隐藏”目录中（C:\Program Files\WindowsApps），该目录具有严格的访问规则，可以阻止任何类型的游戏MOD或普通用户交互：

下图展示了这个目录的权限：

以前，由于Microsoft Store游戏不支持MOD，因此玩家一直在寻找变通的方式来修改自己喜欢的游戏（例如：Minecraft – Microsoft Store版）。举例来说，为了在UWP应用上实现DLL注入，所有应用程序包（S-1-15-2-1）组都应该具有对Windows应用程序中注入的DLL的R+X权限。

在我们对Windows应用程序的生态系统和游戏MOD有了基本了解之后，就可以进入到研究之中。

0x03 研究思路

在将游戏安装到系统上之前，我首先考虑了微软可能会如何实现这一功能。我有两个猜测：

1、WindowsApps目录中存在一个新的子目录，普通用户可以访问。

2、有一个单独的目录被放在普通用户可访问的目录中。

因此，我执行了一个附加步骤，在主驱动器上搜索了“*WindowsApps*”关键词，得到以下结果：

为了让游戏支持MOD，Windows似乎创建了一个新的目录，即C:\Program Files\ModifiableWindowsApps，顾名思义，这个目录应该是用来保存可以修改的Windows应用程序。

接下来的思路是查看该目录和其中内容的权限，但是遗憾的是，里面还没有任何内容。但至少，我可以在没有管理员提示的情况下访问这个目录。

此时我们对C:\Program Files\ModifiableWindowsApps的权限：

我在网上快速检索了和这个目录有关的内容，发现了以下线索：

1、我们在desktop6:MutablePackageDirectory这篇微软官方文档（发布日期为2019年4月19日）找到对ModifiableWindowsApps目录的引用，其中提及了这一目录，“在%ProgramFiles%\ModifiableWindowsApps路径下指定一个文件夹，用于映射桌面应用程序安装文件夹中的内容，以便用户可以修改安装文件（例如：安装MOD）”。

2、在desktop6:MutablePackageDirectories这篇官方文档中（发布日期为2019年4月19日）提到了该目录，“让桌面应用程序可以指定一个或多个文件夹，用户可以在其中修改应用程序的安装文件（例如：安装MOD）”。

3、还有最重要的一个线索，“该元素当前仅应由微软及其合作伙伴发行的某些类型的桌面PC游戏使用，需要modifiableApp的受限功能”。

也就是说，这个功能仅限于微软审核和批准的某些游戏，以便允许游戏在清单中指定modifiableApp功能，从而允许MOD的使用。

0x04 小结

到目前为止，回顾一下我们已知的情况：

1、Windows允许修改一些Microsoft Store游戏；

2、这是通过允许某些游戏开发人员使用受限功能（modifiableApp）在商店上发布UWP游戏来实现的；

3、modifiableApp功能允许Microsoft Store游戏支持Windows MOD和大量新的API。

4、这些可修改的Windows应用程序可以通过MutablePackageDirectory和MutablePackageDirectories指定存储其可修改数据的目录。

0x05 继续探索

到这里，为了继续我的探索，我需要在Microsoft Store上找到支持MOD的游戏列表，然后选择作为目标的游戏。幸运的是，微软有一篇关于Microsoft Store支持MOD的文章，提供了这些游戏列表：

DiRT Rally 2.0
Farming Simulator 17
FTL: Faster Than Light
Into The Breach
MudRunner

我决定选择Faster Than Light这款游戏。

为了确认我对Windows应用程序修改方法的理解是否准确，我迅速浏览了游戏清单，并确认其中是否存在“特殊”的功能（modifiableApp）：

确认部署游戏数据的目录位置，我在安装游戏后检查了ModifiableWindowsApps目录，对于FTL这款游戏来说，目录名称是MutablePackageDirectory：

有了这些信息，我继续以普通用户身份再次安装游戏，并使用ProcMon监控安装过程。

ProcMon提供了一些关于Microsoft Store是如何安装支持MOD游戏的线索：

1、该过程涉及到两个主要的进程：

（1）svchost（以NT AUTHORITY\SYSTEM运行）

（2）GamingServices（以S-1-5-18运行）

2、这些进程执行了一些值得关注的文件操作，并且在此过程中没有模拟低特权用户。

在准备了一台意式咖啡机后，我决定继续花时间，来研究这种安装机制。

0x06 遇到问题

默认情况下，存储Windows游戏的ModifiableWindowsApps目录不允许普通用户对安装目录或内容进行操作：

微软之所以要限制游戏目录（和父目录）访问的原因，是为了防止普通用户劫持安装进程，并将游戏数据放置到不需要的目录中。攻击者通过符号链接的方式，可以实现这一点。

具体而言，在Windows上，可以通过以下方式创建符号链接：

1、硬链接（Hard Link）：硬链接是文件系统的一种表示形式，可以让多个路径引用同一个卷内的单个文件。

2、连接点（Junction）：连接点（也称为软链接，Soft Link）与硬链接的不同之处在于，它引用的存储对象是单独的目录，并且连接点可以链接位于同一计算机上不同本地卷上的目录。

3、对象管理器符号连接：这是一种类似于文件系统的结构，用于保存命名资源，例如设备和事件，它也支持符号链接。

如果大家想了解关于符号链接的更多信息，可以参考James Forshaw（@tiraniddo）的文章。

如果我能够获得对ModifiableWindowsApps目录的写访问权限，那么我就可以尝试将游戏安装重定向到系统上的任意目录，包括普通用户无法访问的目录，因为安装进程是以高特权用户身份运行的。

那么，假设我能够针对ModifiableWindowsApps目录创建原始的连接点，也许可以按照下述步骤将安装程序劫持到任意目录（即：C:\Windows\ImmersiveControlPanel），从而绕过访问限制。

C:\Windows\ImmersiveControlPanel的权限：

遗憾的是，如果要设置任何符号链接，普通用户需要具有对ModifiableWindowsApps或其任意子目录的写入权限。

而这是不可行的，因为不能替换ModifiableWindowsApps，因为它已经作为系统的一部分，并且有严格的访问规则来保护此目录及其中的内容（即：FTL游戏目录）。

到这里难道结束了吗？还没有…

0x07 调整思路

我需要的，是一种“提升”ModifiableWindowsApps目录，并将其放置在我可以访问的系统的其他位置的方法。至少是在重定位完成之前，都需要依赖于这种方式。

我关注到，Windows中包含一个简洁的功能，可以定义普通用户可访问的各种数据的存储位置。可以通过存储设置来访问此功能。

该功能显然适用于Windows应用程序，我想确认此功能也适用于可修改的Windows应用。因此，我将新应用程序的目标驱动器设置为系统上的其他驱动器，然后再次尝试安装过程。ModifiableWindowsApps目录和游戏都放置在新驱动器上。

如果将其部署在其他驱动器（而不是C:）上，这可能是一种获得对ModifiableWindowsApps目录的写访问权限的方法，我需要做的就是准备目标驱动器（可以是系统上的任何其他盘符，也甚至是空白U盘），再结合连接点，通过“存储设置”诱使安装程序执行。

0x08 接受挑战

现在，是时候将上述整合到一起，并尝试利用这种机制了，我们看看之前设想的方案是否有效，以及是否能发现一个实现层面的缺陷。

首先，我使用以下命令，将连接点设置为劫持安装程序（我们假设使用D盘作为另外的驱动器）：

    md "D:\Program Files"
    mklink /J "D:\Program Files\ModifiableWindowsApps" "C:\Windows\ImmersiveControlPanel"

然后，调整Windows应用程序中“存储设置”对应的位置：

安装游戏：

使用ProcMonc监控安装过程：

确认游戏数据实际上已经写入到我的任意目录中：

至此，我们确认普通用户可以将数据写入系统上的任意目录，但是删除文件是否能成功呢？我想到的第一种方法，是尝试卸载游戏。

遗憾的是，卸载过程仅仅删除了游戏文件（存储在实际的游戏目录中），似乎没有接触任何不相关的数据。

但是，如果游戏目录本身就是连接点呢？如果我们使用两个连接点来欺骗安装程序，使其认为游戏安装目录本身是系统上的另一个目录，情况会怎么样？

这样一来，当安装程序尝试删除游戏数据时，就会删除系统上任意目录的内容（例如存储在管理员桌面上的“Private”目录）：

我再次准备了攻击环境，对其稍作改动，使用两个连接点让安装程序指向目标，从而实现任意目录删除：

    md "D:\Program Files"
    md "D:\pivot"
    mklink /J "D:\Program Files\ModifiableWindowsApps" "D:\pivot"
    mklink /J "D:\pivot\FTL" "C:\Users\dnt-admin\Desktop\private"

在设置环境后，我尝试了之前任意写入的方案，在实施过程中仅做了些微更改。实际上，如果要触发删除，需要在Microsoft Store中终端安装（在下载完成后），或者等待安装程序抛出错误。