一種基于Python符號執(zhí)行的自動化網絡攻擊流量獲取方法

陳家浩 王軼駿 呂 誠

(上海交通大學網絡空間安全學院 上海 200240)

0 引 言

隨著全球網絡服務爆發(fā)式的增長，網絡安全問題也隨之而來。大量的網絡攻擊腳本在網上傳播使用，對網絡健康生態(tài)造成了極大的威脅。而在針對網絡攻擊的檢測與防御中，網絡流量樣本是非常重要的研究對象和判斷依據。因此對各種網絡攻擊腳本所能產生的攻擊流量的采集工作就非常重要。

想要采集這些攻擊流量主要有4種方法：(1)使用真實的攻擊代碼對測試靶機進行攻擊，攻擊流量直接由運行的攻擊代碼生成;(2)對各類攻擊行為的特征進行整理和建模，提取關鍵信息，構造攻擊流量;(3)從真實的網絡安全事件分析與審計中獲得攻擊流量;(4)采用符號執(zhí)行技術，對攻擊腳本進行分析，提取其釋放的攻擊流量。

第1種方法通過直接運行攻擊腳本的方式來產生攻擊流量。這種方法雖然可以得到最真實的攻擊流量，但存在明顯的缺點：首先，不同攻擊代碼所使用的編程語言和運行平臺各不相同，難以設計一套測試系統能夠運行所有攻擊代碼，并釋放攻擊流量，這對研究人員需具備的硬件設施條件和個人能力有很高的要求；其次，一次成功的攻擊不僅僅依賴于攻擊方，對目標也有很多的要求，為了提取在各種場景下的攻擊流量，需要模擬各種情況搭建多個滿足要求的靶機環(huán)境，網絡設備與網絡服務種類繁多，應用場景復雜多變，搭建靶機環(huán)境的人力和物力成本非常大；再者，運行攻擊代碼將會對實驗系統和實驗設備造成難以控制的破壞，甚至可能留下后門、木馬等長久性威脅。

第2種方法通過對各類攻擊行為對特征進行整理和建模。這種方法需要通過各種途徑采集攻擊流量，才能對這些流量加以分析，提取有效數據，根據模型生成仿真的攻擊流量。這個方法的缺點在于：首先，在不搭建靶機的情況下對攻擊流量的采集比較困難，很難對各類攻擊的流量進行完整采集；其次，這種方法生成的仿真攻擊流量的可靠性取決于模型的準確性，為了模擬真實攻擊流量，需要在數據包順序、流量分布特征等多方面進行模擬，要想逼真地模仿在各種場景下的各類攻擊流量難度很大。

第3種方法通過從真實的網絡安全事件中獲取攻擊流量。這種方法不適合進行大規(guī)模的采集工作。因為并不是網絡安全事件的被攻擊方都愿意向研究者提供攻擊事件相關的信息，有的網絡安全攻擊事件還會被受害方主動隱藏。并且這方法也看運氣，很難在一段時間內發(fā)生種類全面的網絡安全事件。

第4種方法使用符號執(zhí)行技術對攻擊腳本進行靜態(tài)分析。這種方法也存在一定的缺點，受限于攻擊腳本使用的編程語言，針對用不同編程語言編寫的攻擊腳本需要分別實現其符號執(zhí)行引擎。該方法帶來的優(yōu)勢就比較明顯，由于是靜態(tài)分析，無需搭建大量靶機環(huán)境，也無需采集各類攻擊流量，符號執(zhí)行技術會遍歷攻擊腳本的幾乎所有分支，生成各種情況下完整的攻擊流量，而且可以實現自動化執(zhí)行，方便高效，極大地節(jié)約了人力物力成本。同時本文還發(fā)現目前很大一部分網絡攻擊腳本都使用Python語言作為腳本語言。

本文研究了一種對現有網絡攻擊腳本使用符號執(zhí)行的攻擊流量提取方案，通過該方案可以高效提取所需的攻擊流量。本文也會進一步對其實際效果進行分析。

1 相關研究

符號執(zhí)行最初提出是在20世紀70年代中期，主要描述的是靜態(tài)復合執(zhí)行的原理，到了2005年左右由于引入了一些新的技術讓符號執(zhí)行更加實用，因而開始逐步流行。Concolic執(zhí)行的提出讓符號執(zhí)行真正成為可實用的程序分析技術，其在對桌面應用程序的測試中被廣泛研究。它能以最少的測試用例達到最高測試覆蓋率的特點受到廣大測試研究人員的青睞，進而大量用于軟件測試、逆向工程等領域。

在2005年左右涌現出很多此方面的研究成果，Berkeley 大學提出的Kudzu Javascript 符號執(zhí)行平臺，用于檢測 Javascript中的注入漏洞；MIT提出用于檢測HTML運行時錯誤的符號執(zhí)行工具 Apollo; UC Santa Barbara 和他們的CTF團隊Shellphish提出的angr二進制符號執(zhí)行平臺等。

