CVE-2020-16939：Windows 組策略 DACL 覆蓋權限升級

十月，Microsoft發布了一個修補程序來糾正Windows組策略客戶端中的漏洞。該漏洞可能允許攻擊者以提升的權限執行代碼。安全研究員Nabeel Ahmed向ZDI程序報告了此漏洞。他很親切地提供了詳細的文章和概念證明，詳細介紹了ZDI-20-1254 / CVE-2020-16939。*

此漏洞濫用了SetSecurityFile組策略更新期間在上下文中執行的操作NT AUTHORITY\SYSTEM。對特定文件夾內的所有文件執行此操作。攻擊者可以創建與另一個文件夾的目錄連接，從而獲得對該文件夾內容的完整權限。

此漏洞與CVE-2019-0841和CVE-2020-1317相似，但最終結果相同，只是此漏洞是由組策略更新觸發的。

介紹

從Windows 8.1開始，就開始使用組策略緩存。出于性能目的，它將組策略的副本保留在本地緩存中。用戶GPO設置存儲在中%programdata%\Microsoft\GroupPolicy\Users，而計算機GPO設置存儲在中%windir%\System32\GroupPolicy\DataStore。

漏洞

如前所述，當發生組策略更新時，策略將在本地緩存。我們對“用戶GPO設置”緩存位置尤其感興趣%programdata%\Microsoft\GroupPolicy\Users。這很有趣，因為%programdata%默認情況下即使是低特權用戶也可以寫。

我們首先來看一下gpupdate在Windows中以低特權用戶身份啟動命令時文件的外觀。我們將使用Sysinternals的Process Monitor來查看各種文件操作。

我們將使用ProcMon過濾器并突出顯示以下屏幕截圖中顯示的設置：

圖1-進程監視器過濾器設置

圖2-進程監視器突出顯示設置

該gpupdate /target:user /force命令的輸出如下所示：

圖3-Procmon輸出組策略更新用戶GPO

當我們向下滾動操作列表并跳過與流程創建相關的部分時，我們很快就會開始看到SetSecurityFile顯著執行的操作而沒有模擬（缺少突出顯示）。如果書面的自由訪問控制列表（DACL）太寬容，那可能很重要。

圖4-確定的“ SetSecurityFile”操作

稍后我們將看到，編寫的某些DACL是允許的，從而完全控制了攻擊者。但是，我們仍然沒有可利用的條件，因為這些位置中的文件對于進行特權升級沒有用處。為了嘗試重定向這些DACL寫入，以便將它們應用于對我們有用的文件，我們可以嘗試在文件夾層次結構中放置目錄連接。這可能導致組策略更新過程改為打開我們選擇的目標文件夾，然后在其中寫入DACL。

查看文件夾上的權限，我們注意到第一個障礙：如果已經發生了組策略更新，您會注意到在%programdata%\Microsoft\GroupPolicy\Users目錄下，將基于每個域用戶為其創建一個附加目錄SID。此文件夾的權限不允許我們寫。文件夾的所有者是Administrators組，并且該Users組僅具有從%programdata%\Microsoft文件夾繼承的讀取和執行權限。

圖5

但是，如果我們向下移動文件夾結構并分析每個文件夾，則您會注意到一個小的差異。所述sysvol的文件夾下%programdata%\Microsoft\GroupPolicy\Users\<SID>\Datastore\0\的文件夾具有低特權用戶作為文件夾（在下面的截圖看到的）的所有者：

圖6

由于低特權用戶是sysvol文件夾的所有者，因此他們可以更改該文件夾的權限而不會出現太大問題。為此，低特權用戶應禁用繼承，然后向自己授予“完全控制”權限。

一旦完成，低特權用戶就可以在sysvol目錄下寫入文件，并且在NT AUTHORITY\SYSTEM運行組策略更新時，該文件夾下的每個文件夾和文件都將受到DACL寫入操作。

現在，這開始變得越來越有趣。通過在sysvol其中與選定位置的連接處創建一個新文件夾，我們可以控制組策略服務將打開的文件和文件夾。在下面的實驗中，我們要求它轉到C:\Program Files (x86)\Microsoft，并且它服從于低特權用戶設置的Directory Junction。

圖7-組策略服務后面是目錄連接（重新分配點）

但是，通過放置目錄連接來控制流并不一定意味著低特權用戶可以濫用它來獲取有用的東西。我們感興趣的有用部分是DACL寫操作。在目錄聯結“重定向”之后，寫入操作會發生嗎？

圖8

在上面的屏幕截圖中，您可以看到DACL權限確實被成功覆蓋。

下一個問題是書面的DACL是否足夠寬容，從而為攻擊者提供了特權升級的途徑。 Alas, no:

圖9-DACL權限之前

圖10-組策略更新和目錄結點重新解析后的DACL權限

在成功地將其解析到多個位置之后，我注意到當DACL寫入過程由于SYSTEM用戶沒有足夠的特權而突然中斷，或者由于所討論的文件正在使用中而被寫入時，寫入的權限實際上授予了低特權用戶Full Control權限。

圖11-訪問錯誤導致DACL寫入過程被停止

一種強制錯誤的方法是在完成寫入DACL操作之前刪除連接點。可以使用機會鎖（oplock）檢測刪除交界點的正確時刻 。

Exploit

我們可以使用此行為full control通過使用聯結點和oplock來設置文件夾/文件（其中SYSTEM擁有權限或SYSTEM是文件的所有者）上的文件許可權。

圖12-低特權用戶對VMware Tools文件夾沒有足夠的特權

如您所見，我們當前以沒有管理特權的普通用戶身份登錄。在此示例中，我們將嘗試控制VMware Tools位于中的文件C:\Program Files\VMware。目前，我們僅對文件夾和其中的文件具有讀取/執行權限。

我們創建了組策略的高速緩存中的結點文件夾sysvol指向C:\Program Files\VMware。連接點的名稱應以開頭$。我們還創建了另一個文件夾，其中包含一個隨機文件。在該隨機文件上，我們設置了一個OpLock，因此可能導致錯誤。

一旦觸發了OpLock，我們將刪除連接點并釋放OpLock。由于DACL寫入僅部分起作用，并且刪除了聯結點，因此Full Control保留了權限。成功利用后，當前用戶對目標文件夾及其中的文件擁有完全權限。用戶現在可以修改文件的內容，從而導致特權升級。

圖13 –低特權用戶現在對“ VMware Tools”文件夾具有完全權限

下面是第二個示例，其中低特權用戶嘗試劫持其中的文件C:\Windows\System32\config。在這種情況下，OpLock永遠不會觸發，因為該操作已被DACL寫入操作失敗的先前文件暫停。但是，config文件夾中的部分內容具有新的DACL（包括SAM文件）。

圖14-低特權用戶現在對“ SAM”文件具有完全權限

概念證明

我提供了一個PoC（https://github.com/thezdi/PoC/tree/master/...），它可以自動執行劫持。它應該以沒有管理權限的低特權用戶身份執行。

1. 將PoC提取到本地硬盤上普通用戶可寫的位置。
2. 通過傳遞一個參數來執行PoC可執行文件，該參數指定您要將連接點重定向到的文件夾的路徑。例如： FolderTakeover.exe?C:\Windows\System32\Tasks