《模糊測試--強制發掘安全漏洞的利器》閱讀筆記(一)
第一部分
本部分的主要目標是介紹開發“全功能”對模糊測試器所需要的基本思想。本部分的這些概念能讓人更好的使用模糊測試技術。
重要知識點
-
白盒測試不見得比黑盒測試效率更高,因為編譯器在將源代碼編譯成匯編代碼時引入了巨大改變:例如微軟源代碼泄漏事件
-
黑盒測試適用於安全漏洞由單組輸入引發的情況。需要多組輸入時,基本只能通過手工的代碼審評或是逆向代碼工程(RCE)來發現
-
在學術界,與模糊測試最接近的術語是邊界值分析(Boundary value analysis,BVA)
-
本書中,對模糊測試的定義:
“通過向應用提供非預期的輸入並監控輸出中的異常來發現軟件中的faults的方法。”
-
確定輸入向量:原則是從客戶端目標應用發送的任何東西,包括頭,文件名,環境變量,注冊表鍵,以及其他信息,都應該被看作輸入向量
-
Web瀏覽器模糊測試器通常利用HTML的功能來自動化模糊測試過程,如檢查CSS,COM,ActiveX
-
協議是達成通信的必要條件。
-
協議設計的三種典型法方法:定長字段,變長字段和分割字段
-
需要能夠系統地回放整個測試過程,才能做進一步的分析和發現奔潰的具體原因
普通知識點
白盒測試
- 源代碼分析工具分三類:
- 編譯時檢查工具:VC++的/analyze選項
- 源代碼瀏覽工具
- 自動源代碼審計工具
黑盒測試
- 手工測試:掃除(Sweeping)
灰盒測試
- 二進制審計:在匯編級別的審計,使用的工具包括:
- 反匯編器:IDA
- 反編譯器:Boomerang,IDA的F5插件
- 調試器:WinDbg,OllyDbg,GDB
- 自動化的二進制審計
| 工具名稱 | 提供商 | 授權 | 注釋 |
|---|---|---|---|
| LogiScan | LogicLibrary | 商業 | 集成到Logidex DSA |
| BugScan | Halvar Flake | 自由 | IDC腳本,枚舉所有函數調用,發現不安全的庫函數 |
| Inspector | HB Gary | 商業 | 整合如IDA和OllyDbg等的輸出 |
| SecurityReview | Veracode | 商業 | 不關心 |
| BinAudit | SABRE Security | 商業 | IDA插件,發現數組越界訪問,重復內存釋放等 |
模糊測試器
- 基於變異的模糊測試器
- 基於生成的模糊測試器
模糊測試階段
- 確定測試目標
- 確定輸入向量:是否能找到所有的輸入向量是模糊測試能否成功的關鍵。
- 生成模糊測試數據
- 執行模糊測試數據
- 監視異常:一定要對異常和錯誤有監視,否則不知道是什么數據觸發faults,則這次模糊測試就沒有意義
- 判定發現的漏洞是否可能被利用:這種過程是典型的手工過程,需要操作者具有特定的安全知識。
模糊測試的局限性
- 訪問控制漏洞:模糊測試無法識別應用程序本身的權限問題
- 糟糕的設計邏輯:模糊測試無法識別發現的問題是否是由於安全問題造成的
- 后門:模糊測試無法識別是否是后門功能
- 破壞:SIGSEGV信號會導致模糊測試無法識別是否出發內存破壞
- 多階段安全漏洞:模糊測試對識別單個漏洞很有用,但對小的漏洞鏈構成的漏洞則作用不大
模糊測試方法分類
-
預生成測試用例:
需要理解對象規約支持的數據結構和可接受的范圍,然后對應生成測試邊界條件或事違反規約的測試用例。(生成測試用例很費神,但可復用。用完用例,則測試結束) -
隨機生成輸入:
效率最低,但可快速識別目標是否有非常糟糕的代碼。例如:while[1]; do cat /dev/urandom | nc -vv target port; done該命令從Linux urandom設備讀取一個隨機數,然后將該隨機數發送給指定的目標地址和端口
使用這種方法,需要分析棧,在調用棧又可能被破壞的情況下,分析調用過程尤其痛苦。
-
手工協議變異測試:
比隨機生成更加初級。優點是可充分發揮自己過去的經驗和“直覺”。常用於Web應用安全測試。 -
變異或強制性測試:
模糊器從一個有效的協議樣本或是數據格式樣本開始,持續不斷的打亂書包或是文件中的每一個字節,字,雙字,或是字符串。
雖然該方法浪費了CPU資源,但是不需要對應用進行研究,並且整個模糊測試過程可以完全自動化。
-
自動協議生成測試:
需要先對應用進行研究,理解和解釋協議規約或文件定義。但是,這種方法並不基於協議規約或文件定義創建硬編碼的測試用例,而是創建一個描述協議規約如何工作的文法。
例如SPIKE和SPIKEfile工具都是這類測試的典型例子,采用SPIKE腳本描述協議或是文件格式,並使用一個模糊測試引擎來創建輸入數據。
模糊測試器類型
- 本地模糊器
- 命令行模糊測試器:從命令行中傳入參數,例如使用clfuzz工具,iFUZZ工具
- 環境變量模糊測試器:從環境變量中傳入參數,例如使用Sharefuzz工具,iFUZZ工具
- 文件格式模糊測試器:文件格式模糊測試器動態創建半形式化文件,然后使用目標處理這些文件,例如使用FileFuzz工具,notSPIKEfile和SPIKEfile工具,PAIMEIfilefuzz工具
- 遠程模糊測試器
- 網絡協議模糊測試器
- 簡單協議:僅有簡單認證或是沒有認證,並且基於ASCII字符而不是二進制數據,不包含長度或是校驗域,如FTP
- 復雜協議:認證可能需要通過加密或是某種形式的混淆來實現,並且通常由二進制數據和部分可讀的ASCII字符串構成。例如MSRPC(微軟原創過程調用)
- Web應用模糊測試器:主要尋找SQL注入,跨站腳本攻擊(XSS)。例如使用WebScarab工具,SPI Fuzzer工具,Codenomicon HTTP測試工具
- Web瀏覽器模糊測試器:只是文件格式模糊測試器中特殊的一類。例如使用mangleme工具,DOM-Hanoi工具,Hamachi工具,CSSDIE工具,COM Raider工具
- 網絡協議模糊測試器
- 內存模糊測試器:一種實現方法是對進程執行一次快照,在生成快照后迅速向該進程的輸入處理子例程中注入故障數據。(優缺點見書P37)
- 模糊測試框架:通常包括一個庫用來生成模糊測試字符串,一套簡化的網絡和磁盤輸入輸出子例程,一些類似腳本的語言。(優缺點見書P38)
協議
-
協議是一些規范,協議形成了數據傳輸和處理的基礎結構,協議中的各部分稱為字段。
-
協議的主要總用就是定義“協議中各部分數據如何被解釋”。
-
簡單文本協議:用於通信的數據值都在可打印字符范圍內。如FTP
-
二進制協議:需要理解協議的結構。例如AIM的認證和登陸過程。
wotsit.org收錄了上百種專有和公開協議的文檔描述。
-
網絡協議:分專有和公開協議。例如FTP,AIM,routing,e-mail,streaming media
- 專有:公司中的封閉小組開發和維護
- 公開:生成RFC文檔
-
文件格式:用來描述文件的數據結構。例如office文檔
-
常用協議元素:
- 名字-值對:一般規則是,通過對名字-值對中的“值”的部分進行模糊測試,通常可以發現潛在的安全漏洞。
- 塊識別符:用來標識二進制數據塊的數據類型。
- 塊大小:一種模糊測試的方法是修改表示塊大小的值,使其比實際數據塊的數據大小稍大或稍小一些,然后觀察結果輸出。緩沖區溢出和緩沖區下溢就是通過這種方式發現的。
- 校驗和:模糊測試器需要重新計算校驗和並寫入文件,保證被測應用能夠正常處理用於模糊測試的文件。例如PNG圖像格式就使用了校驗和。
有效模糊測試的需求
對測試的可重現性和可復用性的計划應該在開發模糊測試器之前就進行考慮。
- 可重現性與文檔:能夠重現耽擱測試和一組測試的測試結果,是基本需求。
- 可重用性:需要事先考慮到“可重用的部分”,然后再做對應開發。
- 過程狀態和過程深度:當前狀態相對於初始狀態的距離稱為過程深度。例如SSH,客戶端首先處於初始狀態,認證過程中服務器處於認證狀態,認證成功之后即處於已認證狀態。
- 跟蹤、代碼覆蓋和度量:代碼覆蓋是指模糊測試器能夠讓被測應用達到和執行的過程狀態的數量。
- 錯誤檢測:產生和傳輸可能引發異常的數據占模糊測試的一半,另一半是精確的識別出一個已經出現的錯誤。例如1.在兩次請求之間插入"ping"或者做“存活檢查”來做區分。2.利用日志輸出做檢查,如windows事件瀏覽器
- 資源約束:預算和時間期限等,都會給模糊測試帶來限制。在設計方案時,要考慮這些問題。
