Fuzz 私有協議的經驗分享

介紹

作為一名安全顧問，我們常常需要對我們客戶的應用程序進行黑盒安全測試。而在通常情況下，我們所評估的對象都是那些使用自己的私有方案來進行通信的應用程序，而不是依賴於那些常規協議（如HTTP）的。

最近，我們參與了一個短期的安全測試項目，測試的對象就是一個具有自己的通信協議的定製應用程序，該通信協議包裹在SSL / TLS隧道中，因此我們需要完整的去了解其安全性。

本文旨在描述我們是如何解決這一項目中所遇到的技術局限以及時間限制等問題，並通過基於變異的Fuzzing來成功測試和查找應用程序中的問題。

什麼是私有協議？

大致來說，私有協議是一種未被開放標準定義或由個人或公司控制的協議。在許多情況下，沒有關於其內部工作的官方文檔，並且其難以與使用封閉協議的應用程序通信。

簡單來說就是協議的複雜程度會有所不同，有些比其他的更複雜：例如，通常情況下給定的協議可能非常簡單 ，他們基於ASCII字元，易於理解，並且可以容易地與其他元素相關的其他欄位的消息。但也可能存在更複雜的協議。他們可能涉及不明顯的不同數據表示，二進位或序列化數據，校驗和和值欄位等。

當然儘管是私有的，有些協議還是有自己的規範文件或者由供應商提供的官方文檔（如金融交易所所使用的FIX，其被廣泛用於股票交易）或已經被技術愛好者和開源倡導者工程進行逆向的協議——這方面比較經典的例子就是AOL的即時通訊OSCAR協議。

雖然網路協議的逆向工程是完全可能的，但這毫無疑問是一個麻煩的任務，這其中涉及非常多的耐心以及高超的技能，當然最重要的還是時間。並且擁有所有這些要素也不一定就是可行的，所以我們需要一個替代方案來解決我們手頭上的問題。

自動軟體安全測試與fuzzing

fuzzing是過去幾年一直很受重視的一個領域，學術界和行業里都出現了很多先進的方法。

早期的 fuzzing技術可以大致分為變異和基於生成，儘管存在更先進和現代的方法，如進化fuzzing，利用代碼覆蓋的反饋，並藉助遺傳演算法產生更好的投入，以及其他技術的依賴開約束求解器，concolic和象徵性執行等

基於變異的fuzzing通常被稱為「啞巴fuzzing」，因為它的作用是執行輸入的隨機變異並且吐出被破壞的數據作為結果。然而，不要被它的名字所欺騙：可能看起來很笨的fuzzing可以非常有效，並且其在流行的軟體中發現過許多錯誤。

另一種流行的策略被稱為基於生成的fuzzing。這種技術涉及協議或文件格式的先前知識是fuzzed的，並且它可以生成大多數符合協議的測試用例，但是也會包含一些已知的可能導致意外行為的數據的欄位，如大字元串，包含shell元字元的惡意輸入，負數，非常長或非常正常的數字等等。

優缺點對比

基於變異的fuzzing具有快速建立的優點，因此在實際應用中可以獲得良好的效果; 然而，在實現高代碼覆蓋率（您的測試樣本將在此處發揮關鍵作用），或者在將校驗和發送到應用程序進行處理之前需要調整校驗和的情況下，可能無法實現高應用程序覆蓋率 ，因為應用程序很可能會拒絕其餘部分作為校驗和的輸入將失敗，沒有達到代碼的潛在易受攻擊的區域。

而基於生成的代碼更有可能具有更大的代碼覆蓋率，當然有所犧牲的是創建時間更長。此外，fuzzing的神奇的創造力以及變異和數據破壞啟發式的巧妙之處將決定其在查找錯誤方面的成功。

我們的經驗

很幸運的是我們處理的協議雖然是私有的，但卻是基於ASCII的，似乎並沒有太複雜。然而，考慮到時間限制，我們毫無疑問沒有辦法去選擇花費時間來了解它並創建一個基於生成的fuzzer？而且，為什麼要花費寶貴的時間呢？我們完全可以寫出我們自己的變異引擎，這不是更好嗎？

當然更為重要的一點是與協議本身有關：由於無需計算校驗和或符合其他嚴格的協議結構，因此我們選擇使用基於變異的方法進行模糊。

