云端模糊測試挖洞實例
一、簡介
Fuzzing(模糊測試)是一種用于識別軟件bug以及漏洞的方法。就目前的發展趨勢來說Fuzzing正向著云端邁進，相較于傳統Fuzzing方式，云端Fuzzing使得模糊測試速度加快也更加靈活。在本教程中，我們將與你一同走完云端模糊測試的全過程(即部署，Fuzzing以及使用softScheck Cloud Fuzzing Framework (sCFF)框架檢索結果)。我們將以運行在Ubuntu 16.04上的tcpdump4.9版本為例進行演示，讀者可下載sCFF框架，和我們一同玩耍。
二、背景知識
第一章節將講解在使用過程中會遇到的一些基礎問題。當然，如果你對云端模糊測試有一定經驗或者對這些基礎問題足夠了解的情況下可以跳過本章節。此外，我們強烈建議從上到下依次閱讀本文，子章節可能有些簡短，但是都會提供大家進一步了解詳情的傳送門。
1. Fuzzing
Fuzzing是一項用于軟件強度測試的技術。其核心思想是自動或半自動的生成隨機數據輸入到一個程序中，并監控目標程序異常，如崩潰，斷言(assertion)失敗，以發現可能的程序錯誤，比如內存泄漏。
這些異常大多數都是軟件漏洞，經驗豐富的攻擊者完全可以進行利用。由于其自動化特性以及可以應用于所有軟件中，Fuzzing常作為安全專家的基本裝備存在。盡管知曉源代碼可以加快模糊測試的速度，但是并非必須的。數十年來，模糊測試工具以及目標應用都是在本地計算機上運行。然而隨著各種云計算服務商興起，似乎在云端運行模糊測試工具也是個不錯的選擇。事實上像微軟，谷歌等大型公司已經實現在云端進行模糊測試了。在云端模糊測試方面，微軟還要領先一步，其Springfield項目甚至還向開發者提供云端模糊測試服務。
相對于傳統模糊測試，云端模糊測試有哪些優點呢?首先你不需要額外購買計算機，省錢，節省空間，不需要花過多時間去設置環境等等，云端模糊測試的主要優勢還是它所具有的靈活性，同一時間程序可以在多個操作系統上進行測試，檢測是否會出現不同表現行為。如果一個項目對數據吞吐量要求較高，就可以利用RAID0陣列中的SSD。當一個應用程序需要大量的RAM，也可以選擇一個相應的實例。如果需要測試一個web應用或者是網絡協議，這里有許多低階終端，所以相對來說完成任務的花費就很便宜。
當然這里也是存在缺點的。首先你得相信為你提供云服務的商家，因為所有數據都是在云端運行，而非你個人的計算機。此外，你多用幾個月所需要支付的價格差不多也夠你自己再買一臺計算機的價格了。
2. Amazon AWS
Amazon Web Services是指Amazon提供的各類云端服務合集，目前AWS是全球最大的一家提供云計算服務的公司。AWS中有一個名為Elastic Compute Cloud (EC2)的組件，EC2允許用戶自己配置虛擬機作為服務器使用。在云端創建的這個虛擬服務器實例，在創建時就可以選擇操作系統，預安裝軟件，資源分配等各種設置。至于操作系統，用戶可以依靠Amazon龐大的鏡像庫AMI進行選擇，我們可以從Amazon提供的100余種不同的機器配置中自由選擇。用戶只需要按每小時支付費用，當然配置越高收費越貴咯!
3. softScheck Cloud Fuzzer Framework
softScheck為了讓模糊測試過程更加輕松，使用Python 3開發了softScheck Cloud Fuzzer Framework(sCFF)，該框架使用Boto 3 API與AWS進行通信。sCFF遵循Unix范式將不同的子程序分開：一個程序專注一件事。
4. American fuzzy lop
American fuzzy lop (afl)是sCFF框架中的一個模糊測試工具。以其速度，可靠性，復古風格的UI設計以及赫赫戰功而聞名。如果可以獲得測試軟件的源代碼，不僅能生成更加客觀的模糊測試結果，還能提高測試覆蓋率。編者注：當前大多數遠程代碼執行和特權提升等比較嚴重的漏洞基本是使用Fuzzing技術挖掘的，然而Fuzzing技術仍然存在著覆蓋率低的缺陷。而許多的代碼漏洞需要更大的路徑覆蓋率才能觸發，而不是通過純粹的隨機嘗試。
5. tcpdump
Tcpdump是一款著名的網絡數據包分析工具。它能抓取，顯示，以pcap文件格式保存網絡中的數據包，之后這些數據將以更友好的方式提供給使用者。不同于老大哥Wireshark，Tcpdump是一個非交互式命令行程序，對于模糊測試來說更加方便。
6. GNU Debugger
GNU DeBugger (GDB),可以對軟件運行狀態進行單步分析，更精確的找出導致程序崩潰的原因。如果分析的是包含調試標志的二進制代碼，你可以知道當前程序正在運行代碼的那一行，對于修復bug來說更加輕松。甚至還可以在運行時修改某些變量的值，用以快速觀察變量值改變是否能修復bug。
三、使用sCFF來對tcpdump進行模糊測試
介紹完背景知識后，接著繼續我們文首提到的tcpdump 4.9漏洞發現之旅。這一章分為兩個部分，首先就是章節列表，這是需要你在繼續本教程之前完成的任務。由于文章篇幅的限制，這些內容并沒有寫入文章，還好網上已經有大量的文章教程可以使用。其次涵蓋了預模糊測試階段，主要講解了在真是環境下進行模糊測試之前應該做的事情，最后即是發現漏洞后你該怎么做。
1. 前期工作
如果你想要以云端模糊測試的方法找出tcpdump中存在的漏洞，你首先需要完成一些本教程沒涉及到的步驟，基本上這些操作可以歸結為AWS以及sCFF框架的配置。如果你想以傳統的本地模糊測試方法尋找漏洞，或者僅僅只是了解一下云端模糊測試，你可以跳過這些步驟。
必選項：
- 創建一個AWS賬號
- 導出AWS密鑰ID和密鑰
- .aws/config中應該包含你的域信息，.aws/credentials中應該包含密鑰ID和訪問密鑰
- 創建SSH安全組，以允許實例與外部端口22之間進行通信
- 創建并下載密鑰對(SSH通信需要使用到這些密鑰)
- 下載并安裝sCFF;
可選項：
- 為了進行模糊測試， 需要安裝AFL的語言環境
- 確保afl-collect以及GDB + exploitable plugin已安裝
2. 預模糊測試階段
前期工作完成之后，接著便下載tcpdump 4.9版本的源代碼。你也可以下載最新的git版本，雖然本文作為案例的漏洞在新版本中已進行修復，但誰能保證不會有其他驚喜呢?在下載源代碼之后，使用afl-gcc編譯對于之后的模糊測試是有幫助的(CC=afl-gcc ./configure && make)
編譯成功之后，運行scff-mkconfig指令創建一個sCFF項目文件。請確保將target設置為tcpdump，參數設置為–e –r @@。其中-e和-r都是tcpdump的參數，-e表示打印擴展頭，-r表示讀取文件。這兩個標志在之后會被afl每次生成的模糊測試文件替換。記住，如果你是是第一次注冊AWS t2機器，只要運行時低于750小時都可以免費使用。所以你可能會堅持使用t2機器進行模糊測試。為了更快的得到測試結果，推薦大家使用一個模版，使用了一個170btyes的pcap文件包含ipv4通信數據。作為借鑒，以下為我們通過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實例，你可以使用密鑰對通過SSH進行通信。
3. 模糊測試階段
接下來，我們可以通過scff-ctrl . bootstrap命令對將用于模糊測試的機器進行設置。一旦設置完成，正式的模糊測試便開始。sCFF提供了單模Fuzzing和分布式Fuzzing。在單模Fuzzing下，每個實例都會單獨運行模糊測試工具;分布式Fuzzing，雖然同樣每個實例運行一個模糊測試工具，但模糊測試數據會在實例間共享，這樣可以提升測試速度。如果你擁有兩個以上的實例，我們推薦使用分布式Fuzzing模式，以scff-ctrl . distributed指令啟動分布式模式。如果想要了解模糊測試的狀態，我們可以通過瀏覽器進行查看。
你可以使用scff-ctrl . grab-findings命令隨時下載導致這些崩潰的文件。
4. 測試完成后
運行scff-exploitcheck命令可以對這些崩潰文件進行分析，誤判和重復出現的崩潰信息將會被過濾，最后剩下的信息將會用于漏洞的檢測和利用。
如果信息中有紅色EXPLOITABLE標簽，那么這里存在漏洞的可能性就非常高了。再用gdb對所發現的內容進行檢測。如下圖，tcpdump 4.9的文件printsl.c中存在一個可利用的漏洞。
經過進一步的調試，我們可以得知dir為255，并且dir也是lastlen中的指針(定義為lastlen[2][255])，這里存在參數越界，進而導致程序崩潰。
為了修復這個錯誤，我們要么調整dir的值，要么檢查dir的值是否在0和2之間。在dir = p[DIR_SLX]后面設置一個斷點，然后在gdb中修改該值(例如0,p=0)
再對源代碼進行編譯，之后檢查程序是否還會崩潰。
四、總結
由于該漏洞需要用戶使用-e參數來打開pcap文件才可以完成攻擊，危害并不是特別嚴重。
當我將該漏洞報告給tcpdump安全團隊，他們的響應速度的確稱贊，該漏洞已在4.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
