寫在前面的話

Fuzzing(模糊測(cè)試)是一種識(shí)別軟件設(shè)計(jì)缺陷和安全漏洞的方法。隨著技術(shù)的不斷進(jìn)步，F(xiàn)uzzing也逐步轉(zhuǎn)移到了云端(Cloud)。與傳統(tǒng)的模糊測(cè)試技術(shù)相比，Cloud Fuzzing不僅可以提升模糊測(cè)試的速度，而且還可以提升測(cè)試的可擴(kuò)展程度。在這篇文章中，我們將介紹Cloud Fuzzing的完整過程。通過這種技術(shù)(softScheck Cloud Fuzing Framework-sCFF)，我成功地在Ubuntu 16.04的tcpdump(4.9版本)中發(fā)現(xiàn)了一個(gè)安全漏洞。感興趣的同學(xué)可以自行下載sCFF框架，并按照本文的操作步驟動(dòng)手嘗試一下。

[[189942]]

一、背景知識(shí)

第一章主要介紹的是與本文有關(guān)的一些基礎(chǔ)知識(shí)以及測(cè)試會(huì)用到的程序。如果你之前已經(jīng)比較了解Cloud Fuzzing了，你可以直接閱讀第二章。但是，我們強(qiáng)烈建議各位按照文章順序進(jìn)行閱讀。

1. Fuzzing(模糊測(cè)試)

Fuzzing是一種測(cè)試軟件健壯性的技術(shù)。模糊測(cè)試，也稱Fuzzing或Fuzz測(cè)試，它是一種自動(dòng)化軟件測(cè)試技術(shù)，主要通過向被測(cè)目標(biāo)輸入大量的畸形數(shù)據(jù)并監(jiān)測(cè)其異常來發(fā)現(xiàn)漏洞，是當(dāng)前安全業(yè)界流行的漏洞挖掘手段之一。從廣義角度來看，該技術(shù)的關(guān)鍵在于如何構(gòu)造有效的測(cè)試用例(輸入的畸形數(shù)據(jù))，以及如何有效的監(jiān)控異常。Fuzzing技術(shù)簡(jiǎn)單、有效、自動(dòng)化程度比較高，是目前工業(yè)界進(jìn)行安全測(cè)試最有效的方法，被廣泛應(yīng)用于Web、系統(tǒng)、應(yīng)用程序的漏洞挖掘。由于它一般屬于黑盒測(cè)試，通過構(gòu)造有效的畸形數(shù)據(jù)進(jìn)行測(cè)試，因此該技術(shù)的代碼覆蓋率相對(duì)較低，且它的測(cè)試效率跟測(cè)試人員的經(jīng)驗(yàn)和技術(shù)有很大關(guān)系。

[[189943]]

在此之前，模糊測(cè)試通常是在本地計(jì)算機(jī)中進(jìn)行的，但隨著“基礎(chǔ)設(shè)施即服務(wù)”的趨勢(shì)不斷興趣，越來越多的企業(yè)開始提供云端服務(wù)了。實(shí)際上，類似微軟和Google這樣的大型公司早就已經(jīng)在云端實(shí)現(xiàn)了模糊測(cè)試技術(shù)。例如在Springfield項(xiàng)目中，微軟公司甚至已經(jīng)開始向廣大開發(fā)者提供Cloud Fuzzing服務(wù)了。

那么我們我什么要用Cloud Fuzzing而不用傳統(tǒng)的模糊測(cè)試技術(shù)呢?首先，Cloud Fuzzing意味著你不需要再購(gòu)買額外的電腦了，而購(gòu)買測(cè)試設(shè)備不僅需要花很多錢，而且你還需要花時(shí)間去搭建和配置測(cè)試環(huán)境。但Cloud Fuzzing最大的優(yōu)勢(shì)就在于它所能提供的靈活性和可擴(kuò)展性，它可以在短時(shí)間內(nèi)完成大量的工作，并幫助測(cè)試人員節(jié)省大量的時(shí)間。比如說，Cloud Fuzzing可以在同一時(shí)間在多種不同的操作系統(tǒng)上對(duì)同一個(gè)程序進(jìn)行模糊測(cè)試。如果一個(gè)項(xiàng)目對(duì)數(shù)據(jù)吞吐量有較高要求，那么這個(gè)測(cè)試實(shí)例就可以使用多塊固態(tài)硬盤(RAID0配置);如果一個(gè)程序需要大量的RAM，那么我們就可以選擇一個(gè)可以提供大量RAM的配置。如果我們需要對(duì)一個(gè)Web應(yīng)用或網(wǎng)絡(luò)協(xié)議進(jìn)行測(cè)試，那么Cloud Fuzzing就可以給我們提供大量的終端節(jié)點(diǎn)。

