周美秀 ，俞 潔 ，姚國祥

（1.暨南大學(xué) 信息科學(xué)技術(shù)學(xué)院，廣東 廣州510632；2.暨南大學(xué) 網(wǎng)絡(luò)中心，廣東 廣州510632)

“漏洞”是計算機系統(tǒng)在硬件、軟件、協(xié)議的具體實現(xiàn)或系統(tǒng)安全策略上存在的安全方面的缺陷。漏洞一旦被發(fā)現(xiàn),攻擊者就可使用這個漏洞獲得計算機系統(tǒng)的額外權(quán)限,使在未授權(quán)的情況下訪問或破壞系統(tǒng)[1]。Web控件漏洞數(shù)量在近幾年呈現(xiàn)迅速增長的趨勢，根據(jù)著名的軟件安全公司賽門鐵克關(guān)于Web控件安全漏洞的統(tǒng)計：2007年至2009年的檢測Web漏洞呈幾何數(shù)量級增長[2]。針對日益增多的ActiveX控件漏洞，一方面操作系統(tǒng)安全工程師被動地研究新的防御機制，另一方面許多軟件安全研究人員主動地探究ActiveX控件漏洞的發(fā)掘技術(shù)。目前常用的漏洞挖掘技術(shù)主要有Fuzzing技術(shù)、靜態(tài)分析技術(shù)、動態(tài)調(diào)試技術(shù)、補丁比較技術(shù)等[3]。

1 Fuzzing漏洞檢測模型

Fuzzing漏洞測試方法的選擇依賴不同的因素，如目標(biāo)程序、需要測試的數(shù)據(jù)所采用的格式、研究者的技能等，但其步驟相對一致。故此，可以抽象其模型，圖1是Fuzzing漏洞檢測模型示意圖[4]。

首要步驟是構(gòu)造有可能觸發(fā)漏洞的畸形測試數(shù)據(jù)。此模塊完成測試目標(biāo)各種信息收集的功能，收集的這些信息為接下來的進一步測試服務(wù)，對Fuzzing測試能否檢測到漏洞起決定性的作用。新的測試數(shù)據(jù)可以用預(yù)先設(shè)定的值，也可以通過改變已有的測試數(shù)據(jù)來動態(tài)生成。

圖1 Fuzzing漏洞檢測模型示意圖

Fuzzing漏洞檢測模型的核心步驟是Fuzzing測試。一般都可設(shè)置測試模式，即指定該次測試用的是組合字段測試、等價類測試、邊界值測試等模式。也可以在后續(xù)異常分析時進行數(shù)據(jù)構(gòu)造方式以及測試模式的調(diào)整，從而使測試過程更加高效。

異常監(jiān)視也是Fuzzing測試中較為重要的步驟。異常監(jiān)視可以使我們確切知道測試數(shù)據(jù)包或者文檔在送往Fuzzing系統(tǒng)測試的過程中，哪些數(shù)據(jù)包和文檔觸發(fā)了系統(tǒng)異常。再者，異常監(jiān)視可以記錄下異常情況下的一些重要信息，如寄存器狀態(tài)、CPU狀態(tài)以及堆棧狀態(tài)等，以供下一步的異常分析做參考。

異常分析的任務(wù)是確定該次異常是否有可利用性以及是否是漏洞。因為觸發(fā)系統(tǒng)異常的原因繁多，不只是軟件漏洞，軟件的bug也可能導(dǎo)致系統(tǒng)崩潰。異常分析幾乎是現(xiàn)階段每一套Fuzzing系統(tǒng)的弱點，因為其涉及的人工分析工作太多，所以這一環(huán)節(jié)很難引入自動化機制。

2 傳統(tǒng)的Web控件漏洞檢測模型

傳統(tǒng)模型主要由測試前準(zhǔn)備、測試階段、測試后報告三個階段組成。測試前準(zhǔn)備階段包括分析Web控件屬性、分析函數(shù)及其參數(shù)、生成測試數(shù)據(jù)等；測試階段主要包括模擬用戶打開測試實例、動態(tài)異常監(jiān)測和異常記錄。圖2所示為傳統(tǒng)的ActiveX控件漏洞檢測模型。

圖2 傳統(tǒng)的ActiveX控件漏洞檢測模型

2.1 測試前準(zhǔn)備階段

首先，確定目標(biāo)Web ActiveX控件，即找出Web控件的CLSID。在注冊表相應(yīng)的表項信息中根據(jù)控件的CLSID，確認(rèn)其是否實現(xiàn) IObjectSafety安全接口、是否是腳本安全、是否被設(shè)置了killbit位，只有在確認(rèn)控件實現(xiàn)了IObjectSafety安全接口、腳本安全、沒有被設(shè)置Kill-Bit位的情況下，才繼續(xù)后續(xù)的步驟。

最后，還要分析出ActivieX控件的屬性列表、函數(shù)列表以及函數(shù)參數(shù)列表，只有明確這些列表之后，才能根據(jù)不同的漏洞有針對性地構(gòu)造Fuzzing測試數(shù)據(jù)。這也是Web ActiveX控件Fuzzing漏洞測試的特殊性之一。

