我如何使用Cloud Fuzzing挖到了一個tcpdump漏洞
寫在前面的話
Fuzzing(模糊測試)是一種識別軟件設計缺陷和安全漏洞的方法。隨著技術的不斷進步，Fuzzing也逐步轉移到了云端(Cloud)。與傳統的模糊測試技術相比，Cloud Fuzzing不僅可以提升模糊測試的速度，而且還可以提升測試的可擴展程度。在這篇文章中，我們將介紹Cloud Fuzzing的完整過程。通過這種技術(softScheck Cloud Fuzing Framework-sCFF)，我成功地在Ubuntu 16.04的tcpdump(4.9版本)中發現了一個安全漏洞。感興趣的同學可以自行下載sCFF框架，并按照本文的操作步驟動手嘗試一下。
一、背景知識
第一章主要介紹的是與本文有關的一些基礎知識以及測試會用到的程序。如果你之前已經比較了解Cloud Fuzzing了，你可以直接閱讀第二章。但是，我們強烈建議各位按照文章順序進行閱讀。
1. Fuzzing(模糊測試)
Fuzzing是一種測試軟件健壯性的技術。模糊測試，也稱Fuzzing或Fuzz測試，它是一種自動化軟件測試技術，主要通過向被測目標輸入大量的畸形數據并監測其異常來發現漏洞，是當前安全業界流行的漏洞挖掘手段之一。從廣義角度來看，該技術的關鍵在于如何構造有效的測試用例(輸入的畸形數據)，以及如何有效的監控異常。Fuzzing技術簡單、有效、自動化程度比較高，是目前工業界進行安全測試最有效的方法，被廣泛應用于Web、系統、應用程序的漏洞挖掘。由于它一般屬于黑盒測試，通過構造有效的畸形數據進行測試，因此該技術的代碼覆蓋率相對較低，且它的測試效率跟測試人員的經驗和技術有很大關系。
在此之前，模糊測試通常是在本地計算機中進行的，但隨著“基礎設施即服務”的趨勢不斷興趣，越來越多的企業開始提供云端服務了。實際上，類似微軟和Google這樣的大型公司早就已經在云端實現了模糊測試技術。例如在Springfield項目中，微軟公司甚至已經開始向廣大開發者提供Cloud Fuzzing服務了。
那么我們我什么要用Cloud Fuzzing而不用傳統的模糊測試技術呢?首先，Cloud Fuzzing意味著你不需要再購買額外的電腦了，而購買測試設備不僅需要花很多錢，而且你還需要花時間去搭建和配置測試環境。但Cloud Fuzzing最大的優勢就在于它所能提供的靈活性和可擴展性，它可以在短時間內完成大量的工作，并幫助測試人員節省大量的時間。比如說，Cloud Fuzzing可以在同一時間在多種不同的操作系統上對同一個程序進行模糊測試。如果一個項目對數據吞吐量有較高要求，那么這個測試實例就可以使用多塊固態硬盤(RAID0配置);如果一個程序需要大量的RAM，那么我們就可以選擇一個可以提供大量RAM的配置。如果我們需要對一個Web應用或網絡協議進行測試，那么Cloud Fuzzing就可以給我們提供大量的終端節點。
當然了，Cloud Fuzzing也有其不足之處。首先，你必須充分信任云端的提供方，因為你所有的一切都運行在云端設備上，而不是運行在你自己的設備中。其次，你在使用Cloud Fuzzing時是需要付費的，那么當你使用了幾個月甚至幾年之后，你所支付過的費用可能要比你自行購買測試設備所花的錢還要多。
2. 亞馬遜AWS
亞馬遜Web服務(AWS)是Amazon.com所提供的一系列在線服務的集合，而AWS也是目前云計算領域中最大的巨頭。AWS其中的一個組件為彈性云計算(EC2)，EC2允許用戶設置虛擬機，用戶可以對其進行各種配置，并將其充當服務器使用。用戶所創建的一個實例本質上就是云端的一臺虛擬服務器，它由操作系統和軟件應用所組成，用戶在創建的過程中還可以自行分配服務器所需的資源。除此之外，用戶也可以在亞馬遜設備鏡像(AMI)庫中選擇需要的操作系統，而且亞馬遜也給用戶提供了一百多種不同的機器配置選項，用戶可以根據自己的需要來選擇配置文件。用戶付費是按機器運行小時來付費的，而高配置實例的成本要比低配置實例要低得多。
3. softScheck Cloud Fuzzer Framework
為了盡可能地簡化模糊測試的過程，softScheck的技術人員開發出了softScheck Cloud Fuzzer Framework(sCFF)。sCFF采用Python 3編寫，并使用Boto 3 API來與AWS通信。sCFF由多種子程序組成，其中的每個工具都可以完成多項任務。
在下圖中，我們根據模糊測試的階段來對sCFF子程序進行了分類：
4. American fuzzy lop
American fuzzy log(afl)是sCFF所使用的模糊測試器(fuzzer)，afl以其測試速度、穩定性和操作界面而為人所知，而且它可以幫助我們發現軟件中的各種漏洞。如果我們擁有測試目標的源碼，那么它在對源碼進行了分析之后，不僅能夠生成更加合適的測試向量，而且還可以顯著提升測試覆蓋率。而在給定的時間里，代碼覆蓋率越大，那么掃描到安全漏洞的可能性也就越高。下圖顯示的是afl的運行界面：
5. tcpdump
眾所周知，Tcpdump是一個網絡數據包分析器，它可以捕捉、顯示、并以pcap文件格式保存目標網絡所發送的數據包。與Wireshark不同的是，Tcpdump可以通過簡單的命令(無需交互)來運行，這樣可以讓模糊測試過程變得更加簡單。
6. GNU Debugger
在GNU DeBugger(GDB)的幫助下，我們可以對軟件的運行狀態進行一步一步地分析，以便我們找出軟件崩潰的原因。
二、使用sCFF來對tcpdump進行模糊測試
在了解完基礎知識之后，接下來讓我們嘗試尋找一下tcpdump 4.9中存在的漏洞。
1. 準備工作
如果你想要找出tcpdump中的漏洞，你首先要配置AWS實例和sCFF。
要求：
- -創建一個AWS賬號;
- -導出AWS密鑰ID和密鑰;
- -.aws/config中應該包含你的地區信息，.aws/credentials中應該包含密鑰ID和訪問密鑰;
- -創建一個SSH安全組，并允許實例與外部端口22之間進行通信;
- -創建并下載密鑰對(SSH通信需要使用到這些密鑰);
- -下載并安裝sCFF;
2. 預測試階段
準備工作完成之后，我們要下載tcpdump v4.9的源代碼。當然了，你也可以直接使用git來下載tcpdump的最新版本，雖然本文所描述的漏洞在新版本中已經修復了，但你說不定可以使用本文的方法找出新的漏洞呢?
下載完成之后，我們可以使用“CC=afl-gcc ./configure && make”命令來編譯源碼。
編譯成功之后，我們通過“scff-mkconfig”命令來創建一個sCFF項目文件。請確保將target參數設置為“tcpdump”，將“args”參數設置為“–e –r @@”。其中“-e”和“-r”都是tcpdump的參數，“-e”表示打印出數據包中的擴展header，“-r”用于讀取文件。下面是我們通過“scff-mkconfig”命令創建出的配置文件：
- [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 @@
注：現在，亞馬遜允許用戶通過“scff-create-instances”命令來創建EC2實例。
3. 測試階段
接下來，我們可以通過命令“scff-ctrl . bootstrap”來對用于Fuzzing測試的設備進行配置。配置完成之后，模糊測試便開始了。sCFF允許我們選擇單模Fuzzing和分布式Fuzzing。在單模Fuzzing下，每一個實例都會運行一個fuzzer;二在分布式Fuzzing中，雖然仍是每一個實例運行一個fuzzer，但fuzzing數據會在實例間共享，這樣可以提升測試速度。如果你擁有兩個以上的實例，我們推薦使用分布式Fuzzing模式(命令：“scff-ctrl . distributed”)。如果想要了解測試的狀態，我們可以通過瀏覽器來訪問云服務器進行查看，并通過命令“scff-ctrl . grab-findings”來下載錯誤日志。
4. 測試完成后
“scff-exploitcheck”命令將會對我們的發現進行分析，假陽性和重復出現的崩潰信息將會被過濾，最后剩下的信息將會用于漏洞的檢測和利用。
如果找到的信息有紅色的“EXPLOITABLE”標簽標注，那么這里存在漏洞的可能性就非常高了。正如上圖所示，tcpdump 4.9的文件printsl.c中存在一個可利用的漏洞。接下來，我們用GDB來對崩潰信息進行分析：
分析后我們可以看到，dir為255，而且dir也是lastlen其中的一個引用參數(定義為lastlen[2][255])，這里存在參數越界，而正是這一點導致了崩潰的出現。
如果要解決這個問題，我們可以更正dir的值，或者檢查dir的值是否在0到2之間?，F在，我們可以在dir = p[DIR_SLX]后面設置一個斷點，然后在gdb中修改dir的值，感興趣的同學可以自己嘗試寫一個補丁【參考資料】。
修復之后，再對源碼重新進行編譯，然后檢查程序是否還會崩潰。
三、總結
這個漏洞并不是非常的嚴重，因為攻擊者必須要讓目標用戶使用“-e”參數來打開pcap文件才可以完成攻擊。雖然攻擊難度較大，但這仍然是一個安全漏洞。我們也將該漏洞上報給了tcpdump的安全團隊，這個漏洞將在tcpdump v4.10中得到修復。
整個測試過程大約需要五個小時，其中包括發現并修復漏洞。
- 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