目前符號執(zhí)行引擎主要分為三類：第一類用來分析x86二進制機器碼，例如 UC Santa Barbara 和他們的CTF團隊Shellphish提出的angr等；第二類用來分析基于LLVM項目的中間代碼，如2008年Cristian Cadar開發(fā)的KLEE等；第三類為專用符號執(zhí)行引擎，這些引擎往往針對特定的編程語言，如Berkeley 大學提出的Kudzu和MIT提出的Apollo。有些通用的符號執(zhí)行引擎雖然擴展性好，可以支持多種編程語言，但執(zhí)行效率偏低；專用引擎雖然其限制較多，但是執(zhí)行效率高、實用性強。

此外，符號執(zhí)行技術的發(fā)展是依賴于求解器技術的發(fā)展的。求解器作為符號執(zhí)行技術的關鍵一環(huán)，只有能夠求解復雜的路徑約束問題才能使符號執(zhí)行技術真正有實用價值。而近年來許多求解能力出眾的求解器逐漸出現，其中以2015年微軟開源的Z3求解器最為著名。該求解器不但在求解能力上克服了多種原本業(yè)內無法解決的非線性問題，還支持大量的編程語言API。

目前支持Python的符號執(zhí)行引擎有PyExZ3、CHEF。PyExZ3是專門針對Python的符號執(zhí)行引擎，使用z3 SMT求解器，現在只支持對整數類型的符號執(zhí)行，局限性較大；CHEF基于S2E引擎，由此衍生出來的符號執(zhí)行引擎，CHEF引擎作為通用性平臺，具有擴展性好、兼容性強的特點，但所付出的代價就是執(zhí)行效率的低下。

從目前國內外的相關研究來看，基于Python語言的符號執(zhí)行引擎存在局限性較大，缺乏實用價值，或者平臺體積龐大，執(zhí)行效率低下。因此本文介紹一套經過改進的以Python的符號執(zhí)行引擎為核心的方案，可以用于對攻擊流量的提取。

2 腳本預處理

本文在研究過程中發(fā)現，使用符號執(zhí)行技術進行自動流量采集工作的方案并不是僅僅依靠符號執(zhí)行技術就能實現的。網絡上流傳的Python攻擊腳本形式參差不齊，需要合理統一的預處理流程把它們的結構統一到一個合理的標準上才能使得之后的符號執(zhí)行過程穩(wěn)定運行。因此本文的方案設計如圖1所示。本節(jié)介紹的預處理部分的流程如圖2所示。

圖1 方案總體結構設計圖

圖2 腳本預處理流程圖

2.1 變量添加

網絡攻擊腳本通常都會與目標設備進行大量業(yè)務邏輯的交互。原因主要有：

(1) 不同種類的網站服務之間業(yè)務差距巨大，交互方式的差異甚至遠遠超過兩臺不同品牌不同系統的電腦，并且能同時攻擊兩種不同的網絡設備的漏洞少之又少。因此，針對網絡服務的攻擊腳本一開始需要檢查目標網絡設備的型號，通過向其交互后獲得的反饋數據進行判斷。

(2) 設備的固件版本與該設備存在的漏洞情況關系非常大，因此攻擊腳本一開始需要對目標網絡服務的版本進行檢查，根據目標設備的返回數據來判斷出目標設備是否存在漏洞。

(3) 由于大部分網絡服務的漏洞存在于業(yè)務邏輯交互中，因此讓漏洞點暴露出來需要一定的業(yè)務交互鋪墊。這其中會涉及到在函數體內部使用變量保存反饋數據內容，再根據這些內容進行判斷，進入分支代碼。

基于以上原因，本階段需要尋找到這些保存著反饋數據的變量，這些變量在后續(xù)的代碼中往往會以字符串的形式進行判斷跳轉。因此需要將這些變量原本的獲取內容進行劫持，使這些外來的數據也加入后續(xù)的符號執(zhí)行。

最初本文進行如下的嘗試：(1) 去除該變量獲取數據的那一行代碼；(2) 在目標函數中添加該變量，使其成為這個函數的一個字符串輸入參數。如圖3所示。

圖3 變量添加示意圖一

這個方法從符號執(zhí)行技術的角度來說完全可行，符號執(zhí)行階段會將該變量作為一個符號變量進行推算，從而遍歷執(zhí)行到受它影響的代碼分支。但是，這個方法對于本文所需的流量采集目的來說是不可行的。因為去除該變量通過網絡交互而獲取數據的代碼后，本次符號執(zhí)行所得的流量中自然就會缺少這行代碼原本應該產生的交互流量。因此，本文采用了新的改進方案，如圖4所示。

圖4 變量添加示意圖二

