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:WindowsBootEFI文件夾中，名為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，這實際上不錯。但這意味著系統完整性策略不受很好保護，我們將在後續文章對此進行探討。

*本文作者：華為未然實驗室，轉載請註明來自 FreeBuf.COM

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！