NSC2015文偉平：軟件安全漏洞挖掘技術探討
責編：penggao ｜2015-07-03 17:52:22文偉平：謝謝主持人，非常高興，也有這樣的機會來參加第三屆網絡安全大會，今天我看到這個場景非常感動，這么多參會者還坐在地下，外圍也那么多參會者站著聽著我們的演講。我們北大團隊也參加了第一次的網絡安全大會，也派了一個代表，所以我這里有一些內容可能曾經在第一屆網絡安全大會和第一屆互聯網網絡安全大會講過，如果有一些參會者聽過的話，我可能會說的快一點。
今天和大家探討的主題叫”軟件安全漏洞挖掘技術”。軟件安全漏洞挖掘，國內還有叫漏洞分析，漏洞分析和漏洞挖掘業界也是有區分的，有些就是把漏洞挖掘歸在漏洞分析，我們這個意義上的漏洞挖掘是指對位置漏洞的挖掘。
當前的技術發展，大家也知道，漏洞挖掘本身是很難的問題。大家發現Windows7發現很多遠程管理的漏洞，但Windows7發布之后，大家發現遠程管理漏洞，尤其系統級的變得比較少了，實際這和微軟SDL開發模式有一定的關系，他們有安全的開發平臺。Windows7操作系統里實際它也引入了很多安全機制，上午TK在”內存20年”里也介紹到了一些安全機制，但沒有詳細展開，StackCookie他可能列了1997年的幾篇論文，也就是通常所說的GS，還有SafeSEH，DEP是數據執行保護，和地址空間的隨機化，也就是說這些安全機制的涌入，使得我們能找到安全隱患的點或者Bug，如果Bug不能夠被利用其實還不能算是漏洞，即使我們確定了可能是個安全隱患，但它卻不能夠被利用，使得我們在挖掘一些安全漏洞也變得越來越難。
實際漏洞挖掘技術也是在發展的，既然早期我們主要是通過ST、CTOI或者GES、SGANF（音）這樣一些漏洞的函數，構建函數模型來進行漏洞挖掘。在后期我們會引入路徑模型的概念，包括原代碼審計系統系統，二進制代碼反饋之后也是一種源碼，也就是說我們可以根據代碼直接的上下文關系，語義解析構建出一些路徑模型來挖掘漏洞。系統的安全對抗也是發展的，既然有了新的技術和安全機制同樣也會推出對抗的技術，例如數據執行保護制，可以通過ROP構造出來各種各樣的Gaget，調用系統里相關的函數，因為攻擊者攻擊對方之后實際更多是被攻擊機器上的資源完成他攻擊的過程。
針對地址空間的隨機化，我們知道對噴（音）是最典型的，還有AC3里一些針對漏洞的GsBre（音），還有TK之前提出來的像UZDate數據解構，他們是能構造出來通用Shellcode的一些方法，能夠提高漏洞被利用的成功概率。
以Windows系統為例介紹一下它的內存保護機制，當傳統內存機制，GS、SafeHEP、SafeSEH、DEP和SLF，Windows8里也引入了新的能夠檢測到ROP的方法。對堆進行了更多的改進，比如隨機化的LFH，對頁面屬性的保護，對其他內存方面比如虛指針也提供了相應的安全機制，對于空頁面、內存分配的隨機化，（PPT）大家看右邊這個圖，GS方面它也進行了積極的增強，也就是StackCookie，Windows7和Windows8最大的一個區別，就是在Cookie生成算法里采用了Intel的SQL-key這樣的算法和技術，使得Cookie更難以進行猜測。在SL方面，他又提出了高算地址的隨機化，我想研究過Win8或調試過Win8的系統安全人員應該都很清楚它的機制。DEP里它也提出檢測ROP的機制。
軟件、漏洞挖掘技術，三個標紅的可能是我們在一些大會上面跟大家交流過的，漏洞挖掘技術只是一些思路，并沒有很深的技術，大家一聽可能就很明白。第一種技術應該是很多廠商廣泛使用的一種漏洞挖掘技術，基于Crash信息的，這里的Crash信息可能是基于單機的，實際還有很多網絡上的Crash信息是可以用的。如果微軟Crash信息收集服務器沒有采用加密形式進行傳遞，這些信息對我們是非常有用的，所以對于微軟的Windows系統我們更多的是采用本地的，對于應用軟件，就是對網絡上傳輸的Crash信息是很有分析價值的。
以微軟Windows為例，Windows出現藍屏事件時會有系統轉存，轉存模式有三種：一是完全的淡化，把當前物理內存里的所有信息都存下來；二是核心內容的存儲，除了進程之外的信息我們把它Download下來，三是小內存的存儲，以16位為單位進行轉存。得到這些信息之后，就可以通過微軟自身提供的Win DBG進行分析，每一個出錯的信息都可以形成陷阱針，我們這個陷阱針我們可以通過bing看到它當時出錯的場景，比如堆棧是什么情況，在一條什么指令上出錯，可能大家從這條指令就能夠看出，它在讀一些不應該讀的地址，就是讀出一個錯誤。
回溯之后，我們可以把整個函數調用順序清晰地展示出來。最后我們能看到，可能這個函數是wingzk！SfnINSTRING出現的問題，下一步我們可以借助強大的反饋鏈平臺，像IDA來進一步判斷它是不是存在邏輯的缺陷，判斷它這個漏洞有沒有可能被進行利用。
我們判斷的一個依據，看看用戶態里的參數或數據能不能夠傳遞到內核態里，所以，我們一步步進行回溯，最后發現從用戶態空間傳遞過來的參數沒有做任何判斷，而”esi+8″這個地址可以被我們指定，這種情況下面就意味著我們能夠發現內核里讀的錯誤，這也是我們MS11-054發現的過程，也是我們團隊發現的一個漏洞，這個漏洞也已經提交給微軟了。
第二種方法也比較簡單，基于這樣的假設，也就是假設我們給廠商給自己產品打補丁時，打的補丁存在一些安全隱患，或者打的不完備，因為軟件廠商發現發現自己的產品出來漏洞之后一定希望用最小的代價去修復當前這個漏洞，所以，它一般比較注重當前漏洞點的修補，而很少考慮漏洞上下文的環境，尤其Windows這種大型邏輯上它是很嚴謹的，但對很多的邏輯條件在別的地方可能也存在相應的改變，也就是它不能考慮到整個系統或者第三方代碼會給我們變量和邏輯條件帶來影響，這樣我們可以形成了參考，安全補丁比對邏輯挖掘的思路。這種技術我們在清華大學學報上面已經形成論文，大家可以去下載。其實思路是很簡單的，也就是說我們可以通過路徑查找能夠找出來所有可能能夠執行的路徑。
進一步對這個邏輯條件進行相應判斷或者進行約束，最后進行求解，能不能夠找到繞過這個邏輯條件去執行到漏洞點的路徑，如果能找到的話，就意味者這個漏洞修補可能是不完全的。
這里有個典型的漏洞，這個漏洞應該說是已經公開的。漏洞之前和之后實際在前面就是加了一個邏輯條件和框段，同時Windows系統和其他開發者在其他地方又有這個地方進行了修改，如果我們采用某一種方法，能夠把它的條件先進行重置，這種情況我們就可以把以前的漏洞進行重現。
舉例，MS10-010，是我們團隊成員在分析MS10-011這個漏洞和補丁分析出來的一個漏洞，當時這個漏洞的D點和P點實際是在不同的函數里，也就是說實際增加了運行到漏洞點的邏輯條件，但這個邏輯條件它是可以通過普通用戶構筑一些特定函數后來進行修改的，既然我們自己也有編程的基礎，代碼方面的技術，自己可以通過編程直接改變這個條件，從而觸發原來的一個漏洞，所以這很巧一個是MS10-011，一個是MS10-010，實際他們是一樣的漏洞，是屬于客戶端子系統的漏洞。
第三種方法，系統內核函數的無序調用，這里面不僅僅是內核函數，也可以API函數，Win7、Win8出現之后，系統漏洞的確很難繼續挖掘，我們需要改變一些新的思路進行漏洞挖掘，這種方法實際是很好的能夠去挖掘本地學習提升漏洞的方法，它可以面向Windows的內核模塊，也可以面向一些驅動程序進行漏洞挖掘。
它的思路很簡單，一個普通用戶能夠驅動打印機，就意味著一個普通用戶能夠調用打印機驅動里面的函數，既然普通用戶能夠驅動我們驅動里的函數，完全可以通過自己的代碼編程把這些函數剝離出來，剝離出來的目的是什么呢？就是為了進行無序的調用，所以，我們可以有正常的順序序列，也可以有打亂順序的調用，譬如順序里的函數經過多次調用之后看看在內存里是不是會打架。
也可以對調用的順序看能不能改變，或者調用一些條件或參數，或者沒有公開過的API函數。這也是MS10-010的特點，它是客戶端子系統的漏洞，在微軟里它應該屬于重要級的漏洞。MS10-010，也就是客戶端子系統主要是完成這樣的功能，它可以讓用戶登錄進來之后開啟的每一個進程可以在SDRSD里留下一個PLD，就是進程列表。我們有個方法可以讓用戶退出操作系統，他曾經開啟過的進程依然留在這個系統里，這應該是存在安全隱患的，這和操作系統設計原則是違背的。
這種方式我們怎么樣讓它重現呢？就是打亂它的調用數據，這里列出的一段代碼，我們可以改變它的邏輯條件，繞過它的安全補丁。我們怎么做呢？這里面每一步都可以通過安全函數實現。正常情況下會先連接ApiPort–退出–關閉，我們的標志就結束了。如果打亂這個順序的調用，先連接，接著關閉，最后調用退出函數，這樣它就會寄存器里變成0，進程卻依然留在系統里。
基于協議握手的漏洞管理技術，這也沒有什么太多的新意，主要是針對一些網絡軟件，這個測試空間是很大的。尤其是針對網絡的應用軟件，原來我們在進行Fuzzing測試時比較關注的是它的第一步，現在我們可以關注到它的第二步或第三步，我們首先可以把它整個網絡通信流程模擬出來，再結合我們的立項工程，立項主要用在C端（Server端），也就是說我們去解析傳遞過去的數據包最后在Client端或Server端是怎么解析的，我們能夠去定制更加自動化的Fuzzing測試用例，從而縮小我們測試用例的空間。
這是個典型的例子，我們往往關注的是第一步，實際往往很我多漏洞會出現在第二步或第三步，在連接創建之后或者用戶已經登陸進去之后，后續數據包的傳遞可能會導致出來一些安全漏洞，最近我們團隊也在研究URL的漏洞，主要是針對瀏覽器和Flash的一些對象，比如SWF。一提到UAF可能大家都知道，就是User After Free。（PPT）這張圖上應該展現的就是比較通用的漏洞模型，也就是說我們在解析HTML時，HTML里可以通過Create Edident去創建我們的對象，同時通過JS完成事件的回調，事件回調中可以銷毀對象或者對對象屬性進行修改，修改完了之后我們后面還會有繼續的引用，這樣就會導致UAF的漏洞。
業界也有很多Fuzz的工具，比如Grade（音）也是用開源的工具，這些工具有相應的特點，比如針對節點的，針對JS的，還有跨瀏覽器的，比如CloseFuzz針對IE、Chrome或者火狐。一般UAF漏洞，第一步，既然我們做Fuzz工具應該怎么做？首先是創建我們的對象，第二步是修改創建對象的屬性或者進行釋放，最后在別的地方再進行引用，同時我們需要有一個能夠監控到瀏覽器運行狀態的工具，進行Fuzzing時完全可以打開創建瀏覽器為子線程調試的參數，這樣我們可以捕獲到當前瀏覽器運行的一些異常信息，最后來進行判斷。
如果我們要實現一個瀏覽器的Fuzzing工具有很多資料可以進行參考，典型的是有W3C的官方文檔，文檔里面給我們提供了大量關鍵字，可以構造出我們的字節，告訴我們dom樹的一些結構。
W3C也提供了針對瀏覽器基本功能的測試用例，它其實有很多測試樣本，這些測試樣本對于我們寫瀏覽器Fuzzing測試工具是很有幫助的，我們可以對它進行修改和定制。還有一些方法，例如可以利用跨引擎，大家知道，IE瀏覽器發展到今天有很多的版本，在IE8之前的都是通過JScript.dll來進行解析的，IE9或IE9以上的版本都是通過JS和Jscript9.dll版本解析的。
這樣我們可以用早期JScript.dll來構建我們的dom樹，用新版本來進行解析，也就是說我們利用他們構建方式和解析形式上的差異，看能不能夠發現相應的一些漏洞。為dom樹節點添加事件的回調。還有一種方法，我們也可以充分地利用一個對象，這個對象也是dom樹里可能會有的一個對象，像elementRange，這個對象可以存儲dom樹當前需要Fuzz的節點和應用，在別的地方處理完之后最后再通過對象查詢它引用變化的情況，對于回調函數的構造可能有一定的技巧，需要我們能夠有效地打亂dom的關系樹，并且它構造的方法可能會直接影響到我們Fuzzing工具的一些效率。
最后的方法是針對Flash對象UAF的挖掘，SWF工具里S3為了提高SWF處理效率，有個新的線程跟蹤機制，存在主線程和工作線程。這里有共享內存的特性，如果主線程和工作線程根據共享對象的處理出現一些不同步的現象就有可能出現UAF的漏洞，最近有一些案例，1月份出現2015的0311和0333，這兩個都是因為ByteArray這個對象的一些問題，也就是我們把ByteArray設成并享之后出現的問題。
第一個漏洞，如果說An Cooperis（音）失敗的情況下有可能會造成主線程里對它錯誤的引用；第二個是工作線程里直接對ByteArray進行clean清楚時沒有告訴主線程，這時候我們dom memory可能導致一些引用，導致UAF漏洞，這是針對ByteArray對象的根本原因。
m-buffer是指向實際的對象，m-subscriber是個引用的列表，也就是說我們把ByteArray設成共享時再進行復制，它復制了m-buffer的相關內容，忽略了對象引用的信息，當我們對這個新對象進行操作時，就會使得老對象還不知道一些信息，從而在后續引用時造成UAF。
對于Flash對象，我們一般認為，它支持三種線程之間的共享方式，只有最后一種它是以共享內存的形式進行同步的，也就是說第一種和第二種都是直接進行復制，但不引用，只有第三種他們的內存可以進行共享和操作的。通過S3腳本設置共享對象，并對共享對象進行處理，把它取出來使用。這是個操作的過程，也就是說我們把它取出來之后，可以寫入自己的Fuzz程序，Fuzz程序可以對當前這個對象進行Clear，也可以復制成null，也可以把當前屬性修改成位我們想要修改的屬性，后續我們再進行進一步引入來看看它是不是出錯，從而發現UAF的漏洞。
對于回調事件的設置也是很靈活的，也就是說我們可以對這個對象進行很多處理，進行相應組合，最后發現一些漏洞。
今天這個機會很難得，后面還有點時間，我再把北大的小組也簡單介紹一下，我們這個團隊在2008年時就一直存在，主要在做軟件安全方面的研究，我們主要有一個方向：立項工程，漏洞分析，漏洞挖掘，惡意代碼和安全評估。（PPT）這是我們在漏洞方面發現的成果，相比前面大牛們所做的工作，我們做的工作是很少的，我們給微軟提供的是3個漏洞，沒有公開的有3個漏洞。
對應用軟件上發現的漏洞是本地學習提升的漏洞，主要是驅動層面發現的漏洞。
今天的演講就到這里！謝謝大家！