挖洞過程中碰到死結/死循環時，該怎麼辦？

前言

我會在本文中把平時在應用程序中發現漏洞的方法，例如屬於軟體安全漏洞，而不是配置錯誤或補丁管理問題等一些技巧和大家一起分享。

本文分三大部分，我將首先回顧一下我認為比較高水平的挖漏洞方法，然後討論在尋找安全漏洞時需要了解和執行的內容。最後，我將討論一些其他的挖漏洞思想和經驗，這些方法並不常見。

什麼是漏洞發現過程?

從某種角度來說，漏洞發現過程可以被比作發現迷宮的出口一樣。

1.你不會立刻看清楚迷宮的的全貌；

2.通過探索逐漸看清全貌；

3.有多個位置並不確定的起始點和端點；

4.雖然最終你並不會100%搞明白迷宮的全部地圖，但從迷宮走出去是不成問題的。

轉換成挖漏洞的思維就是:

1.枚舉入口點即與應用程序交互的方式；

2.想一想應用程序會在哪裡出現不安全的狀態即漏洞；

3.使用指定的入口點操作應用程序，看是否會出現不安全的狀態。

在這個過程中，迷宮就好比是應用程序，地圖是你對它的預期理解，起點是你的入口點，終點是你發現不安全的狀態。

入口點可以是UI中明顯可修改的參數，也可以是對最終用戶來說比較模糊或透明的交互(例如IPC)。對於安全研究員來說，還有一些更有趣的入口點:

1.老舊代碼區域，例如，從遺留系統中過渡的痕迹；

2.劃分團隊或個人，例如互操作性的開發工作的交叉部分；

3.調試或測試代碼，這些代碼被從開發部門帶到實際運行中；

4.客戶機調用的api與伺服器公開的api之間的差別；

5.不打算受到最終用戶直接影響的內部請求，例如FormField對象所組成的集合。

我所考慮的漏洞類型可以分為兩類:普通型和上下文型。一般的漏洞，例如，RCE、SQLi、XSS等，我通常可以在不了解其業務邏輯的情況下在許多應用程序中找到漏洞。而上下文漏洞，如未經授權的設備暴露或篡改，則需要更多的業務邏輯、信任級別和信任邊界規則的知識。

我的經驗是，優先考慮什麼會對利益相關者產生最大的影響。而利用輕量級的威脅模型，如一種基於STRIDE威脅模型，也可以幫助弄清楚到底出了什麼問題。

以下是一個web應用程序示例，以及一個桌面應用程序示例。

假設這個應用程序是一個金融門戶網站的單頁Web應用（single page web application，SPA），我已經對它進行了驗證，但是沒有伺服器端源代碼或二進位文件。當我在枚舉入口點時，我可以探索站點的不同特性，以了解它們的運行目的，看看我的HTTP代理中有哪些請求，並將一些清晰的信息組合成初步的地圖。我還可以查看客戶端JavaScript，以獲取SPA所調用的RESTful api的列表。沒有伺服器端代碼的一個限制是，我不能看到由SPA調用的api和由伺服器公開的api之間的差別。

然後可以操縱被識別的入口點，試圖到達我正在尋找的不安全的狀態。當我考慮到表面的漏洞時，我應該構建適合應用程序的技術堆棧和業務邏輯的測試用例列表。如果沒有，我就會去嘗試那些永遠無法工作的測試用例(例如，當後端使用Postgres時，嘗試使用xp_cmdshell)，而不需要對應用程序進行更深入的了解(例如，在外匯請求的貨幣參數中找到驗證差距)。

在桌面應用程序中，通過確定的入口點來尋找漏洞的基本過程仍然適用，但也有一些不同之處。與web應用程序最大的不同之處在於，它需要一組不同的主題知識和方法來執行。前10 位「OWASP」工具將不會有多大幫助，將應用程序連接到一個HTTP代理來檢查網路流量可能不會產生同樣的運行水平。這是因為入口點更多樣化，包含了本地向量。

與黑盒方法相比，當你訪問源代碼時，不確定性會少一些。特別是在針對弱的代碼路徑和效載荷方面。你可以從一個脆弱接收器(Sink)開始，然後倒著到達一個入口點，而不是通過一個入口點來發送有效載荷。而利用白盒方法，你會受到固定思維的限制。

挖漏洞需要具備哪些知識?

漏洞研究所需的知識是廣泛的、隨時間變化的，並且根據應用的類型不同而有所不同。然而，知識的領域往往保持不變，可以分為四種:

1.應用程序的技術：也就是說開發人員應該知道如何構建目標應用程序的技術，包括編程語言、系統內部構件、設計範例或模式、協議、框架或庫等等。如果一個研究人員擁有與他們的目標相適應的經驗，則更好。

2.進攻和防禦的概念：從基本的安全原則到不斷演變的技術，進攻和防禦概念的結合可以引導研究人員發現漏洞，同時繞過漏洞。

