簡要概述

9月24日亞洲知名安全技術峰會SyScan在北京召開。在大會上Instruder做了《深入思考UAC背后的安全問題》演講。會后筆者針對這一議題做了詳細分析與測試，就UAC提升用戶權限的的問題做了總結與分析。

研究背景

現(xiàn)在WIN7操作系統(tǒng)以經(jīng)大量普及，UAC的安全機制以成為滲透過程中最為明顯的絆腳石，UAC會使大量滲透工具失效，木馬無法運行，如何突破UAC的層層防護是一直以來研究的重點。
研究目的

經(jīng)過學習與研究應該實現(xiàn)，在當前用戶權限下，繞過UAC提示直接運行程序，并可以實現(xiàn)修改啟動項，釋放文件到系統(tǒng)目錄等功能，而這一過程必須在用戶沒有任意察覺的情況下完成。

研究方案

白名單機制

從用戶賬戶控制對權限進行保護的基本過程可以看到，在用戶以管理員權限運行程序的 過程中，用戶賬戶控制在向用戶進行提權詢問前，將會先查詢本地系統(tǒng)中的白名單以決定是 否直接放行，因此，白名單機制是用戶賬戶控制中的一個重要部分。用戶賬戶控制限制著程 序使用高級權限才能進行的操作，但是，這樣的機制同樣也會對系統(tǒng)本身的程序造成影響，微軟也不希望系統(tǒng)程序的運行也詢問用戶，因為他們本身是安全的。因此，微軟則在 UAC 中添加了白名單機制，即在系統(tǒng)中記錄有一張表單，對于表單中的系統(tǒng)程序，將不限 制其直接提升到管理員權限。系統(tǒng)中的白名單程序有多個，其中，msconfig、taskmgr、perfmon、cleanmgr 等平時常用的程序都在其中。

實現(xiàn)直接提權

比較常用的利用系統(tǒng)程序的方法是利用系統(tǒng)動態(tài)加載 DLL的特性，在系統(tǒng)中還有一份名單為 KnownDlls，當一個程序需要動態(tài)加載 DLL 的時候，會先在這份名單之中進行查找，如果找到則加載相應路徑的DLL 文件，如果沒有找到則依照當前目錄、 System32 目錄的順序進行查找，因此如果能找到一個程序動態(tài)調(diào)用的 DLL 文件不在KnownDlls 中，而在 System32 下面，則可以偽造一個相應的 DLL，來實現(xiàn)借助其他程序來 執(zhí)行需要的操作。在所有白名單程序中，正好有這樣一個程序，即 sysprep.exe，它的位置為 System32/sysprep/，而它在啟動時，會動態(tài)加載一個 CRYPTBASE.DLL，這個 DLL 在 System32 下面，因此 sysprep.exe 會在當前目錄尋找的時候加載失敗，繼而轉到 System32 目錄查找， 試著臨時生成一個假的 CRYPTBASE.DLL 放在 sysprep 文件夾下，在 sysprep.exe啟動時，將加載假的 CRYPTBASE.DLL，從而執(zhí)行我們需要的操作。sysprep.exe 加載假 CRYPTBASE.DLL線程注入白名單中的程序全部都在系統(tǒng)目錄當中，因此要把生成的假 DLL 復制到程序目錄中， 將會由于權限問題而觸發(fā) UAC，這樣便失效了。因此，需要特別的方法來把假 DLL 給復制到系統(tǒng)目錄內(nèi)，并且不會觸發(fā)系統(tǒng)的權限控制。這一步的操作也需要系統(tǒng)白名單的程序來實現(xiàn)，選用的程序為EXPLORER進程，首先使用遠程線程的方法把DLL注入到EXPLORER進程，然后再通過EXPLORER把CRYPTBASE.DLL復制到指定目錄UAC不會提示。所有操作完成后啟動sysprep.exe我們的DLL就會被加載，從而繞過成功。但這個方法缺點也很明顯，在注入EXPLORER進程時，殺毒軟件已經(jīng)開始關注了。

SyScan大會中的方法