當(dāng)然了，Cloud Fuzzing也有其不足之處。首先，你必須充分信任云端的提供方，因?yàn)槟闼械囊磺卸歼\(yùn)行在云端設(shè)備上，而不是運(yùn)行在你自己的設(shè)備中。其次，你在使用Cloud Fuzzing時(shí)是需要付費(fèi)的，那么當(dāng)你使用了幾個(gè)月甚至幾年之后，你所支付過的費(fèi)用可能要比你自行購(gòu)買測(cè)試設(shè)備所花的錢還要多。

2. 亞馬遜AWS

亞馬遜Web服務(wù)(AWS)是Amazon.com所提供的一系列在線服務(wù)的集合，而AWS也是目前云計(jì)算領(lǐng)域中最大的巨頭。AWS其中的一個(gè)組件為彈性云計(jì)算(EC2)，EC2允許用戶設(shè)置虛擬機(jī)，用戶可以對(duì)其進(jìn)行各種配置，并將其充當(dāng)服務(wù)器使用。用戶所創(chuàng)建的一個(gè)實(shí)例本質(zhì)上就是云端的一臺(tái)虛擬服務(wù)器，它由操作系統(tǒng)和軟件應(yīng)用所組成，用戶在創(chuàng)建的過程中還可以自行分配服務(wù)器所需的資源。除此之外，用戶也可以在亞馬遜設(shè)備鏡像(AMI)庫(kù)中選擇需要的操作系統(tǒng)，而且亞馬遜也給用戶提供了一百多種不同的機(jī)器配置選項(xiàng)，用戶可以根據(jù)自己的需要來選擇配置文件。用戶付費(fèi)是按機(jī)器運(yùn)行小時(shí)來付費(fèi)的，而高配置實(shí)例的成本要比低配置實(shí)例要低得多。

3. softScheck Cloud Fuzzer Framework

為了盡可能地簡(jiǎn)化模糊測(cè)試的過程，softScheck的技術(shù)人員開發(fā)出了softScheck Cloud Fuzzer Framework(sCFF)。sCFF采用Python 3編寫，并使用Boto 3 API來與AWS通信。sCFF由多種子程序組成，其中的每個(gè)工具都可以完成多項(xiàng)任務(wù)。

在下圖中，我們根據(jù)模糊測(cè)試的階段來對(duì)sCFF子程序進(jìn)行了分類：

4. American fuzzy lop

American fuzzy log(afl)是sCFF所使用的模糊測(cè)試器(fuzzer)，afl以其測(cè)試速度、穩(wěn)定性和操作界面而為人所知，而且它可以幫助我們發(fā)現(xiàn)軟件中的各種漏洞。如果我們擁有測(cè)試目標(biāo)的源碼，那么它在對(duì)源碼進(jìn)行了分析之后，不僅能夠生成更加合適的測(cè)試向量，而且還可以顯著提升測(cè)試覆蓋率。而在給定的時(shí)間里，代碼覆蓋率越大，那么掃描到安全漏洞的可能性也就越高。下圖顯示的是afl的運(yùn)行界面：

5. tcpdump

眾所周知，Tcpdump是一個(gè)網(wǎng)絡(luò)數(shù)據(jù)包分析器，它可以捕捉、顯示、并以pcap文件格式保存目標(biāo)網(wǎng)絡(luò)所發(fā)送的數(shù)據(jù)包。與Wireshark不同的是，Tcpdump可以通過簡(jiǎn)單的命令(無需交互)來運(yùn)行，這樣可以讓模糊測(cè)試過程變得更加簡(jiǎn)單。

6. GNU Debugger

在GNU DeBugger(GDB)的幫助下，我們可以對(duì)軟件的運(yùn)行狀態(tài)進(jìn)行一步一步地分析，以便我們找出軟件崩潰的原因。

二、使用sCFF來對(duì)tcpdump進(jìn)行模糊測(cè)試

在了解完基礎(chǔ)知識(shí)之后，接下來讓我們嘗試尋找一下tcpdump 4.9中存在的漏洞。

1. 準(zhǔn)備工作

如果你想要找出tcpdump中的漏洞，你首先要配置AWS實(shí)例和sCFF。

要求：

• -創(chuàng)建一個(gè)AWS賬號(hào);
• -導(dǎo)出AWS密鑰ID和密鑰;
• -.aws/config中應(yīng)該包含你的地區(qū)信息，.aws/credentials中應(yīng)該包含密鑰ID和訪問密鑰;
• -創(chuàng)建一個(gè)SSH安全組，并允許實(shí)例與外部端口22之間進(jìn)行通信;
• -創(chuàng)建并下載密鑰對(duì)(SSH通信需要使用到這些密鑰);
• -下載并安裝sCFF;

2. 預(yù)測(cè)試階段

準(zhǔn)備工作完成之后，我們要下載tcpdump v4.9的源代碼。當(dāng)然了，你也可以直接使用git來下載tcpdump的最新版本，雖然本文所描述的漏洞在新版本中已經(jīng)修復(fù)了，但你說不定可以使用本文的方法找出新的漏洞呢?

