譯者：WisFree
預估稿費：190RMB
投稿方式：發送郵件至linwei#360.cn，或登陸網頁版在線投稿
寫在前面的話
我所做的研究不僅是“反分析”，而且我還想繞過安全分析并執行惡意代碼。因此， 通過研究我發現了一種能夠繞過常見安全分析工具的方法，今天給大家介紹的就是Sysinternals Suite。簡而言之，在Sysinternals Suite的幫助下，我可以在不需要管理員權限或SEDebug權限的情況下完成我的“反分析”操作。最終實現的效果就是：惡意程序正在運行，但不會顯示在Procexp.exe之中。
Sysinternals Suite
Sysinternals Suite是微軟發布的一套非常強大的免費工具程序集，一共包括將近70款Windows工具。用好Windows Sysinternals Suite里的工具,你將更有能力處理Windows的各種問題,而且不用花一分錢。Sysinternals 之前為Winternals公司提供的免費工具，Winternals原本是一間主力產品為系統復原與資料保護的公司，為了解決工程師平常在工作上遇到的各種問題，便開發出許多小工具。之后他們將這些工具集合起來稱為Sysinternals，并放在網絡供人免費下載，其中也包含部分工具的源代碼，該工具集一直以來都頗受IT專家社群的好評。
Procexp的“隱藏復活節彩蛋”-“HiddenProcs”
首先我研究的是Procexp（Procexp是windows系統進程管理的一個比較方便的工具,能快速的發現病毒,結束不必要的進程。除此之外，它還可以詳盡地顯示計算機信息：CPU、內存使用情況、DLL和句柄等信息）。我在IDA中對Procexp進行了分析，并且發現了一段非常有意思的代碼，具體如下圖所示：
這段代碼會搜索一個名叫“HiddenProcs”的MULIT_SZ寄存器值。如果這個值存在的話，它將會對一系列新生成的進程名進行解析操作。我原本打算將這些代碼提取出來進行進一步分析，但不幸的是，我發現負責隱藏這些進程名的實際代碼其實并不存在（不知道是不是IDA的問題），所以我其實發現的是一個無效的注冊表鍵，于是我只能換一種辦法了。
Procexp鏡像劫持一（結果：失敗）
如果我們可以劫持procexp的話，那么我們就可以控制它顯示給用戶的內容了。當你在64位操作系統中運行Procexp32.exe（或者其他的32位 Sysinternal工具）的時候，它將會在本地磁盤中導出一個64位版本的進程，然后再自動運行這個64位的版本。這樣一來，如果我們能能夠劫持這個進程的話，會怎么樣呢？
實際上，我們的目標就是如何利用Procomon32來注入Payload或運行惡意代碼。這個程序負責向本地磁盤寫入目標進程的64位版本并在64位操作系統中運行該進程。請大家先看看上面這張圖片，注意圖片頂部綠色的節點（Drop64bitProcExp函數）以及圖片底部粉色的節點（CreateProcessW），這兩段程序在執行的過程中，兩者之間有一定的時間間隔。因此，如果我們能夠保證讓ProExp32.exe在上圖中紅色部分的地方運行得盡可能的久，我們就可以不斷地嘗試寫入惡意進程了，但我們能不能在CreateProcess被調用之前劫持整個進程呢？
接下來我便對此進行了嘗試，我開發了一個簡單的PoC，然后將我的線程設置成了TIME_PRIORITY_TIME_CRITICAL，并嘗試向目標程序寫入我自己的代碼。我的目標就是在上圖所示的那兩個節點之間執行我自己的惡意代碼。
當這個程序正在運行并且用戶嘗試打開ProcExp時，我得到了如下圖所示的錯誤信息。就此看來，我的鏡像劫持方法并沒有成功，我還得嘗試其他的方法。
Procexp鏡像劫持二（結果：成功）
在對文件生成代碼（負責生成進程64位版本的代碼）進行了深入分析之后，我們發現如果“wfopen_s(“ProcExp64.exe”, “wb”)”無法成功的話，ProcExp并不會立刻退出執行。
那么這里肯定就存在安全漏洞了，只要“GetFileAttributes”能夠成功執行，那么它將會忽略fopen可能會返回的錯誤信息。
這樣一來，鏡像劫持很容易就能夠實現了。我們只需要將我們自己的“ProcExp64.exe”寫入到臨時目錄之中，然后將該程序的屬性修改為“只讀”。接下來，“fopen(“ProcExp64.exe” ,”wb”)”將會失敗，但是當程序嘗試執行“GetFileAttributes”時將會成功，而程序的執行流程將會帶領我們正確地“走”到CreateProcess。
如下圖所示，我們的進程在本地磁盤的臨時目錄%temp%中生成了一個偽造的ProcessExplorer，文件名稱為“PROCEXP64.exe”，該文件的屬性為“只讀”屬性（你可以自己在家動手嘗試一下）。我生成的是一個很簡單的程序，它只會在命令控制臺中輸出字符串“Hijacked”。具體如下圖所示:
接下來，當我們嘗試運行Procexp.exe時，它便會觸發其中的安全漏洞，并且運行我們所生成的“PROCEXP64.exe”。
劫持效果如下圖所示：
我設計的這個PoC只是想告訴大家這種劫持方法其實是可行的，但我認為我們其實可以做得更加好，因為上面給出的這種劫持方法只能適用于在64位操作系統中運行32位Sysinternals工具的場景。
DLL劫持（最終的解決方案）
接下來給大家介紹的就是我最終的解決方案了，即最終的PoC。首先我們來看一看Sysinternal的注冊表鍵，大家可以看到其中一個名叫“DbghelpPath”的注冊表鍵。這個注冊表鍵對于絕大多數應用程序來說都是可寫的（USER注冊表單元）：
DbghelpPath注冊表鍵指向的是一個存放“dbghelp.dll”文件的可信路徑。非常好，我所要做的就是劫持這個路徑。我給出的PoC代碼可以讓這個注冊表鍵指向臨時目錄%TEMP%，然后我再向臨時目錄(%TEMP%/DbgHelp.dll)中存放一個我自己的惡意dbghelp.dll文件就可以了。當Procexp開始運行之后，它將會加載這個路徑下的DLL文件。當它成功加載了我的惡意DLL文件之后，我們就可以利用ProcExp程序來隱藏我們的惡意進程了。點擊【這里】獲取我的PoC代碼。
整個劫持過程需要涉及到對ProcExp進程的運行邏輯以及鏈表結構進行逆向分析，下圖顯示的就是我們的PoC代碼成功利用ProcExp運行了一個名叫“Malicious.exe”的惡意進程：
總結
整個劫持過程其實并不難，而最棒的一點就在于，幾乎每一款SysInternal工具都擁有這樣一個可寫的DbgHelp路徑注冊表鍵，所以從理論上來說，你可以利用任何一款Sysinternal Suite工具來實現本文所介紹的攻擊技術。
本文簡要介紹了流行的三個瀏覽器動態Fuzz工具cross_fuzz、grinder、X-Fuzzer的原理及其優缺點，并提供了一種通過動靜結合的方式兼顧可重現性、通用性、高效性、自動化程度高的瀏覽器fuzz方法。
小編注：《瀏覽器fuzz框架介紹》文章將刊登在最新的綠盟科技技術刊物上。請關注綠盟科技博客 http://blog.nsfocus.net/web-browser-fuzzing/
引言
Fuzz（模糊測試）是一種側重于發現軟件安全漏洞的方法。典型地模糊測試過程是通過自動的或半自動的方法，反復驅動目標軟件運行，并為其提供”精心”構造的輸入數據，同時監控軟件運行的異常，進而根據異常結果及輸入數據查找軟件的安全漏洞。隨著Smart Fuzz的發展，RCE（逆向代碼工程）需求的增加，其特征更符合一種灰盒測試。其簡要流程圖如下：
Web瀏覽器是網絡應用中使用最廣泛的軟件之一，IE、FireFox、Chrome等三款主流瀏覽器占據了Web瀏覽器市場的大部分份額，其自身的安全性備受關注、影響廣泛。本文介紹的瀏覽器fuzz則是以上述三款瀏覽器作為fuzz的主要目標，以內容（css、html、js）隨機的html頁面作為被測瀏覽器的輸入，并監控瀏覽器運行的異常情況，查找其安全漏洞。
瀏覽器fuzz是查找瀏覽器漏洞的一個常用且有效的方法，公開的動態瀏覽器fuzz工具有cross_fuzz、grinder、X-Fuzzer等，這些工具基本都通過javascript腳本進行fuzz操作，同時通過hook函數、localStorage本地存儲等技術手段動態記錄fuzz操作日志，捕獲到異常后再根據記錄日志進行還原。
現有瀏覽器fuzz工具動態記錄日志方式可能會影響被測瀏覽器的執行環境進而導致有時不能夠重現異常；且其在記錄日志方法上通用性（如IE的ActiveXObject）、穩定性（grinder hook函數）欠佳。
很多瀏覽器fuzz工具每運行一個測試用例都會重啟待測瀏覽器進程，因為瀏覽器重啟在運行一個測試用例過程中耗時占比較大，進而導致fuzz效率不高。
有的瀏覽器fuzz工具（如經典的cross_fuzz）在遇到crash時會停止fuzz，自動化程度不夠。
本文在總結了現有動態瀏覽器fuzz工具優缺點的同時，提供了一種通過動靜結合的方式兼顧可重現性、通用性、高效性、自動化程度高的瀏覽器fuzz方法及其工具NBFuzz（New Browser Fuzz）。
corss_fuzz 簡介
cross_fuzz由google的安全研究人員Michal Zalewski開發，支持多個瀏覽器fuzz，并專門針對IE瀏覽器作了優化。這個工具及在其基礎上衍生的瀏覽器fuzz工具發現了大量的瀏覽器安全漏洞，其設計思想對瀏覽器漏洞挖掘產生了深遠的影響。
cross_fuzz主要闡述了瀏覽器fuzz的設計思想，只是個演示性的功能模塊，還不是一個完整的瀏覽器自動化fuzz工具，如關鍵的操作日志記錄、異常監控等還需要用戶自己來實現。
界面
流程圖
X-Fuzzer 簡介
X-Fuzzer是由安全研究人員Vinay Katoch開發的一款輕量級的動態瀏覽器fuzz工具，其日志記錄采用了主流瀏覽器通用localStorage本地存儲、document.cookie，即使瀏覽器異常崩潰時日志也能夠保存。此工具dom元素fuzz操作、日志記錄都很簡單，還需自行完善；而且此工具沒有異常監控模塊，不能實現自動化fuzz。
界面
功能模塊圖
grinder 簡介
grinder是一個自動化瀏覽器fuzz框架，客戶端node主要采用ruby語言編寫。
其日志記錄通過向被測瀏覽器進程注入grinder_logger.dll ，進而hook javascript函數parseFloat在jscript9.dll、mozjs.dll等腳本引擎中的實現函數，這樣需要記錄日志時只需調用parseFloat函數，日志記錄功能由grinder_logger.dll中相應的hook回調函數完成。需要注意的是下載相應dll符號文件后才能完成hook操作，且最近版本的Firefox已不包含mozjs.dll導致hook函數失敗。此日志記錄方法穩定性、通用性欠佳。
監控模塊（ dbghelp.dll 、 symsrv.dll ）負責啟動、監控被測瀏覽器，記錄其異常信息，完成fuzz自動化 。
重現模塊（ testcase.rb ）根據日志重現POC。
具體fuzz操作需要用戶自行完善。
界面
NBFuzz
NBFuzz 日志記錄方法總結
ActiveXObject只適用于IE。
cookie、html5的localStorage適合IE、Firefox、Chrome等主流瀏覽器，但存儲大小有限制（cookie 4K、localStorage 5M），且需要設置瀏覽器支持cookie、記錄歷史。IE本地打開html文件時不支持localStorage。
html5本地數據庫indexDB、SQLite的通用性不足（IE不支持或部分支持）且使用較復雜。
XMLHttpRequest通用性較好，但每一步fuzz操作都需要實時記錄，通信總耗時較長，影響fuzz效率。
XMLHttpRequest改進：fuzz操作localStorage本地實時存儲；每個測試用例開始時localStorage設置異常標志，沒有異常在測試用例結束時置空異常標志；下一個測試用例通過XMLHttpRequest將產生異常的fuzz記錄上傳服務器。這樣就解決了C/S實時記錄fuzz操作日志的通信瓶頸且localStorage 大小能夠滿足要求。
拋棄fuzz操作日志：動態記錄日志可能影響重現性（如indexDB 、 localStorage 等操作），通用性、穩定性（如grinder hook函數）欠佳；NBFuzz直接生成測試用例，不記錄fuzz操作日志，且生成的測試用例不存在隨機操作，保證了可重現性、通用性。
NBFuzz模塊圖
通過測試用例生成程序生成大量指定瀏覽器的fuzz測試用例，將生成的測試用例和調度頁面一并置于web服務端，監控模塊打開待測瀏覽器訪問調度頁面，調度頁面通過內嵌iframe頁面順序調用測試用例；監控模塊記錄被測瀏覽器異常或者超時重啟被測瀏覽器進程，保障瀏覽器fuzz的自動化；最后分析監控模塊記錄的異常信息，找出可疑crash，根據其異常時間查找web服務端log文件中修改時間與之相匹配的文件，獲取調度頁面發來的導致異常的測試用例名稱，進而重現crash，進一步判斷漏洞的可利用性。
測試用例生成
界面
根據選定的瀏覽器類型生成大量包含其特性（不同的屬性、函數、垃圾回收機制等）的測試用例，由于使用了IE特有的ActiveXObject進行本地文件操作所以要求使用IE運行此程序，使用js寫包含js的測試用例。
流程圖
測試用例加載（調度模塊）
為解決每一個測試用例重啟瀏覽器進程瀏覽器啟動耗時占比大的問題，NBFuzz的調度模塊通過內嵌iframe打開測試用例，一個測試用例完成后調度頁面reload操作執行下一個測試用例，為防止頁面不響應異常監控模塊在超時后重啟待測瀏覽器；同時為了防止web服務端記錄log文件過多加入了不夠精確的異常判斷機制，因為超時重啟將導致異常標志不能正常置false，產生誤報，盡管如此也會大大減少log日志。
調度模塊流程圖如下：
瀏覽器Fuzz總結
隨著瀏覽器的安全機制（如IE的延遲釋放、隔離堆等）不斷加強，其安全漏洞井噴之勢已經得到遏制；而目前仍應用廣泛的flash由于其安全機制的不健全逐漸成為安全研究的熱點，安全漏洞亦呈現爆發的態勢，可以預見不久的將來若其仍固步自封，必將步java的后塵，逐漸被用戶所”拋棄”。
flash fuzz框架只需在NBFuzz框架的基礎上進行些許的改變即可，如需增加as3測試用例編譯成swf的過程。
請關注綠盟科技博客 http://blog.nsfocus.net/web-browser-fuzzing/