該方案中依然保留了獲取網絡數據的代碼，但是在其下方立刻補了一條賦值語句。將賦值語句中的右操作數變量作為函數的參數寫入函數參數列表。這樣一來，就依然能夠執(zhí)行這一網絡交互動作產生相應的網絡流量，但是也可以使得符號執(zhí)行對該內容進行后續(xù)的推算。

同時也存在攻擊腳本中沒有主函數，直接使用Python代碼執(zhí)行的情況，此時需要先將這部分代碼包裹入自定義的無參數主函數。

2.2 變量預設

通常網絡攻擊腳本中需要指定目標的IP與端口，有時也需要指定攻擊者的IP與端口。這兩種變量通常不會參與后續(xù)的條件判斷，而是直接在之后的代碼中被使用，因此并不需要參與符號執(zhí)行。

此外，IP地址這種類型的變量雖然通常為一個字符串，但是由于腳本中缺乏對IP地址的判斷約束，導致IP地址變量幾乎不可能被符號執(zhí)行引擎推算成“XXX.XXX.XXX.XXX”的形式。

因此，IP變量與PORT變量并不適合使用符號執(zhí)行進行處理，需要在預處理階段將其預先設定好。設定方案如下：通過匹配 “host”、“ip”、“port”、“parser”等關鍵字來找出腳本中的這些變量。通常它們會以3種形式出現：

(1) 函數參數列表中的參數。

(2) 全局變量。

(3) 需要用戶輸入的parser參數。

第一種情況下，先將這些變量從參數列表中移除，然后在函數一開始就將這些變量設定為指定的IP和PORT值，如圖5所示。

圖5 變量預設示意圖一

第二種情況下，直接將這些全局變量賦值為指定的IP和PORT值，如圖6所示。

圖6 變量預設示意圖二

將這些變量設置為固定值也是為了幫助后續(xù)的流量采集。通過過濾指定IP和PORT的流量包來精準地采集該腳本的流量，去除別的噪聲流量。

第三種情況與以上處理方法類似，直接將目標變量賦值即可。

2.3 腳本重命名

在一個Python語言寫的網絡攻擊腳本中，通常會有許多函數，符號執(zhí)行階段需要對其中某個涵蓋了全部攻擊邏輯的主函數進行符號執(zhí)行。尋找這個函數的任務也應當由預處理階段來完成。

目前采用的方案是：將腳本文件名(不包括拓展名)進行統一編號和重命名。然后將目標主函數的聲明處和調用處也進行重命名，并且主函數重命名后的名稱和腳本文件名(不包括拓展名)保持一致。這樣符號執(zhí)行引擎可以根據文件名來找到該腳本中的主函數。

通常網絡攻擊腳本中的主函數是main()函數、run()、exploit()函數等。本項目中對其處理的策略是exploit()函數優(yōu)先。方案如下：

(1) 將攻擊腳本重命名為“expXXXXXXXXXX.py”的形式。

(2) 尋找是否存在exploit()函數，如果存在，則將該函數重命名為“expXXXXXXXXXX()”的名稱，并相應地修改原本調用exploit()的代碼，然后結束本處理。

(3) 尋找是否存在run()函數，如果存在，則將該函數重命名為“expXXXXXXXXXX()”的名稱，并相應地修改原本調用run()的代碼，然后結束本處理。

(4) 尋找代碼中是否存在指定主函數的“if __name__==‘__main__’”語句，如果存在，則將其中唯一包含的函數重命名為“expXXXXXXXXXX()”的名稱，并相應地修改原本調用該函數(通常為main函數)的代碼。

此方案的效果如圖7-圖8所示。

圖7 腳本重命名示意圖一

圖8 腳本重命名示意圖二

2.4 腳本適配

網絡上可以獲得的用Python寫的網絡攻擊腳本所使用的Python版本是不同的，有的使用Python 2，有的使用Python 3。需要將其統一為Python 3下可運行的腳本。

這一步通過使用Python 3的官方工具2to3即可實現轉換化。轉換過程中如果出現報錯信息需要傳遞給空白數據填寫階段。轉化成功后為了確保該腳本的正確性，需要在Python 3環(huán)境下執(zhí)行一下。如果執(zhí)行失敗需要記錄報錯信息并傳遞給空白數據填寫階段。

本階段與之前的三個預處理階段只處理一次不同，其對于一個攻擊腳本來說可能需要和空白數據填寫操作進行反復循環(huán)，流程如圖9所示。

圖9 腳本適配流程圖

2.5 空白數據填寫

許多網絡攻擊腳本中是需要自定義參數的，例如IP、端口、地址偏移等。有些腳本會有默認的參數使得該腳本在沒有被用戶根據實際情況修改前依然可以正常運行。但依然有相當一部分腳本中沒有默認值而導致腳本無法正常運行起來。

