挖掘漏洞的高級方法和思維（Part.2）

執行什麼活動？

在分析一個應用程序時，我使用了下面的四種「分析模式」，每當我遇到困難時，就不斷地從一種模式切換到另一種模式。這不是一個線性或周期性的過程。我不確定這個模型是否詳盡無遺，但確實可以幫助我保持跟蹤覆蓋面。

在每種模式下都有主動和被動的活動。主動活動需要與應用程序或其環境進行某種程度的交互，而被動活動則不需要。也就是說，劃分的邊界並不總是清晰的。每個活動的目的如下：

1. 理解有關安全性的假設。

2. 假設如何破壞他們。

3. 試圖破壞他們。

用例分析是指了解應用程序做了什麼，以及它服務的目的。這通常是我負責新應用程序時要做的第一件事。與應用程序的工作版本交互以及讀取一些高級文檔有助於鞏固對其特性和預期邊界的理解。這有助於更快地生成測試用例。如果我有機會要求內部文檔（威脅模型，開發人員文檔等），我總是會試圖這樣做，以便得到更透徹的理解。

這可能不如深入探索測試用例那樣有趣，但它為我節省了大量的時間。我可以講的一個例子就是Oracle Opera，通過閱讀用戶手冊，我能夠快速找出哪些資料庫表存儲了有價值的加密數據（而不是一一瀏覽）。

實現分析是了解應用程序駐留的環境。這可能包括在被動級別檢查網路和主機配置，並在主動級別執行埠或漏洞掃描。

這種示例可能是一個安裝的系統服務的可執行文件具有ACL，允許低特權用戶修改它（從而導致本地許可權升級）。另一個例子可能是一個Web應用程序，它在同一主機上有一個暴露的匿名FTP伺服器，這可能導致源代碼和其他敏感文件的泄露。這些問題不是應用程序本身固有的，而是如何在其環境中實現的。

通信分析是了解目標與目標如何與其他進程和系統交換信息。通過監視或主動通過不同入口點發送精心製作的請求，並檢查響應是否產生了不安全的狀態，就可以找到漏洞。許多Web應用程序漏洞都是通過這樣的方式找到的。網路和數據流圖（如果有的話）對於全面了解情況非常有幫助。

雖然對這種模式需要了解特定於應用程序的通信協議，但對應用程序內部工作的理解則不然。在這種分析模式下，用戶影響的數據如何在系統中傳遞和轉換，或多或少被視為黑盒測試，重點在於監視和發送請求，並分析出現的響應。

如果我們回到我們早些時候假設的金融門戶網站，我們就可能會想看看允許客戶以不同貨幣購買預付信用卡的功能。假設一個購買請求接受了以下參數：

· fromAccount：花費資金購買預付卡的賬戶。

· fromAmount：fromAccount（例如100）賬戶的貨幣存入卡片的金額。

· cardType：要購買的卡類型（例如USD，GBP）。

· currencyPair：fromAccount和cardType的貨幣對（例如CADUSD，CADGBP）。

我們可能要做的第一件事是發送一個標準的請求，以便我們知道一個正常的響應應該看起來像一個基線。從CAD帳戶購買$82美元的卡的請求和響應可能如下所示：

我們可能不知道在幕後發生了什麼，但是狀態屬性status的結果是OK。現在，如果我們將fromAmount調整為負值，或將fromAccount調整為別人的賬戶，那麼可能會返回錯誤的響應，指示正在執行驗證。如果我們將currencyPair的值從CADUSD更改為CADJPY，我們將看到toAmount從82.20更改為8863.68，而cardType仍然是USD。通過使用更有利的匯率，我們就能夠獲得更大的回報，而期望的卡類型保持不變。

如果我們能夠訪問後端代碼，就可以更容易地知道用戶輸入中發生了什麼，並提出更徹底的測試用例，從而可以更精確地觸發安全漏洞。也許在客戶端上沒有暴露的另一個請求參數可能以潛在的惡意方式改變了預期的行為。

代碼和二進位分析是為了理解用戶影響的輸入是如何在目標應用程序中傳遞和轉換的。借用「實用惡意軟體分析」中的類比，如果最後三種分析模式可以與屍體解剖過程中的外觀進行對比，那麼這種模式就是解剖開始的地方。

有多種可以進行靜態和動態分析的活動。這裡有幾個：

· 數據流分析。這對偵察入口點和了解數據如何流向潛在的不安全狀態非常有用。當我在通信分析的背景下試圖讓有效負載工作時，我會以不同的方式調整它以嘗試去達到這個虛擬的不安全狀態。與這種模式相比，我可以先檢查一下這個不安全的狀態是否真的存在，如果是的話，找出如何製作我的有效載荷以更精確地到達那裡。如前所述，這種模式的好處之一是能夠找到不安全的狀態，並能夠向後工作，為相應的入口點製造有效載荷。

· 導入分析。通過分析導入的API，可以深入了解應用程序的功能以及與操作系統的交互方式，特別是在沒有更多上下文的情況下。例如，使用了加密函數可以說明某個資產被加密保護。你可以追蹤函數調用以確定它正在保護的內容以及是否正確保護。如果程序正在創建一個進程，你可以查看確定用戶輸入是否可以影響該進程。了解軟體如何與操作系統進行交互可以讓你了解可用於與之交互的入口點（例如，網路監聽器，可寫文件，IOCTL請求）。

