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

研究方案

白名單機(jī)制

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

實(shí)現(xiàn)直接提權(quán)

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

SyScan大會中的方法

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

圖1

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

圖2

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

圖3

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

圖4

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

圖5

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

圖6、7

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

圖8

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

圖9

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

取代MSU文件

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

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

shaolong