CVE-2018-0952：Windows Standard Collector服務中的特權提升漏洞分析
如果你對尋找bug的過程不感興趣，或者是“太長不看”那種，那麼 ofollow,noindex" target="_blank">ATREDIS-2018-0004 是個不錯的選擇，而且 CVE-2018-0952-SystemCollector" rel="nofollow,noindex" target="_blank">這裡還有一個概念性證明（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模組，可以讓事情變得更簡單。
*參考來源： atredis ，FB小編Covfefe編譯，轉載請註明來自FreeBuf.COM