Windows 10 S中的Device Guard详解（上篇）

本文探讨Windows 10 S（下称Win10S）中的Device Guard（设备保护，下称DG）。我将提取策略，并弄清楚在默认Win10S系统上可以和不可以运行什么。我将在下一篇文章中介绍在不安装任何额外软件（如Office）或升级到Windows 10 Pro的情况下实现任意代码执行的一些方法。

Win10S是第一个向消费者发布的通过DG预先锁定的Windows操作系统。DG是基于WindowsVista中引入的内核模式代码完整性（KMCI）和Windows 8 RT中引入的用户模式代码完整性（UMCI）。DG包含诸多限制代码执行的特性，基于一组策略规则限制什么类型的可执行文件/脚本（包括DLL）可以加载。要找到在带DG的系统中运行任意代码的方法，我认为第一步是要提取DG策略并检查其缺陷。

提取DG系统完整性策略

DG的执行通过系统完整性(SI)策略配置。SI策略作为二进制文件存储在磁盘上。当操作系统启动时，WINLOAD或内核CI 驱动程序将策略加载到内存中，并根据配置的各种规则开始执行。

文件的位置取决于策略的部署方式。我使用的是预装了Win10S 的Surface笔记本电脑，策略位于C:\Windows\Boot\EFI文件夹中，名为winsipolicy.p7b。该文件无读取限制，我们可以提取其内容，因此可以确定执行的是什么策略。但是，据我所知，没有官方文档描述该二进制策略文件格式。有一个ConfigCI Powershell模块可将XML文件转换为二进制策略。但是没有相应的命令执行相反的操作。

MattGraeber编写了一个可将二进制格式转换回XML格式的Powershell脚本。但原始脚本有些问题，因此我做了一些修改，以完全支持Win10S中使用的策略格式，并修复了一些bug。Matt用我的修补程序在github上更新了其副本，可点击此处获取。将脚本加载到Powershell中，然后运行以下命令：

ConvertTo-CIPolicywinsipolicy.p7b output.xml

转换后得到我们可以阅读的XML文件。XML文件可从Matt的博文获取。接下来我们分成几个部分一一探讨。

系统完整性策略规则

第一个重要的部分是定义一组在系统完整性策略中启用的布尔选项的规则。

第一个选项启用UMCI。默认情况下，DG不执行UMCI，但执行KMCI。第二个选项启用“高级启动选项菜单”，这有点意思，因为默认情况下，菜单为禁用状态，该策略允许系统用户对启动过程有更多的控制。第三个选项是“执行应用商店应用程序”。这确保你不能为应用商店应用程序禁用UMCI。如果没有这种设置，就可以配置一个side-loading策略，如此你就可以部署自己的UWP应用程序。由于Win10S的宗旨是“安全性”，所以只允许应用商店签名的UWP应用程序，我将在“允许的签名者”部分解释这一点。最后一个是“条件性Windows锁定策略”，其似乎与Windows10S SKU和锁定策略最终可被禁用的可能性相关联。这与许可值和系统环境变量“Kernel_CI_SKU_UNLOCKED”有关。

文件规则

接下来是一组文件规则。这通常用于将已知可绕过DG及可让你轻易运行任意代码的具体可执行文件列入黑名单。这与微软在其DG部署指南中提供的列表接近。不过微软还阻止了注册表编辑工具和Windows脚本宿主等内容。

对于每个拒绝规则，策略指定一个文件名和最低文件版本。注意，在拒绝规则中，最低版本实则是最高版本。这就是说，规则仅适用于版本号低于指定版本的文件。由于每个规则的版本设置均为65535.65535.65535.65535，这是绝对最大值，这就确保了任何版本的可执行文件均无法执行。文件名和版本从可执行文件的版本资源中提取，这意味着仅仅将cmd.exe重命名为badger.exe并不能解决问题，策略会看到版本资源中的原始文件名并阻止执行。如果尝试修改版本资源，那么文件的签名不再匹配，你就无法通过签名策略。

