Windows Standard Collector服務中的特權提升漏洞實例分析

Windows Standard Collector服務中的特權提升漏洞實例分析，針對這個問題，這篇文章詳細介紹了相對應的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。

如果你對尋找bug的過程不感興趣，或者是“太長不看”那種，那么ATREDIS-2018-0004是個不錯的選擇，而且這里還有一個概念性證明（PoC）。

Process Monitor已經是我研究和開發時最喜歡的一個工具。在開發安全工具時，我頻繁地用它來監視工具如何與Windows交互，以及它們是如何被檢測到的。今年早些時候，我在Visual Studio中調試一段代碼并用Procmon監視時注意到一些有趣的行為。一般來說，我會為Visual Studio設置過濾以減少干擾。但在設置過濾之前，我注意到一個SYSTEM進程寫入用戶擁有的目錄：

StandardCollector.Service.exe 寫入用戶臨時文件夾

當擁有權限的服務寫入用戶擁有的資源時，可能會產生符號鏈接（symlink）攻擊向量的可能性，為了確定如何直接影響服務的行為，我通過查看服務加載的庫開始研究Standard Collector服務：

Visual Studio DLLs被StandardCollector.Service.exe加載

庫的路徑顯示Standard Collector服務是Visual Studio診斷工具的一部分，在瀏覽了相關文件夾的一些庫和可執行文件之后，我發現有幾個二進制文件是用.NET寫的，其中包括一個叫VSDiagnostics.exe的獨立命令行工具，下圖為控制臺的輸出：

VSDiagnostics命令行工具的輸出

將VSDiagnostics加載到dnSpy中會發現很多關于該工具以及它如何與Standard Collector服務服務交互的內容。首先，獲取IStandardCollectorService的實例，并使用會話配置創建ICollectionSession：

初始配置診斷收集會話的步驟

接下來，用CLSID和DLL名稱將代理添加到ICollectionSession，這也是一個比較有趣的用戶控制行為。它也讓我記得以前的研究就是利用了這種DLL加載行為。此時，看起來Visual Studio Standard Collector服務與Windows 10中包含的診斷中心Standard Collector服務非常相似甚至相同。我開始使用OleViewDotNet查詢服務來查詢其支持的接口：

OleViewDotNet中的Windows診斷中心Standard Collector服務

查看IStandardCollectorService的proxy definition會顯示其他熟悉的接口，特別是VSDiagnostics源中的ICollectionSession接口：

OleViewDotNet中的ICollectionSession接口定義

記下接口ID（“IID”）后，我返回到.NET操作庫來比較IID，然而發現它們不同：

具有不同IID的Visual Studio ICollectionSession定義

深入研究.NET代碼，我發現這些Visual Studio特定的接口是通過代理DLL加載的：

VSDiagnostics.exe函數加載DLL

對DiagnosticsHub.StandardCollector.Proxy.dll中的ManualRegisterInterfaces函數的預覽顯示了一個迭代IID數組的簡單循環。包含在IID數組中的是屬于ICollectionSession的數組：

ManualRegisterInterfaces DLL的函數

要注冊的IID數組中的Visual Studio ICollectionSession IID

在更好地理解Visual Studio Collector服務之后，我想看看是否可以重用相同的.NET代碼來控制WindowsCollector服務。為了與正確的服務進行交互，我需要用正確的Windows Collector服務CLSID和IID替換Visual Studio CLSID和IID。接下來，我使用修改后的代碼構建一個客戶端，該客戶端只是創建并啟動了Collector服務的診斷會話：

用于與Collector服務交互的客戶端的代碼片段

啟動Procmon并運行客戶端會在指定的C:\Temp臨時目錄中創建多個文件和文件夾。在Procmon中分析這些事件表明，初始目錄創建是在客戶端模擬的情況下執行的：

雖然初始目錄是在模擬客戶端時創建的，但后續文件和文件夾是在沒有模擬的情況下創建的：

在深入了解其他文件操作之后，有幾個比較突出。下圖是Stand Collector服務執行的各種文件操作的注釋細分：

最有趣的行為是在創建診斷報告期間發生的文件復制操作。下圖顯示了相應的調用堆棧和此行為的事件：

現在確定了用戶影響的行為，我構建了一個可能實現的任意文件創建漏洞利用計劃：

1.服務調用CloseFile后立即獲取合并的ETL文件（{GUID} .1.m.etl）的操作鎖定。

2.查找報告子文件夾并將其轉換為掛載點于C:\Windows\System32。

3.用惡意DLL替換{GUID} .1.m.etl的內容。

4.釋放op-lock以允許通過掛載點復制ETL文件。

5.使用復制的ETL作為代理DLL啟動新的會話，從而觸發提權的代碼執行。

為了編寫漏洞利用程序，我通過利用James Forshaw的NtApiDotNet C＃庫創建op-lock和掛載點來擴展客戶端。下圖顯示了用于獲取op-lock的代碼片段以及相應的Procmon輸出，說明了循環和op-lock獲取：

獲取文件上的op-lock實質上會停止CopyFile，且允許覆蓋內容，并控制CopyFile何時發生。接下來，該漏洞會查找Report文件夾并掃描它以查找需要轉換為掛載點的隨機命名的子目錄。成功創建掛載點后，.etl的內容將被惡意DLL替換。最后，關閉.etl文件并釋放op-lock，允許CopyFile操作繼續。 此步驟的代碼段和Procmon輸出如下圖所示：

有幾種技術可以通過任意文件寫入來提升權限，但是對于此漏洞，我選擇使用collector服務的代理DLL加載功能來使其與單個服務隔離。你會注意到在上圖中，我沒有使用掛載點+符號鏈接技巧將文件重命名為.dll，因為DLL可以任何擴展名被加載。出于此漏洞的目的，DLL只需要在System32文件夾中，以便Collector服務加載它。下圖顯示了漏洞利用程序的成功執行以及相應的Procmon輸出：

上面的截圖顯示漏洞是以用戶“Admin”身份運行的，所以這里有一個GIF，顯示它是作為“bob”運行的，這是一個低權限的用戶帳戶：

你也可以試試SystemCollector的PoC，NtApiDotNet庫同時也是一個Powershell模塊，可以讓事情變得更簡單。

關于Windows Standard Collector服務中的特權提升漏洞實例分析問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。