在這個項目中，我們拿到的都是客戶端和我們想要測試的應用程序之間的明文流量的數據包捕獲（PCAP）。

我們注意來確保我們將獲得不同功能和用途的幾個樣本PCAPs; 這樣我們可以保證我們的fuzzer會更有壓力，即在測試過程中，使得針對應用程序的可用攻擊面的不同區域，增加代碼覆蓋率以及增加我們發現錯誤的機會。

在這種情況下，客戶端和應用程序之間的所有流量都被包裹在TLS / SSL中，請求捕獲非加密流量非常重要，因為我們需要應用程序級通信，而不是傳輸或上層層流量。

另外，我們必須模糊的協議是某種狀態機：在握手消息（也可能被fuzzing）之後，它會按某種順序預期一些其他消息進行進一步處理。

這意味著如果我們發送了握手信息，並在其期望發送一個格式錯誤的消息（例如登錄消息）時，我們將無法fuzzing任何登錄信息，因為它會被拒絕。

為了解決這個問題，我們為我們的Fuzzer增加了一些更多的隨機性：PCAP中只有一定比例的有效載荷將被變異。這將給我們更多的排列和發送乾淨的握手和N-1消息的能力，但只有最後（N個消息）模糊; 或者模糊的握手和乾淨的消息，或清理握手和格式錯誤的登錄，並清除其他消息等。

工具

為了組合一個可以執行上述任務的Python腳本，我們使用了下面這些工具：

Scapy：一個庫，相當於是與網路相關的所有事物的瑞士軍刀，可以從PCAP解析，讀取，寫入和重寫數據。

radamsa：一種流行的基於變異的模糊工具，許多安全研究人員都會選擇的武器。

步驟分解

在概述了我們想要做的內容、哪種模糊策略最適合我們的案例以及該任務所需的工具後，現在是時候來粗略地分解我們用來執行應用程序的fuzzing的步驟：

步驟0：定義一個 fuzz因子 - 例如，只有20％的數據包被變異

步驟1：解析PCAP尋找客戶端 - >伺服器通信

步驟2：在捕獲的內容中，找到包含實際有效載荷的那些被人，因為PCAP有時會包含與我們目的無關的通信，例如TCP 3次握手和其他信令

步驟3：輸入無限循環：

步驟3.1：提取payload，隨機決定是否應根據fuzz因素進行模糊; 如果是這樣，將其插入變異引擎

步驟3.2：獲取變異數據

步驟3.3：向目標應用程序發送受損的payload（或清潔的payload，取決於是否fuzzed）

步驟3.4：洗滌，沖洗，重複，這樣子持續一個晚上。

步驟4：觀察崩潰並執行崩潰分類（如果適用）

事實上，第四步並不在我們的範圍內：由於從黑盒的角度出發，沒有任何手段，甚至沒有觀察到我們所需要驗證的事故。客戶端很好地驗證了自身的崩潰，我們的fuzzing腳本在發送每個受損測試用例後檢查了與目標的連接。雖然緩慢，但是給目標應用程序是否崩潰了一些可見度。

後來在整個的項目過程中，我們被客戶通知，Fuzzer觸發了四次碰撞; 其中三個是獨一無二的。我們沒有足夠的時間進行任何類型的崩潰分析，但是fuzzing的測試用例會觸發未處理的異常，並可能嚴重影響預計始終處於聯機狀態的服務的可用性。

上述步驟的開源實現可以在我們的Github中找到。這篇文章更為重要的是去說明我們的一些想法。另外示例代碼幾乎不能應用於實際的應用程序中，但通過一些修改可能適合不同的需求。

結論

即使是在最簡單的形式中，fuzzing也可能是發現漏洞的非常有用的工具，並且其應該在每個信息安全工程師的技能包中。因為其對於使用私有或非文檔化協議的應用程序，目標應用程序的不同使用形式的樣本PCAP對於測試更大的攻擊面並提高查找錯誤的可能性非常有用。另外，具有創造性和非常規啟發式的好的fuzzing引擎也是必要的，比如在我們所說的例子中其正是以變異的可能來觸發微妙錯誤並覆蓋深入到了代碼邏輯的角落。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！