沒有默認值的變量在代碼中的形式通常有如下兩種：

(1) 這些變量的預設值在代碼中是一串字符，用來提示使用者修改這里。如：“offset=YOUR_TARGET_OFFSET”

(2) 預設值是提示符如：“a=*****”。

本文的處理方法是使用“循環(huán)報錯法”。這個方法涉及到腳本適配和空白數據填寫兩個階段的循環(huán)執(zhí)行。通過腳本適配階段的報錯信息來發(fā)現以上的兩種情況：

(1) 當報錯中含有error type 36等信息時，說明是變量賦值時遇到了如“****”的提示符。此時，將產生報錯信息代碼行的右操作數改成合法數值即可。

(2) 當腳本適配的嘗試運行中出現報錯，如果報錯信息是“undefined”相關，則說明是遇到了“offset=YOUR_TARGET_OFFSET”這類賦值。此時Python執(zhí)行環(huán)境會誤將右操作數理解成了一個未定義的變量。因此，根據報錯信息中的問題代碼行數即可自動修改該行代碼的右操作數為實際數值，從而使得腳本運行無誤。

由于報錯是一個個出現的，因此本階段會與腳本適配階段循環(huán)執(zhí)行，直到腳本適配階段不報錯后，該腳本的預處理即處理完成，流程如圖10所示。

圖10 空白數據填寫流程圖

2.6 效果樣例

為了更好地展示預處理階段對整個方案的重要性和突出的實踐效果，本文在此挑選出一個需要用到上文全部預處理手段的實際攻擊腳本來對比其預處理前后的變化。預處理前的攻擊腳本如圖11所示。

圖11 預處理前的樣例攻擊腳本

由圖11可知，該攻擊腳本原本的文件名稱為“CVE-2018-18067-Exploit.py”，使用Python2進行編寫。在該攻擊腳本中存在著等待修改的目標IP變量，等待預設的用戶TOKEN變量，還有涉及網絡交互的變量。

而圖12中則是預處理后的腳本，此時其已經被翻譯成了符合Python3語法標準的腳本。上文提到的各類變量都已經在預處理的各個階段被處理，圖中的方框指出了修改的部分，腳本的文件名也已經與符號執(zhí)行的目標函數名保持了一致。預處理后的腳本就可以順利進入之后的符號執(zhí)行步驟。

圖12 預處理后的攻擊腳本

3 符號執(zhí)行階段

本節(jié)為整個方案的核心階段，腳本代碼的遍歷執(zhí)行、流量的采集都在本階段進行。

本文雖然有高效的Pyexz3項目作為支撐，但是該項目在Python字符串的符號執(zhí)行技術方面完全是空白，故本文進行了大量的改進與研發(fā)。

3.1 Pyexz3框架分析

本文參考并使用了微軟公司所開發(fā)的一套Python 3符號執(zhí)行引擎。該框架是Python符號執(zhí)行領域開源項目中的佼佼者。

Pyexz3引擎的效率很高，但是文檔和代碼的可讀性較差。該引擎底層使用的求解器是微軟的另一個開源項目Z3求解器。該求解器幾乎是領域內效果最好的求解器，但是文檔管理依然糟糕，3.3節(jié)中的求解示例由本文總結，并未出現在官方文檔中。

目前Pyexz3只能對整數變量進行符號執(zhí)行，不支持字符串變量的符號執(zhí)行計算。而本文對于字符串變量的符號執(zhí)行需求遠遠高于整數變量。因此本文在保留Pyexz3基本架構的情況下對其進行了大量改進，以增添字符串符號執(zhí)行的能力，改進后的項目命名為Pyexz3P。

3.2 改進設計

根據Pyexz3現有的架構，Pyexz3P項目對字符串符號執(zhí)行功能的設計結構如圖13所示。

圖13 字符串符號執(zhí)行系統架構設計圖

本結構最大程度地利用了Pyexz3項目本身在處理整數符號執(zhí)行時的結構，繼承了其高效、層次分明的優(yōu)勢。

本結構中使用SymbolicStr類來參與本符號執(zhí)行引擎的約束條件計算。當約束條件計算完成后，會集中整理并保存進入新的代碼分支所需要的全部約束條件集合Predicate實例中。

本結構中使用Z3String類來對之前整理保存的約束條件集合進行轉化。把現有的約束條件轉化為一條條Z3求解器可以理解的求解判斷規(guī)則。如此一來，求解器的接口和符號執(zhí)行邏輯就能分離開來，方便以后拓展更多高性能的求解器。

PathToConstraint類一方面是收集約束條件的核心類，另一方面也是選擇代碼路徑的核心選擇器。在微軟原本的項目中使用的是BFS樹結構遍歷算法。這個選擇對于普通大型Python項目來說是合理的，因為這類項目的代碼邏輯中分支代碼之間有大量并列關系，隨著約束分支深度的上升，求解的約束集合也會增大，此時求解器求解失敗導致符號執(zhí)行引擎失敗的概率也會上升。因此使用廣度優(yōu)先算法來處理約束樹可以優(yōu)先探索并列的代碼邏輯，較快測試到各個并列的功能。