2.2 測試階段

在測試階段，將每個測試實例送往目標(biāo)程序進行測試。在Web控件的漏洞檢測過程中，測試實例往往以htm、html、wsf、PDF等文檔格式存在，將所有的測試文檔打開，使其可以用程序模擬用戶手工點擊實現(xiàn)。

打開測試文檔后，IE彈出對話框提示是否加載相應(yīng)的Web控件。Web控件加載、Web控件初始化、測試實例調(diào)用控件方法等過程，都可能出現(xiàn)異常，可以利用Windows提供的調(diào)試接口和Windows的結(jié)構(gòu)化異常處理機制SEH，將Fuzzing工具作為調(diào)試器附加在IE瀏覽器之上，這樣便可以接收、處理、記錄IE的各種調(diào)試、異常事件。當(dāng)異常出現(xiàn)時，Windows系統(tǒng)總會彈出錯誤提示窗口，一個較為完善的Fuzzing測試工具，必須能夠模擬用戶點擊關(guān)閉提示窗口，該功能可以用Windows提供的HOOK技術(shù)實現(xiàn)，在以后的研究中將更為詳細地分析和解決這個問題。

2.3 測試報告階段

在捕獲并保存服務(wù)器進程內(nèi)部的異常之后,原型系統(tǒng)將對異常信息進行自動分析,從而智能地給出異常分析報告。該模型系統(tǒng)所實現(xiàn)的異常自動分析算法能夠有效地分析出導(dǎo)致異常命令、異常類型以及異常風(fēng)險程度等。根據(jù)該算法生成的異常分析報告在一定程度上能減少漏洞分析人員的后期分析工作,縮短漏洞分析時間,從而提高漏洞發(fā)掘的效率。

2.4 傳統(tǒng)Web控件漏洞檢測模型的不足

傳統(tǒng)模型存在以下幾方面不足：(1)若ActiveX控件的可調(diào)用方法列表較長，這對于Fuzzing漏洞測試的工作量將大大增加，包括測試樣本數(shù)據(jù)的數(shù)量增加和測試過程的時間增加。本文應(yīng)用代碼掃描分析技術(shù)解決這個問題，有效地減少了測試的工作量。(2)生成測試數(shù)據(jù)的隨機性。對此，本文采用啟發(fā)式生成測試數(shù)據(jù)的方式來解決，提高了漏洞發(fā)掘效率和自動化程度。(3)測試方法較為單一，動態(tài)分析可在代碼執(zhí)行過程中查看代碼，善于發(fā)現(xiàn)運行時錯誤；而靜態(tài)分析通過算法檢查代碼的錯誤。傳統(tǒng)的模型比較著重靜態(tài)分析，很難發(fā)現(xiàn)復(fù)雜交互中產(chǎn)生的缺陷，本文采用靜態(tài)分析和動態(tài)分析結(jié)合的方式。

3 Web控件漏洞檢測模型的改進

針對Web控件漏洞檢測模型的不足，本文采用一種融合代碼掃描和Fuzzing測試的改進模型，采用靜態(tài)分析和動態(tài)分析相結(jié)合的方法，如圖3所示。改進后的模型增加了代碼掃描分析模塊、啟發(fā)式生成測試數(shù)據(jù)模塊、OllyDbg分析測試模塊等模塊。

圖3 Web控件漏洞檢測改進模型

3.1 代碼掃描分析模塊

本模塊的目的是減小測試函數(shù)列表。模塊搜索函數(shù)地址空間中的“目標(biāo)字”，為測試數(shù)據(jù)的構(gòu)造提供支持。另外，用IDA等反匯編工具對目標(biāo)程序的二進制文件進行反匯編，若文件掃描到運用了不安全方法，則將此控件函數(shù)標(biāo)記為待測試函數(shù)。

3.2 啟發(fā)式生成測試數(shù)據(jù)模塊

借鑒人工智能中的遺傳變異和啟發(fā)式算法來生成測試數(shù)據(jù),使測試數(shù)據(jù)更具針對性，從而提高漏洞發(fā)掘效率和自動化程度。

3.3 OLLYDBG分析測試結(jié)果模塊

利用Fuzzing進行漏洞發(fā)掘時,漏洞發(fā)掘人員往往需要第三方調(diào)試器配合才能有效地發(fā)掘軟件漏洞。本模型系統(tǒng)采用OLLYDBG對服務(wù)器進程進行全程監(jiān)控。OLLYDBG是一個新的動態(tài)追蹤工具，它將IDA與SoftICE相結(jié)合，成為目前最強大的調(diào)試工具。

4 測試結(jié)果及分析

為了驗證本文提出的Web控件漏洞Fuzzing測試模型的可行性和有效性，選擇用戶量較大的“暴風(fēng)影音”播放器進行測試（主要針對其mps.dll控件進行測試）。測試環(huán)境如下：Windows系統(tǒng)的 Internet Explore：V7.0，測試對象：暴風(fēng)影音（Stormplayer）V3.11。

