Fuzz 私有協定的經驗分享

本文講的是<b>Fuzz 私有協定的經驗分享</b>，

介紹

作為一名安全顧問，我們常常需要對我們客戶的應用程式進行黑盒安全測試。而在通常情況下，我們所評估的對象都是那些使用自己的私有方案來進行通信的應用程式，而不是依賴于那些正常協定（如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的步驟：

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

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

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

結論

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

原文釋出時間為：2017年7月31日

本文作者：魯班七号

本文來自雲栖社群合作夥伴嘶吼，了解相關資訊可以關注嘶吼網站。

<a href="http://www.4hou.com/technology/5745.html" target="_blank">原文連結</a>