對本文而言，BFS算法則并不適合，因為Python攻擊腳本普遍邏輯簡單，并列的功能分支較少，主要攻擊邏輯相比于其他檢測邏輯在深度上要高出許多。因此，需要優(yōu)先使用DFS算法來更快地進入真正的攻擊邏輯分支。故本文對約束遍歷的算法進行了改進。

本文使用了FunctionInvocation類與ExplorationEngine類進行實際的腳本代碼執(zhí)行。這就使得符號執(zhí)行引擎在遍歷代碼分支的同時已經真正地執(zhí)行了攻擊腳本的代碼并產生了對應的攻擊流量，而無需根據符號執(zhí)行所得的求解去重新執(zhí)行采集。

3.3 功能實現

根據以上設計，本文將其中各個部分所需要的代碼實現后，就可以使得Pyexz3P對字符串相關的判斷約束語句進行識別和加載。接下來所要做的就是在各個約束條件被加載后的分析并轉化成Z3求解器能理解的形式。

3.3.1 字符串長度的約束處理

在網絡攻擊腳本中由于存在payload這樣的對于數據長度敏感的內容，因此對于數據長度的要求有時會比反饋數據的內容更加重要。

要想實現對于字符串長度的約束條件計算，首先要先弄清最后的轉化目標——Z3求解器中相應的求解表達式。經過查閱官方文檔和代碼后，本文總結了一個示例如圖14所示。

圖14 字符串長度約束Z3構造示例圖

由此可見，需要將代碼中長度相關的約束條件轉化為一個操作數數量為1，操作符為“str.len”的expression類實例。然后轉化成Z3表達式階段將其轉化為“Length(z_l)”，其中z_l代表字符串取長度操作中唯一的左操作數。

3.3.2 字符串內容的約束處理

在一些關鍵數據的判斷上，攻擊腳本會嚴格進行字符串對比，這時候需要對字符串內容的約束條件進行求解表達式的轉化。

本文總結了兩個Z3求解器中關于字符串內容的約束求解示例，如圖15所示。

圖15 字符串內容約束Z3構造示例圖

3.3.3 子字符串內容的約束處理

在字符串的對比判斷中，子字符串占了一個很重要的角色。網絡數據中存在大量需要判斷數據格式、開頭的情景，因此，實現了對于從字符串中截取子字符串并進行符號執(zhí)行的功能需求。

由于官方文檔在子字符串處理方面完全空白，本文總結了一個Z3求解器中關于子字符串內容的約束求解示例，第一個示例如圖16所示。

圖16 子字符串內容約束Z3構造示例圖一

圖16的示例步驟在實際符號表達式解析時會過于繁瑣，因此，本文總結了另一個更適合符號執(zhí)行技術需求的示例，如圖17所示。

圖17 子字符串內容約束Z3構造示例圖二

該示例中可以精確控制子字符串在原字符串中的位置和長度，從而使求解器求解的答案更加精準。并且從示例中argv1和argv2的關聯中可以看出，本方法能解決字符串變量傳遞的問題。

3.3.4 正則表達式的處理

在字符串的對比判斷中，有時會出現正則表達式的匹配判斷。目前網上已開源的針對各種語言的符號執(zhí)行引擎中，大部分都沒有處理正則表達式約束的能力。

本文先使用正則表達式反向推導來獲得一個符合該正則表達式的字符串，將這個正則匹配約束轉化為一個3.3.2節(jié)的字符串內容約束或者3.3.3節(jié)的子字符串內容約束。這樣一來就可以解決這一類正則匹配約束了。Python下有一個開源庫名叫xeger，該庫可以根據正則表達式來反向推算符合該正則的字符串。步驟如圖18所示。

圖18 正則表達式約束Z3構造示例圖

3.4 流量的采集

在預處理中，本文將腳本中的IP和端口都設置為特定的值，這么做就是為了方便這個階段的流量采集工作。通過流量的目標IP、目標端口、本地IP和本地端口來過濾流量并抓取保存。由于符號執(zhí)行過程中幾乎每個代碼路徑都被執(zhí)行了一次，因此一個腳本中會產生多次流量。

本文對于每條執(zhí)行的代碼路徑進行了代碼覆蓋率統計，并且還綜合考慮了該條路徑最終產生的流量數據大小和Python調用API的次數，通過加權計算的方式挑選出所需的流量。

3.5 路徑遍歷策略

由于代碼路徑搜索策略的選擇對符號執(zhí)行的最終效果有很大的影響，因此本文還需要考慮當前需求下深度優(yōu)先搜索和廣度優(yōu)先搜索之間的選擇。