3.工具和方法：要有效地將概念付諸實踐，就要花時間學習如何使用工具並配置它們，優化重複的任務，建立你自己的工作流程。了解相關的工具是如何工作的，如何開發它們，以及如何為不同的用例重新設計它們非常重要。

面向過程的方法比以工具為導向的方法更有價值，當使用的工具被限制時，研究人員不應該停止探索。我的方法主要來自於閱讀書籍並親自動手實踐，以及在不斷地試錯中學習。

4.目標應用程序：重要的是能夠更好地理解應用程序的安全屬性，而不是它的開發和維護。這不僅要考慮應用程序的安全特性，還涉及到獲取其用例的上下文，枚舉所有入口點，並能夠假設適合其業務邏輯和技術堆棧的漏洞。

下面的表格展示了一個示例，說明了在web應用程序和Windows桌面應用程序中研究漏洞所需要的知識。

為了獲得這些知識，我花了成千上萬個小時，遭遇了幾百次錯誤，無數個不眠之夜。這些知識領域能極大的增加挖到漏洞的可能性。

執行的是什麼活動?

在分析應用程序時，我使用了下面的四種「分析模式」，每當我遇到困難時，就會不斷地從一種模式切換到另一種模式。這不是一個線性或循環的過程。我不確定這個模型是否詳盡，但它確實能幫助我進行跟蹤。

每個模式中都包含了主動和被動的活動，主動活動需要與應用程序或其環境進行一定程度的交互，而被動活動則不需要。也就是說，描述並不總是明確的，每個活動都有其目的:

1.了解有關安全性的假設；

2.假設如何破壞他們；

3.試圖破壞他們。

用例分析是了解應用程序的用途以及它服務的目的，這通常是我在新申請的時候做的第一件事。與應用程序的工作版本進行交互並閱讀一些高級文檔有助於鞏固我對其特性和預期邊界的理解，這可以幫助我更快地提出測試用例。另外，我會盡最大可能請求內部文檔(威脅模型、開發人員文檔等)以便獲得更全面的理解。

這可能不像做深度用例測試那樣有趣，但該方法確實為我節省了很多時間。比如Oracle Opera示例，通過閱讀用戶手冊，我能夠快速發現哪些資料庫表存儲了有價值的加密數據。

實現分析（Implementation analysis）是用於理解應用程序所在的環境的，這可能包括在被動活動中檢查網路和主機配置，並在主動活動中執行埠或漏洞掃描。

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

通信分析（Communications analysis ）的目的是了解目標如何與其他流程和系統交換信息，通過監控或積極地通過不同的入口點發送精心設計的請求，並檢查響應是否產生不安全狀態，以發現漏洞，許多web應用程序漏洞都是這樣發現的。如果有漏洞的話，網路和數據流圖有助於了解到更多的信息。

雖然這種模式需要了解應用程序特定的通信協議，但是對於應用程序的內部工作原理的理解卻不是這樣的。在這個分析模式中，用戶影響的數據是如何被傳遞和轉換的，在一個系統中或多或少被視為一個黑盒方法，其重點是監控和發送請求，已進行最後的結果分析。

還是以上面假設的金融門戶為例，我可能會考慮到網站允許客戶以不同的貨幣購買預付信用卡的功能，作為一個人為操作的例子。假設購買請求採用的是以下參數:

1. fromAccount：取款的賬戶，用來購買預付卡；

2. fromAmount：獲取賬戶的金額；

3. cardType：購買的信用卡類型，如USD，GBP；

4. currencyPair：fromAccount和cardType的貨幣對(如CADUSD,CADGBP)。

我要做的第一件事就是發送一個標準請求，這樣我就知道了正常響應應該是什麼樣子的。如下所示，就是從一個CAD帳戶購買82美元的信用卡的請求和回應:

雖然我可能不知道幕後到底發生了什麼，但它是由狀態屬性指定的。現在，如果我將fromAmount更改為負數，或者將fromAccount調整到另一個人的帳戶，則這些返回指示可能正在執行驗證的錯誤響應。如果我將CADUSD到CADJPY的currencyPair的值進行修改，我將看到toAmount的範圍從82.20到8863.68，而cardType仍然是USD。我可以通過使用更有利的匯率來獲得更大的回報，而設定的卡片類型保持不變。

如果我能夠訪問後端代碼，就可以更容易地知道用戶輸入了什麼，並提出了更徹底的測試用例，從而更精確地尋找到不安全的狀態。我猜測，客戶端沒有公開的另一個請求參數可能會以潛在的惡意方式改變預期的行為。

代碼和二進位分析能幫助我理解對用戶影響的輸入是如何在目標應用程序中進行傳遞和轉換的，通過對實際的惡意軟體進行分析，我發現如果把最後三種分析模式比作外部的分析，那麼這種模式就是內容分析的開始。