與傳統(tǒng)方法也有類似之處，議題作者Instruder采用的方法也是白名單的方法但又有不同之處，頗為巧妙，作者使用的方法為利用操作系統(tǒng)自己的升級程序WUSA.EXE，讀取釋放文件，這個過程是不會觸發(fā)UAC的，利用這個機制可以輕松突破UAC限制，下面我們一步一步演示實現(xiàn)，首先把wusa.exe找出來，此文件位于 c:\windows\syswow64目錄如圖1所示。

圖1

找到這個文件后，運行一下，看一下它的具體使用方法，具體情況如圖2所示。

圖2

找到WUSA.EXE后我們還要找一個 MSU的文件用來做測試用，我從自己電腦中隨便搜索一些MSU文件出來如圖3所示。
 

圖3

到目前為至準備工具基本就需了，我們來做實驗，使用WUSA.EXE把一個MSU文件釋放一下，看能否成功，實驗方法如下，復制一個MSU文件到D:\TEMP目錄，然后在CMD下切換目錄到c:\windows\syswow64，最后運行wusa.exe d:\temp\msu.msu /extract:d:\temp 這時看到一個很快的進度一閃而過，我比較愚鈍沒能抓下圖來，去D:\TEMP目錄看一下是什么情況如圖4所示。
 

圖4

可以看出文件以成功釋放，這樣很好，下一步繼續(xù)實驗，把釋放目錄修改一下，直接釋放到系統(tǒng)目錄WINDOWS下，看會如何表現(xiàn)，執(zhí)行wusa.exe d:\temp\msu.msu /extract:c:\windows
結果很理想，成功釋放而且沒有觸發(fā)UAC提示，而我此時的UAC設置如圖5所示。
 

圖5

到目前為至我們可以考慮一些邪惡的事情了，比如釋放一些木馬病毒DLL劫持的文件到系統(tǒng)目錄這樣子，不會觸發(fā)UAC程序，同時木馬與病毒也會開機啟動了，再繼續(xù)向下實驗吧目前思路上是沒問題了，那么要考慮的是MSU文件了，這個文件看一下是有微軟數(shù)字簽名的如圖6、7所示。
 

圖6、7

問題隨之而來，WUSA.EXE會對MSU文件進行簽名校驗嗎？這個我們可以通過破壞數(shù)字簽名來驗證一下，使用16進制編輯工具把MSU文件隨便添加幾個字節(jié)如圖8所示。
 

圖8

現(xiàn)在數(shù)字簽名以經(jīng)被破解，無效了，如圖9所示。
 

圖9

清理之前釋放的文件后，再運行一下進行釋放檢測，看下結果，呵呵結果非常理想，依然成功釋放，這說明 WUSA.EXE對MSU文件是沒有簽名校驗的，我們可以隨便偽造MSU文件了。

取代MSU文件

經(jīng)過一系列的測試，已經(jīng)知道，只要搞定MSU文件就成大功告成了，msu 文件擴展名與 Windows 更新獨立安裝程序相關聯(lián)。msu 文件中包含以下內(nèi)容：
 
 Windows Update 元數(shù)據(jù)，此元數(shù)據(jù)描述了 .msu 文件包含的每個更新包。一個或多個 .cab 文件，每個 .cab 文件代表一個更新。一個 .xml 文件，此 .xml 文件對 .msu 更新包進行描述。
 
看起來還是蠻復雜的樣子，呵呵能不能偷偷懶，想其它方法進行繞過呢，微軟的工具對自己的文件格式兼容性，應該是不錯的，既然是文件包，那就測試微軟的CAB包。繼續(xù)實驗，把MSU文件，換成CAB文件測試，結果很理想，依然可以成功，那么我們的后續(xù)工作就很簡單了，只要把想釋放的文件壓縮到CAB包，再利用上述方法就可以成功釋放了，而且整個過程非常安逸，不會有UAC提示。

此外作者也提供了其實利用方法，總體來看，并不復雜，只要掌握繞過原理，其實現(xiàn)過程都是可以實現(xiàn)的，由于時間關系，沒有一一試驗，有興趣的朋友可以自行測試一下。