本文發(fā)現Pyexz3項目使用的路徑遍歷策略為深度優(yōu)先搜索，經過仔細研究代碼發(fā)現該策略不是有意為之，而是該項目在路徑遍歷功能實現中很自然地優(yōu)先將新發(fā)現的分支約束加入約束棧，產生了先進先出的效果。本文考慮到客觀情況：網絡攻擊腳本大多邏輯較為簡單，分支復雜的地方大多為攻擊腳本中反復發(fā)送或請求數據包的部分以及目標環(huán)境檢測部分。

在反復發(fā)送或請求數據包的部分代碼中會出現循環(huán)次數較高的分支代碼，如果使用深度優(yōu)先策略會使得本方案難以跳出該循環(huán)從而引起路徑爆炸。這類情況一般DDOS、數據庫拖庫相關的攻擊腳本中出現較多，需要使用廣度優(yōu)先策略來解決這一問題。

在目標環(huán)境檢測部分代碼中會出現大量的同級分支，類似于C語言中的switch邏輯。這時候使用廣度優(yōu)先策略會比深度優(yōu)先策略的效率低。但是本文在實踐中發(fā)現這并不會導致整個系統卡死，只是降低了平行跳轉邏輯的執(zhí)行效率而已。相比于上面的第一種情況中深度優(yōu)先策略會使整個系統困死在死循環(huán)中要好得多。

因此，本文中還改進了這個深度優(yōu)先的遍歷效果，將其改為廣度優(yōu)先，從而使得本文的方案在可接受的性能犧牲下快速跳出一些容易導致路徑爆炸的循環(huán)分支，進入真正的攻擊代碼邏輯中。

4 強制執(zhí)行階段

本階段為符號執(zhí)行階段的一個補救方案，并不是所有的攻擊腳本都會進入本階段，只有當符號執(zhí)行階段失敗后，才會將第一階段預處理后的標準腳本傳遞入本階段進行最后的自動采集流量嘗試。

4.1 基本理念

由于符號執(zhí)行技術與求解器技術的發(fā)展限制，一些約束的求解是無法完成的，比如許多非線性問題、涉及HASH反推的問題。這些問題的求解方法在如今數學學科發(fā)展中依然是使用暴力枚舉的手段，會大大降低求解器的效率甚至超出其求解能力范圍。因此，符號執(zhí)行階段對某些攻擊腳本可能無法順利運行。

只有遇到這樣的情況時，才會進入最后的自動化獲取流量嘗試，對腳本進行強制執(zhí)行處理。通過這種“偽符號執(zhí)行”的方法來代替特殊情況下的符號執(zhí)行需求，以此來擴大可自動化獲取攻擊腳本流量的覆蓋范圍。

4.2 具體設計

強制執(zhí)行方法雖然較為粗暴，但是其在本項目中是為了彌補符號執(zhí)行技術的不足而設計的最后自動化措施。故依然希望能夠盡可能保留代碼的執(zhí)行順序。于是本階段將會采用一個代碼樹的結構來保存代碼段，并以父子節(jié)點的關系來表示前后執(zhí)行順序。

強制執(zhí)行的基本步驟歸納如下：

(1) 將攻擊腳本中的代碼以跳轉分支指令為分割點，把腳本中的代碼分解成一個個代碼塊。

(2) 將這些代碼塊按照執(zhí)行順序存儲為樹結構。

(3) 運用樹的遍歷算法來根據代碼樹中的一條條代碼路徑生成新腳本并執(zhí)行采集流量。

代碼樹樣例如圖19所示。

圖19 代碼樹樣例圖

4.2.1 條件語句結構

這類語句中存在著一段需要滿足一定條件才能執(zhí)行的語句。在強制執(zhí)行階段會將這段代碼取出后填入代碼樹中進行強制執(zhí)行。結構轉化如圖20所示。

圖20 條件語句結構轉化圖

4.2.2 循環(huán)語句結構

這類語句中存在著一段需要滿足一定條件就能反復執(zhí)行的語句。在強制執(zhí)行階段會將這段代碼取出后填入代碼樹中進行強制執(zhí)行。結構轉化如圖21所示。

圖21 循環(huán)語句結構轉化圖

由于本文更注重代碼執(zhí)行的覆蓋率，因此循環(huán)的語句在代碼樹中僅需被執(zhí)行一次。這樣其中包含的攻擊流量就會順利生成并被采集，故無需反復執(zhí)行。

4.2.3 函數調用結構

Python語言中通常的函數調用可以分為自定義函數調用和非自定義函數調用。非自定義函數是通過引入編程庫來調用的，本文無需關心這類函數的內部實現。自定義函數是攻擊腳本中，腳本作者為了提高代碼模塊程度與可讀性而寫的，本文需要將這部分函數調用也在代碼樹中進行分段存儲。結構如圖22所示。