靜態和動態分析可以執行各種各樣的挖漏洞活動：

1.數據流分析：這對於監控入口點和了解數據如何流向潛在的不安全狀態非常有用，當我試圖在通信分析的環境中獲得有效載荷時，我會用不同的方式來嘗試去實現我所假設的不安全狀態。我可以先檢查一下這個不安全的狀態是否確實存在，如果存在，弄清楚如何使我的載荷更精確地到達那裡。正如前面所提到的，這種模式的好處之一是能夠找到不安全的狀態，並能夠通過倒推獲得相應的入口點的載荷。

靜態和動態分析在這裡是緊密相連的，如果你想從入口點到達不安全的狀態。那麼靜態分析就像閱讀地圖一樣，動態分析就像是對交通和天氣狀況進行實時分析一樣。從靜態分析中得到的應用程序的廣泛而抽象的理解，可以通過動態分析具體化。

2.進口分析（Imports analysis）：分析導入的api可以深入了解應用程序的各個函數以及它如何與操作系統交互，特別是在上下文缺失的情況下。例如，使用加密函數可以表明某些有價值的東西正在受到保護。你可以通過追蹤交互信息來弄清楚它在保護什麼，以及它是否受到了適當的保護。如果創建了一個流程，你可以查看用戶輸入是否可以影響它。了解該軟體如何與操作系統交互，這可以為你提供與它交互的入口點(例如，網路監聽器、可寫文件、IOCTL請求)。

3.字元串分析：在分析導入時，字元串可以對程序的功能提供一些見解。我傾向於尋找諸如調試語句、密鑰或令牌之類的東西，以及任何看起來可疑的東西，因為它們都有可能在正常函數運行時出現意外。有趣的字元串可以追溯到其用法，並查看是否有從入口點可到達的代碼路徑。要注意的是，把核心程序中的字元串和作為靜態導入庫一部分的字元串區分是很重要的。

4.安全掃描診斷：自動化的源代碼掃描工具可能有助於找到通用的低級漏洞，但在發現基於上下文或基於設計的漏洞時實際上是無用的。我通常不認為這個辦法最有效，因為誤報因素的數量非常多。

5.相關分析（Dependency Analysis）：這涉及到對已知漏洞的相關分析，例如，開源組件，或者發現可以在目標應用程序上下文中使用的公開未知的漏洞。一個現代的大型應用程序通常建立在許多外部相關項之上。這些相關性的某些環節說不定就存在漏洞，這樣利用這些漏洞再間接的進入到主應用程序，並最終開發一個入口點。常見的例子包括heartUNK、Shellshock和各種Java反序列化漏洞。

6.庫的分析：如果你有訪問代碼庫的許可權，那麼這有可能有助於識別一些特別的漏洞。除了擁有比單獨使用二進位文件所帶來的好處之外，還更容易找到老代碼區域，這些代碼在很長一段時間內並沒有發生變化。

與其他模式相比，代碼和二進位分析通常花費更長的時間，這就可能會讓分析變得更加困難。因為此模式下，研究人員經常需要理解對應用程序有很深的了解。而在實踐中，這很難做到。

在進攻端，發現漏洞需更有敏銳洞察力，並且還要適應多種攻擊環境。而在防禦方面，可以提供特殊的補救建議，以針對代碼級別的漏洞。

類似與所需的知識，你可以積極地將這種分析模式與其他模式結合在一起，以便增加找到漏洞的可能性。

其他的想法和教訓

本節討論一些不常見的其它想法。

脆弱的複雜性

漏洞的複雜性各不相同，一方面，有一些很明顯的漏洞，它們能夠被輕而易舉地發現，因為這些漏洞的代碼很容易出現在常見的重點監控領域，例如經典的SQLi認證繞過。另一方面，系統元素之間沒有預期的交互作用的結果，它們本身既不安全，也沒有被特殊設計，但組合在一起時，會導致一個漏洞，例如，Intel處理器Memory Sinkhole漏洞。

通過團隊協調挖漏洞

向你的團隊坦率地介紹你所知道的和不知道的事情通常是有幫助的，這樣你就可以在專業領域上的互補。比如：

1.小明探測到了入口點和它們的參數，而阿龍則尋找到了帶有漏洞的接收器。

2.小明將有效載荷從一個脆弱的接收器中取出，而阿龍則將協議的意義放在了接收器對應的入口點上。

3.小明通過動態分析客戶機請求來恢復結構，而阿龍則分析如何靜態地接收它們。

4.小明在一個網路上尋找可訪問的文件共享，而阿龍則通過它們獲取有價值的信息。

總的來說，安全團隊可以提高工作效率，但要做到這一點很不容易。

總結

感謝你花時間閱讀這篇文章，我希望這能讓你獲得挖漏洞的靈感。總的來說，挖漏洞就是一個持續不斷的學習過程。

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

推薦閱讀：