对于微软为何要全力阻止CMD这样的东西，原因尚不十分清楚。我们确实可以用其运行命令，但签名策略一定程度上限制了可运行什么可执行文件。阻止PowerShell和WScript我还较为理解，但正如我们稍后会看到的，这些文件策略规则只能作为防止我们实现任意代码执行的减速带。

允许的签名者

现在我们来看看DG策略允许什么签名者（假设其未被文件规则阻止）。首先，DG策略定义允许的签名者列表，该列表稍后在策略配置中引用。允许的签名者列表如下：

大多数签名证书使用一种特殊的“知名”格式，仅用一个数字值来标识证书。找出这些数字值对应的证书可能比较麻烦。还好，Win10S中的Powershell ConfigCI模块有示例策略文件，比如Default_WindowsEnforced.xml，即使其未明确显示使用的证书，但至少给出了名称（毕竟其可能是多个Microsoft Product Root 2010证书）。比如，“MicrosoftProduct Root 2010”可能是以下root（是Win10S中几乎所有签名文件的root证书）：

但是，由白名单签名者签名还不够，这未免太多简单。你还必须在证书链中具有特定的增强型密钥用法（EKU）。因此，比如，签名者ID_SIGNER_WINDOWS_PRODUCTION_USER必须具有OID值为1.3.6.1.4.1.311.10.3.6的EKUID_EKU_WINDOWS。Windows二进制文件设置了该EKU，但如果由相同root签名的二进制文件（比如WinDBG）也由微软签名，但未设置该EKU，这意味着其不加载。从这一信息我们可以理解由应用商店签名意味着什么。这是特定证书链和特定应用商店EKU的结合。这反映在ID_SIGNER_STORE签名规则中。

对于内核代码，允许以下签名者：

对于用户模式，允许以下签名者：

这里唯一突出的是ID_SIGNER_DRM的用户模式签名，因为其是DRM的预信任的root密钥。几乎肯定可以从多个图形驱动程序为链到该root的证书获取一个私钥。我尚未对此进行测试，但是虽然可通过从内核驱动程序获取私钥而链到该root（假设其在软件中），但你可以构建的链可能不适合代码签名，但这值得一看。

签名者的最终用途是指定谁可以签署和更新策略。要使用未签名的策略，必须设置“Enabled:Unsigned System Integrity Policy”。但是，如上文所述，情况并非如此。你可以在以下代码段中看到哪个签名者可以签署策略。

该策略使用的是ID_SIGNER_WINDOWS_PRODUCTION_USER_2011，这是一个“待签名”证书，而非“知名”证书。所以我们需要找到匹配这个哈希值的实际证书。但是据我们推测，这几乎肯定是签署现有winsipolicy.p7b文件的root之一。我们可以使用Matt的脚本中的Get-CIBinaryPolicyCertificatecmdlet来转储证书，然后使用ConfigCI Powershell模块生成TBS值，我们可以看到这与之前的TBS值匹配：

结论

总体而言，从基本的DG策略角度来看，Win10S似乎是合理的。实际上，只有微软签名的代码可以运行，还有就是证书中有WHQL或Windows EKU的代码，因此，除操作系统预装的东西之外，要找到可以利用的有用东西很困难。当然，通过Desktop Bridge应用程序（应用商店有效签名的Win32应用程序），再加上Windows驱动程序开发者水平并非很高超，无疑能找到一些可安装到系统来利用的代码。你只需要看看Office，Office允许从应用商店安装，其具有完整的VBA宏功能。

缺少的是未使用任何基于Hyper-V的执行——以通过HyperGuard或HVCI代码完整性执行限制删除策略或确保内核模式完整性。这是严重的缺点，并不是Win10S不支持Hyper-V，你甚至可以安装完整的Hyper-V和配置工具。这允许你在锁定平台之上在VM中运行正常版本的Windows，这实际上不错。但这意味着系统完整性策略不受很好保护，我们将在后续文章对此进行探讨。