圖22 函數調用時的代碼樹基本結構

由于自定義函數中也可能因存在條件跳轉等結構而產生代碼樹分支。因此，自定義函數的子節(jié)點可能存在多個，每個子節(jié)點后都連接著調用函數接下來的代碼段節(jié)點，結構如圖23所示。

圖23 函數調用時的代碼樹詳細結構

4.3 代碼樹設計分析

從4.2節(jié)可以看出，代碼樹中存儲的代碼量在分支較多時，會出現在不同節(jié)點上重復存儲同一代碼段的情況。這樣無疑會使得代碼數的存儲代碼量超過原本攻擊腳本的代碼量。

但是這些重復代碼段的情況對于本項目來說開銷并不大。因為網絡攻擊腳本的代碼量普遍較短，并且條件、循環(huán)結構的使用較少，通常都是在檢測目標設備型號時使用一次，其他部分使用較少。因此由上述條件、循環(huán)結構產生的重復代碼存儲并不會造成存儲空間和代碼可能路徑的爆炸式增長。因此，本文使用以上方案是完全合適的。

5 流量特征測試

5.1 測試方法

通過在Exploit-DB等公開網站上獲取的網絡攻擊腳本來測試本套系統的運行效果。

用于測試的攻擊腳本集需要能夠完整測試到符號執(zhí)行和強制執(zhí)行的功能而不能集中在序號執(zhí)行功能上。

在測試過程中采集到的流量需要與本項目研究人員針對相同腳本手工嗅探到的流量進行對比。在對比過程中需要對流量的關鍵特征如數據包的時序特征、數據包內容特征等進行仔細比對，對于其中的差異要進行分析。

5.2 測試結果

本次測試使用下載到的一個針對MS08-067的攻擊腳本。先搭建一個運行著未更新安全補丁的Windows7操作系統虛擬機作為其攻擊的靶機環(huán)境。

通過配置虛擬機網絡環(huán)境，將攻擊者IP和目標IP分別調整至特定內網IP。在攻擊端開啟Wireshark等網絡數據包嗅探工具，使用其自帶的過濾器對IP進行過濾。手動使用攻擊腳本對靶機進行攻擊，從而獲得其在真實攻擊中所發(fā)出的攻擊流量，如表1所示。

表1 真實攻擊所捕獲的流量

接下來將此腳本通過本系統進行處理，處理完成后，選擇了流量最多的那條代碼路徑。其所對應的流量特征如數據表2所示。

表2 通過符號執(zhí)行所捕獲的流量

5.3 結果分析

本系統產生的流量與真實攻擊過程中產生的網絡流量相似度很高，數據包之間的先后順序和數據內容都與真實攻擊相符。

在數據包內容和時序上已經高度相似的基礎上，接下來進一步查看其整體的流量特性。根據表1、表2中的數據進一步畫出本系統產生的流量和實際攻擊中攻擊方產生的流量的時域分布圖，如圖24、圖25所示。

圖24 本系統采集的攻擊流量時間分布

圖25 實際攻擊流量的時間分布

5.3.1 誤差分析1

由圖24、圖25可看出，本系統產生的流量整體相似度非常高。這是因為符號執(zhí)行過程中帶入求解答案進行執(zhí)行時運行的代碼與真實攻擊中的代碼是完全一樣的。因此，產生的攻擊流量在內容特征和時間特征上的相似度也會非常高。

不過可以看出，時間分布上有少量偏差。進一步計算各個包的偏差值發(fā)現其具有明顯隨機性，故認為這是由于網絡傳輸環(huán)境的變化而造成的正常誤差。

從兩幅圖的對比也可以看出，有少量折線點分布不同，即圖24中的第11點和圖25中的第12點附近。進一步分析流量內容可知，這部分數據點為雙方網絡連接正常產生的數據包，與攻擊流量無關，故可以忽略。

5.3.2 誤差分析2

由圖24、圖25可看出，本系統產生的流量在時域分布上雖然順序相同，但是時間間隔上出現了明顯的偏差。

于是本文更換了一個攻擊腳本進行了多次對比實驗，在數據包內容特征上依然相同，但是這次在時間間隔上出現了較大不同，如圖26-圖29所示。

圖26 對比實驗一

圖27 對比實驗二

圖28 對比實驗三

圖29 對比實驗四

經過仔細分析，其原因為：真實攻擊中經常需要等待被攻擊方的反饋來進行下一步的攻擊，而本系統中將反饋變量符號化進行求解計算，無需等待真實靶機反饋，故流量產生較快。

然而本文認為攻擊數據包發(fā)送時間間隔縮小并不會影響其在各類安全產品中的測試效果。因為當前大部分威脅情報系統、防火墻等都主要根據數據包內容進行特征匹配，而數據包間隔受客觀網絡環(huán)境好壞影響而無法確定，故幾乎不考慮。因此，本文采集的攻擊流量依然有相當高的研究價值。