4.1 枚舉ActiveX控件屬性、方法及方法參數(shù)

安裝“暴風(fēng)影音 V3.11”，然后用改進的 Fuzzing測試模型針對暴風(fēng)影音的mps.dll控件進行測試，枚舉ActiveX控件的屬性、方法和方法參數(shù)。

4.2 構(gòu)造測試文檔

本文的Fuzzing測試模型，在枚舉出來的屬性和方法的參數(shù)列表中，右擊任意一個屬性或方法，便可生成對應(yīng)的測試數(shù)據(jù)。模型以VB腳本文檔形式生成測試文檔，便于wscript.exe的直接調(diào)用。下面代碼是暴風(fēng)影音mps.dll控件的導(dǎo)出函數(shù)OnBeforeVideoDownload()的Fuzzing測試文檔之一。

4.3 漏洞測試及結(jié)果分析

構(gòu)造了一系列的測試文檔之后，下面要進行漏洞測試。當(dāng)ActiveX控件的屬性或方法較多時，耗時較長。于是Fuzzing測試自動化的好處便得到體現(xiàn)。因為能夠處理好交互性問題，所以漏洞測試過程便可做到無人值守[5]。本文的Fuzzing測試模型便能妥善處理好交互性問題。

4.3.1異常列表

對Web ActiveX控件的某一屬性或者方法進行Fuzzing測試，用列表的方式呈現(xiàn)其結(jié)果，從該表中便可以方便地獲知導(dǎo)致異常發(fā)生的具體測試文檔、異常發(fā)生的數(shù)目等信息。圖4是暴風(fēng)影音mps.dll控件的導(dǎo)出函數(shù)OnBeforeVideoDownload()Fuzzing測試的異常列表。

4.3.2 異常詳細報告

對異常列表中的每一項可以查看其詳細報告。利用論文提出的Fuzzing測試模型對暴風(fēng)影音mps.dll控件的導(dǎo)出函數(shù)OnBeforeVideoDownload()進行Fuzzing測試得到測試結(jié)果異常報告。圖5是其中的一項詳細報告。從中可以方便地獲知異常發(fā)生的情況下的各種重要信息，包括異常類型、當(dāng)前線程狀態(tài)、當(dāng)前SEH鏈表的狀態(tài)、當(dāng)前堆棧內(nèi)存狀態(tài)、當(dāng)前各重要寄存器內(nèi)容以及當(dāng)前EIP附近的指令等。

從這份詳細報告中可以看到EIP寄存器的值為“41414141”,這是構(gòu)造測試文檔時所采用的經(jīng)典長字符串“AAAA”的十六進制碼。充分說明了若攻擊者加入設(shè)計的輸入?yún)?shù)，EIP可以被劫持，從而可以引導(dǎo)系統(tǒng)去執(zhí)行攻擊者設(shè)計的特殊代碼。因此可以確定mps.dll控件的導(dǎo)出函數(shù)OnBeforeVideoDownload()確實存在著漏洞。有經(jīng)驗的測試者還可以根據(jù)異常報告中崩潰地址、崩潰時的?？臻g狀態(tài)和崩潰時的棧空間狀態(tài)指令狀態(tài)等信息，進一步分析出mps.dll控件漏洞出現(xiàn)的具體位置。

由于Web ActiveX控件具有特殊性、變化快等特點，Web應(yīng)用的安全檢測變得十分困難，而Web安全防范日益重要。本文針對Web的安全漏洞檢測的模型和算法做了一些探討，所提出的方案在解決當(dāng)前Web ActiveX控件漏洞檢測問題上有所突破。未來，將進一步考慮增強測試數(shù)據(jù)的針對性，從而提高測試數(shù)據(jù)觸發(fā)漏洞的比率；搜索ActiveX各導(dǎo)出函數(shù)地址空間中的 “特征字”，搜索調(diào)用非安全方法的ActiveX導(dǎo)出函數(shù)的具體實現(xiàn)方法[6]。

[1]王雨晨.系統(tǒng)漏洞原理與常見攻擊方法[J].計算機工程與應(yīng)用，2001，38(8)：62-64.

[2]SUTTON M，GREENE A，AMINI P.Fuzzing：brute vulnerability discovery(1st ed)[M].Pearson Education，2007.

[3]邵林，張小松，蘇恩標(biāo).一種基于Fuzzing技術(shù)的漏洞發(fā)掘新思路[J].計算機應(yīng)用研究，2009，26(3)：1086-1088.

[4]吳毓書，周安民，吳少華.基于 Fuzzing的ActiveX控件漏洞發(fā)掘技術(shù)[J].計算機應(yīng)用，2008，28(9)：2252-2254.

[5]張美超，曾凡平，黃奕.基于漏洞庫的fuzzing測試技術(shù)[J].小型微型計算機系統(tǒng)，2011，4(4)：651-655.

[6]高峻，徐志大，李健.漏洞自動挖掘技術(shù)研究進展[J].計算機與數(shù)字工程，2009，37(1)：100-105.