· 字元串分析。與分析導入的API一樣，字元串可以提供對程序功能的一些了解。我傾向於尋找諸如調試語句，key/token之類的東西，以及任何看起來可疑的東西，它不符合我期望程序的功能。有趣的字元串可以追溯到他們的用法，並查看是否有從入口點可到達的代碼路徑。區分作為核心程序一部分的字元串和作為靜態導入庫一部分的字元串是很重要的。

· 安全掃描分類。自動化的源代碼掃描工具可能有助於尋找通用的低級漏洞，但在尋找基於上下文或基於設計的漏洞時幾乎沒有用處。由於存在大量的誤報，我通常不會覺得這是最有效的用途，但是如果它產生了很多已確認的漏洞，那麼可能說明安全編碼實踐的實際情況比較糟糕。

· 依賴分析。這涉及到對可利用的已知漏洞的依賴關係（例如，開源組件）進行分類，或者找到在目標應用程序的上下文中可以利用的公開未知的漏洞。現代的大型應用程序通常建立在許多外部依賴項上。它們中的一個子集可能存在漏洞，這些漏洞的一個子集可能會「冒泡」到主應用程序並通過入口點被利用。常見的例子包括Heartbleed，Shellshock和各種Java反序列化漏洞。

· 存儲庫分析。如果你有權訪問代碼存儲庫，則可能有助於確定研究人員通常感興趣的領域。除了具有比二進位更豐富的上下文以外的好處，這種方式更容易找到舊的代碼區域，這些代碼在很長一段時間內並沒有改變，而這些領域中的代碼將橋接分段組的開發工作。

代碼和二進位分析通常需要比其他模式要花費更長的時間，並且可以說更加困難，因為研究人員經常需要將應用程序和技術理解為與開發人員幾乎相同的程度。在實踐中，這些知識通常可以分散在不同的開發團隊之間進行分配，而研究人員需要從整體上對其進行有效的理解。

我不能誇大在這方面編程的能力是多麼重要。一個能用他們的目標應用技術編程的研究人員幾乎總能更好地提供更多的價值。在攻擊方面，發現漏洞變得更加直觀，並且更容易適應多種環境的漏洞。在防禦方面，可以提供非泛型的補救建議，以針對代碼級別上的脆弱性的根本原因。

與知識領域相似，將這種分析模式與其他方法結合起來有助於使事情進行的更加快速，並增加發現漏洞的可能性。

其他的思想和經驗教訓

本節將介紹一些值得一提的其他想法，這些想法在以前的章節中可能不太容易適用。

漏洞複雜性

漏洞的複雜性各不相同。一方面，存在一些微不足道的漏洞，這些漏洞在高度易於審查的領域（例如經典的SQLi身份驗證繞過）中使用了直觀的漏洞利用代碼。在另一方面的結果是預料之外的系統之間的相互作用的元素，通過自己既不安全也不嚴重的工程，但導致漏洞的時候卻是連在一起的（如克里斯DOMAS」記憶天坑」）。我傾向於區分光譜兩端的「一階脆弱性」和「二級脆弱性」，但可能有不同的方法來描述它們。

現代的漏洞已經不是單一的漏洞了。它們往往是一連串的漏洞，加起來就是一個完整的系統入侵。

在團隊中工作

向你的團隊介紹你所知道的和不知道的事情通常是很有幫助的，這樣你就可以在你的專長領域委派任務（理想情況下），同時也有機會在弱領域得到成長。假裝和含糊是適得其反的，因為知道得更好的人會很容易地嗅出這種心理。如果誠實才能成為政治，那麼也許這不是一個理想的團隊合作。另一方面，你不應該指望你所知道的一切都能得到滿足。學習如何獨立學習可以幫助你變得自立，並幫助你的團隊提高工作效率。

在定時項目中，團隊的組成可能是發現漏洞數量和質量的決定性因素。根據項目的規模和持續時間，有更多的分析師可能會更快的拿到結果，或導致額外的開銷，併產生適得其反的效果。我一直以來最好的項目團隊的一個顯著特點是，除了良好的關係和溝通之外，我們還有不同的技能，它們相互作用，增強了我們的個人能力。

我們還被委託了可以並行的任務，這些任務已經結合在一起。這裡有些例子：

1. 鮑勃搜尋入口點和他們的參數，而愛麗絲尋找易受攻擊的sink。

2. 愛麗絲將有效載荷填充到易受攻擊的接收器中，而鮑勃將接收器的協議轉化為接收器的相應入口點。

3. 鮑勃通過動態分析客戶端請求來反轉結構，而愛麗絲則通過分析如何靜態接收它們來做出貢獻。

4. 鮑勃在網路上查找可訪問的文件共享，而愛麗絲通過它們查找有價值的信息。

總的來說，在團隊中工作可以提高工作效率，但要做到這一點需要一些努力和遠見。重要的是知道何時添加成員不會產生生產力，以避免開銷。

最後的筆記

感謝你抽出寶貴的時間閱讀本文。我希望這在你挖掘安全漏洞時能夠解決一些疑惑。進行研究時有挫敗感，這是很正常的事情（我不認為會消失）。這是一個不斷學習的過程，它超越了可以教你一天的工作或任何單一的資源。我鼓勵你自己嘗試事物，並學習其他人如何處理這個問題，這樣你就可以聚合、組合併將每個元素合併到你自己的方法中。

本文翻譯自：http://jackson.thuraisamy.me/finding-vulnerabilities.html ，如若轉載，請註明原文地址： http://www.4hou.com/info/news/8397.html 更多內容請關注「嘶吼專業版」——Pro4hou

推薦閱讀：