下載完成之后，我們可以使用“CC=afl-gcc ./configure && make”命令來編譯源碼。

編譯成功之后，我們通過“scff-mkconfig”命令來創(chuàng)建一個(gè)sCFF項(xiàng)目文件。請(qǐng)確保將target參數(shù)設(shè)置為“tcpdump”，將“args”參數(shù)設(shè)置為“–e –r @@”。其中“-e”和“-r”都是tcpdump的參數(shù)，“-e”表示打印出數(shù)據(jù)包中的擴(kuò)展header，“-r”用于讀取文件。下面是我們通過“scff-mkconfig”命令創(chuàng)建出的配置文件：

[INSTANCES] 
amiami = ami-0963b466 
gid = tcpdump49 
instancetype = t2.micro 
name = auto 
numberofmachines = 4 
platform = linux 
   
[FUZZING] 
dependencies = none 
fuzzer = afl 
fuzzdir = fuzzing 
inputdir = fuzzing/input 
outputdir = fuzzing/output 
template = ipv4.pcap 
target = tcpdump 
args = -e -r @@ 

注：現(xiàn)在，亞馬遜允許用戶通過“scff-create-instances”命令來創(chuàng)建EC2實(shí)例。

3. 測(cè)試階段

接下來，我們可以通過命令“scff-ctrl . bootstrap”來對(duì)用于Fuzzing測(cè)試的設(shè)備進(jìn)行配置。配置完成之后，模糊測(cè)試便開始了。sCFF允許我們選擇單模Fuzzing和分布式Fuzzing。在單模Fuzzing下，每一個(gè)實(shí)例都會(huì)運(yùn)行一個(gè)fuzzer;二在分布式Fuzzing中，雖然仍是每一個(gè)實(shí)例運(yùn)行一個(gè)fuzzer，但fuzzing數(shù)據(jù)會(huì)在實(shí)例間共享，這樣可以提升測(cè)試速度。如果你擁有兩個(gè)以上的實(shí)例，我們推薦使用分布式Fuzzing模式(命令：“scff-ctrl . distributed”)。如果想要了解測(cè)試的狀態(tài)，我們可以通過瀏覽器來訪問云服務(wù)器進(jìn)行查看，并通過命令“scff-ctrl . grab-findings”來下載錯(cuò)誤日志。

4. 測(cè)試完成后

“scff-exploitcheck”命令將會(huì)對(duì)我們的發(fā)現(xiàn)進(jìn)行分析，假陽性和重復(fù)出現(xiàn)的崩潰信息將會(huì)被過濾，最后剩下的信息將會(huì)用于漏洞的檢測(cè)和利用。

如果找到的信息有紅色的“EXPLOITABLE”標(biāo)簽標(biāo)注，那么這里存在漏洞的可能性就非常高了。正如上圖所示，tcpdump 4.9的文件printsl.c中存在一個(gè)可利用的漏洞。接下來，我們用GDB來對(duì)崩潰信息進(jìn)行分析：

分析后我們可以看到，dir為255，而且dir也是lastlen其中的一個(gè)引用參數(shù)(定義為lastlen[2][255])，這里存在參數(shù)越界，而正是這一點(diǎn)導(dǎo)致了崩潰的出現(xiàn)。

如果要解決這個(gè)問題，我們可以更正dir的值，或者檢查dir的值是否在0到2之間?，F(xiàn)在，我們可以在dir = p[DIR_SLX]后面設(shè)置一個(gè)斷點(diǎn)，然后在gdb中修改dir的值，感興趣的同學(xué)可以自己嘗試寫一個(gè)補(bǔ)丁【參考資料】。

修復(fù)之后，再對(duì)源碼重新進(jìn)行編譯，然后檢查程序是否還會(huì)崩潰。

三、總結(jié)

這個(gè)漏洞并不是非常的嚴(yán)重，因?yàn)楣粽弑仨氁屇繕?biāo)用戶使用“-e”參數(shù)來打開pcap文件才可以完成攻擊。雖然攻擊難度較大，但這仍然是一個(gè)安全漏洞。我們也將該漏洞上報(bào)給了tcpdump的安全團(tuán)隊(duì)，這個(gè)漏洞將在tcpdump v4.10中得到修復(fù)。

整個(gè)測(cè)試過程大約需要五個(gè)小時(shí)，其中包括發(fā)現(xiàn)并修復(fù)漏洞。

Downloading and compiling tcpdump:            10 minutes 
Pre Fuzzing Phase + template generation:     10 minutes 
Fuzzing Phase:                               110 minutes 
Post Fuzzing Phase:                       60 minutes 
Patch writing and retesting:                90 minutes 
----------------------------------------------------------- 
Total:                                          300 minutes