6 符號執(zhí)行效果測試

6.1 測試方法

本文收集了50個網絡上公開的Python攻擊腳本進行測試，挑選這些腳本時，盡可能優(yōu)先選擇較新的腳本。漏洞的種類涵蓋了遠程破解、網絡應用攻擊、拒絕服務攻擊等各個方面且數量平均。

用本文提出的方案對這些測試攻擊腳本進行處理，觀察其符號執(zhí)行的實際效果。并且使用本文改進的Pyexz3P項目與原本的Pyexz3項目進行性能對比。

6.2 測試結果

經過測試，本文統計了各種特征的50個攻擊腳本的符號執(zhí)行效果，如表3所示。

表3 通過符號執(zhí)行所捕獲的流量

表3中，總共50個攻擊腳本，Pyexz3P成功執(zhí)行了49個，僅僅在其中一個包含特殊形式參數的攻擊腳本上執(zhí)行失敗，但是強制執(zhí)行成功。而Pyexz3原項目則有20個攻擊腳本符號執(zhí)行失敗，個別腳本上還出現了多個錯誤。最終統計出由于路徑爆炸而失敗2次，由于關鍵變量形式特殊而失敗4次，由于沒有主函數而失敗17次，由于沒有字符串符號執(zhí)行能力而失敗2次。

6.3 結果分析

從結果數據中可以看出，本文的方案由于使用了廣度優(yōu)先算法而成功跳出了測試腳本中的2個包含100次以上循環(huán)結構的攻擊腳本。而使用深度優(yōu)先策略則在這樣的大量循環(huán)結構中難以逃脫。

本文在第2節(jié)中的預處理使得本文的方案在避免特殊形式參數、不規(guī)范的主函數上的能力大大提升。這也是直觀數據上本方案對原項目效果最明顯的改進，甚至超越了符號執(zhí)行技術本身。

雖然原項目僅僅因為字符串符號執(zhí)行的問題失敗了兩次，但是測試腳本中涉及字符串約束計算的攻擊腳本也只有兩個。因此其實本文在字符串符號執(zhí)行能力上的改進是從無到有的大改進，并且也使本方案達到了工業(yè)可用的水平。

7 結 語

本文提出了一整套自動化提取網絡攻擊Python腳本的流量收集方法。相比于一般針對腳本的符號執(zhí)行項目，本文注意到了對腳本的預處理在整個自動化分析中的關鍵作用并詳細闡述了這個預處理過程中需要進行的各項處理，從而使得本項目的穩(wěn)定性大大提高。

此外本文以符號執(zhí)行為自動化提取流量的核心，同時也注意到了這項技術當前客觀發(fā)展的不足而提出了強制執(zhí)行作為候補方案，從而極大地提高了本系統提取攻擊流量時的穩(wěn)定性與成功率。

在測試階段，本方案展示出了不俗的提取效果，所提取的網絡攻擊流量真實度很高，攻擊特征保留完好。并且符號執(zhí)行功能上的改進也使得本方案的通用性和健壯性大大增強。對于之后的安全研究工作有著積極的推動作用。

由于求解器技術的發(fā)展限制，一些約束問題的求解方法在當前客觀的計算機算法科學或者數學科學發(fā)展程度下是無法求出合適答案的。因此，希望之后符號執(zhí)行領域或者求解器領域相關研究工作可以加入最新的求解算法來增強符號執(zhí)行引擎的求解能力，擴大其可以處理的約束條件范圍。這個方向的發(fā)展進步無疑可以在日后提高本項目中順利使用符號執(zhí)行進行流量生成的腳本比例，同時降低生成流量效果較為遜色的強制執(zhí)行比例。

本文解決的是使用Python語言編寫的網絡攻擊腳本。盡管Python的確是大部分網絡攻擊腳本所使用的編程語言，但是也有許多網絡攻擊腳本使用了別的編程語言如Ruby語言。故希望有別的項目可以參考本文，對更多編程語言的攻擊腳本進行自動化分析與流量采集。

由于本文針對的對象是網絡攻擊腳本，因此其跳轉邏輯往往并不復雜，判斷語句所產生的約束條件也十分易于被當前的求解器解決。因此，作為符號執(zhí)行引擎的補救方案——強制執(zhí)行，實際用到的比例較低。故對于這個補救方案并沒有做過多的優(yōu)化，因為這在本項目中的回報并不明顯。但是對于目前許多符號執(zhí)行引擎技術依然是空白的新編程語言來說，強制執(zhí)行是一個很好的候選方案。這個方案的技術入門門檻低，建設成本小，并且效果也能滿足大多數測試需求。因此，希望這個方案可以被其他項目參考選用并被優(yōu)化。