前言

說到安全就不能不說漏洞，而說到漏洞就不可避免地會說到三座大山：

?漏洞分析?漏洞利用?漏洞挖掘

從筆者個人的感覺上來看，這三者盡管通常水乳交融、相互依賴，但難度是不盡相同的。本文就這三者分別談?wù)勛约旱慕?jīng)驗和想法。

漏洞分析

漏洞分析相對簡單，通常公開的漏洞中就有一兩句話描述了漏洞的成因，自己拉代碼下來看也就能了解個大概。對于一些自己發(fā)現(xiàn)的bug，從崩潰日志中一般也能比較輕松地進(jìn)行復(fù)現(xiàn)和調(diào)試。盡管有的bug排查起來相對繁瑣，但總歸是可以一步步減少范圍鎖定最終目標(biāo)的。因此，網(wǎng)上對于漏洞分析的文章很多，一方面分析起來有跡可循，另一方面分析的漏洞也不一定是自己的“原創(chuàng)”漏洞，素材來源更加廣泛。

漏洞分析雖然簡單，卻是每個安全研究人員的必經(jīng)之路。就像練武中的扎馬步、站梅花樁一樣，是日積月累的基本功。之前研究內(nèi)核時有段時間熱衷于寫漏洞分析的文章，后來隨著日漸熟練，寫文章記錄的速度已經(jīng)遠(yuǎn)遠(yuǎn)跟不上分析的進(jìn)度，所以現(xiàn)在往往懶得動筆了。

基本功必不可少，但扎馬步扎得再穩(wěn)也不表示你能獨步武林。有大佬曾經(jīng)說過，如果他想的話，可以一天寫好幾篇分析文章還不帶重樣的。畢竟，漏洞分析的目的是為了學(xué)習(xí)、吸收、轉(zhuǎn)化，以史為鑒，最終形成自己獨到的理解。

漏洞利用

漏洞利用就相對復(fù)雜一點，尤其是對于二進(jìn)制漏洞，成功的利用需要精巧的內(nèi)存布局，因此需要對程序涉及到的數(shù)據(jù)結(jié)構(gòu)要相當(dāng)?shù)牧私狻６也⒉皇撬新┒炊寄苻D(zhuǎn)換為有效利用的，一般比較容易編寫利用的漏洞，我們稱之為品相好。對于品相不好的漏洞，我更喜歡將其稱之為bug。當(dāng)然也有人認(rèn)為 bug 至少造成了程序崩潰，所以可以算一個DoS(拒絕服務(wù))漏洞。

當(dāng)然漏洞能否利用其實也是和人有關(guān)。對于復(fù)雜的系統(tǒng)，你認(rèn)為無法利用的漏洞，大佬就能以一種你沒想到的方式利用成功。比如安卓CVE-2019-2025(水滴)^[1]漏洞，屬于Binder中的一個條件競爭，競爭窗口只有幾條匯編指令。漏洞品相相當(dāng)不好，連CVSS給出的可利用分?jǐn)?shù)(Exploitability Score)也只有1.8分，但360的大佬們也通過玩弄調(diào)度器進(jìn)行穩(wěn)定利用提權(quán)了。

因此，關(guān)于漏洞利用的文章也就少了很多。一方面處于負(fù)責(zé)任披露安全問題的考慮，安全研究人員不會給出完整的利用細(xì)節(jié)，以免腳本小子濫用；另一方面對于公開的利用，你也總不能跟著寫一篇文章灌水，畢竟利用思路很多時候是因人而異的，過于雷同就難免有炒冷飯的嫌疑，除非有一些獨到的思考補(bǔ)充，或者有新的利用思路。

很多時候漏洞利用的文章看著看著就變成了漏洞利用分析的文章，這也說明了漏洞利用難度頗高，能獨立寫出原創(chuàng)利用并進(jìn)行分享的人不多。就我的感覺而言，漏洞利用更像是另一種形式的軟件開發(fā)，首先通過漏洞構(gòu)造原語，然后通過原語實現(xiàn)最終的利用程序。

漏洞挖掘

漏洞挖掘可以說是安全研究人員向往的高地之一，不管你分析了多少漏洞，寫了多少利用，如果你沒有自己挖掘出過原創(chuàng)的漏洞，那你的安全研究生涯就是不完整的。但是漏洞挖掘這事兒并不是確定性的。漏洞分析只要有漏洞肯定能分析清楚，只不過是時間問題；漏洞利用只要不是明顯的無法利用，那至少也存在利用成功的可能性。

漏洞挖掘則不然，即便你盯著某個應(yīng)用使勁挖，也不能保證有結(jié)果，說不定對方根本就沒有能觸發(fā)的漏洞。都說世上沒有絕對安全的系統(tǒng)，但是相對安全的系統(tǒng)一抓一大把，至少在出問題之前，你是不知道的。

我們能看到各種安全會議中介紹各種新發(fā)現(xiàn)的漏洞和問題，網(wǎng)上也有很多相關(guān)的文章，但更多是炫技式分享(show-off)，很少有分享怎么挖洞的。因此筆者就先拋磚引玉，談?wù)勛约旱南敕ā?/p>

Fuzzing

自從 AFL 橫空出世之后，當(dāng)今漏洞挖掘言必稱 Fuzzing，仿佛這是李云龍他娘的意大利炮，不管三七二十一先來上一發(fā)就能轟出幾個 0day。當(dāng)然，我不是說 Fuzz 不好，只不過凡事都有其誕生和得以應(yīng)用的環(huán)境。

Fuzzing 即模糊測試，在早期是 QA 測試中的一項黑盒測試技術(shù)，通過隨機(jī)變異的輸入來測試程序的魯棒性。在程序的崩潰被用于漏洞利用后，也就一躍成為一種漏洞挖掘方法。隨機(jī)變異輸入的效率相對低下，可能變異了半天連 main 函數(shù)里第一個 if 都沒有跳進(jìn)去。AFL 率先提出并實現(xiàn)了根據(jù)路徑/覆蓋率等反饋來進(jìn)行輸入的變異，從而大大提升了測試用例的有效性。

自從 2013 年 AFL 提出以來，各類 Fuzzer 百花齊放，在學(xué)術(shù)上有了爆發(fā)性的論文增長；開源社區(qū)有 honggfuzz^[2]、libFuzzer^[3] 等優(yōu)秀的項目；在工程上有 OSS-Fuzz^[4] 利用龐大機(jī)器集群進(jìn)行持續(xù)測試的應(yīng)用和 syzkaller^[5] 這種年均發(fā)現(xiàn)幾千內(nèi)核漏洞的工具等。

從產(chǎn)出的漏洞數(shù)量來看，F(xiàn)uzzing 作為一種漏洞挖掘方法可謂一騎絕塵。當(dāng)時，隨著時間的推移，通用模糊測試策略已經(jīng)越來越難發(fā)現(xiàn)新的漏洞，要么你有獨特的測試語料，要么你有領(lǐng)先的運(yùn)算資源。因此，一部分人就從通用 Fuzzer 轉(zhuǎn)回到了針對特定目標(biāo)變異的 Fuzzer(即 Structure Aware Fuzzer)。也就是說，只針對目標(biāo)程序接受的數(shù)據(jù)類型進(jìn)行特定變異，比如針對 PDF 文件格式每個字段變異等等。

別忘了，AFL 這種通用 Fuzzer 的出現(xiàn)，就是為了實現(xiàn)一次編碼，到處 Fuzz 的目的；而針對不同目標(biāo)去寫 Fuzzer，顯然有違初衷。另外，如果目標(biāo)接受的是已知格式的輸入還好，對于未知格式，還需要自己去分析和理解各個字段含義。在閱讀代碼和理解代碼邏輯的過程中，目標(biāo)程序的潛在問題很可能已經(jīng)出現(xiàn)在你眼前了，再去編寫一個不能復(fù)用的 Fuzzer，顯得有些多此一舉。這種發(fā)現(xiàn)漏洞的方法也就是下節(jié)所說的——代碼審計。

代碼審計

代碼審計，俗稱看代碼。有的人用 SourceInsight 看，有的人用 VIM 看，但不管怎么樣還是用眼睛看。既然大家都長了兩只眼睛，為什么有的人就能一個月看出十幾個高危，有的人就只看了個寂寞？

看代碼也是有方法的。雖然我比較想聽聽 @oldfresher 是怎么看代碼的，但他似乎不太愿意分享，所以我只能說說自己的方法。

要挖漏洞首先要對漏洞進(jìn)行分類，大致可以分為下面三種:

?設(shè)計漏洞?實現(xiàn)漏洞?操作漏洞

所謂設(shè)計漏洞就是軟件設(shè)計過程中就存在邏輯問題，比如 WiFi 的 WEP，設(shè)計的問題往往是比較嚴(yán)重的，而且修復(fù)周期長，所幸這類問題不是太多；實現(xiàn)漏洞就是我們常見的軟件漏洞，內(nèi)存溢出、UAF、條件競爭等都算在里面；操作漏洞和實現(xiàn)漏洞往往類似，只不過更多是指配置錯誤而產(chǎn)生的漏洞，比如 nginx 配置錯誤導(dǎo)致的目錄穿越問題就屬于一種操作漏洞。

明確漏洞類型后也不是馬上開始看代碼，而是先進(jìn)行初步的攻擊面分析，也就是常說的威脅建模。主要分為下面幾步:

?信息收集: 收集所有相關(guān)的資料，尤其是設(shè)計文檔或者幫助手冊等?應(yīng)用架構(gòu)建模: 列舉應(yīng)用所含的組件以及狀態(tài)機(jī)，注意各個組件之間隱含的信任關(guān)系?威脅鑒定: 在各個流程中列舉潛在的攻擊點，并分別標(biāo)記危害等級?審計計劃: 按優(yōu)先級對實現(xiàn)的審計計劃進(jìn)行排序

代碼審計聽起來是個讓人退縮任務(wù)，因為你面對的是一堆你不熟悉的代碼，而且要求你快速地建立起自己的理解而且找到其中最深層的秘密(安全漏洞)。通常你不會有足夠的時間審計項目的每一行代碼，因此這其中的一個重點就是懂得如何分配精力，在最可能出現(xiàn)安全問題的代碼中達(dá)到滿意的審計覆蓋率。

成功的代碼審計過程一定是務(wù)實、靈活且面向結(jié)果的。雖然講究方法，但并不意味著根據(jù)別人的方法就能成功。與很多人的認(rèn)知不同，代碼審計其實是一件需要創(chuàng)造力的技能。那位說了，看別人代碼要什么創(chuàng)造力？要在應(yīng)用中找到漏洞，審計者需要將自己代入作者的思維中理解代碼，同時還需要跳出作者的思維，洞察到原作者沒有預(yù)料到的可能性；這種技能與知識相對，像是騎車、游泳、彈琴一樣，是需要通過學(xué)習(xí)和練習(xí)去掌握的，而一旦掌握就像本能的一部分難以忘記。當(dāng)然代碼審計也有知識的部分，比如需要了解各種漏洞類型和場景等。

這些都這只是代碼審計中的冰山一角，篇幅原因無法面面俱到。比如代碼審計策略的抉擇，是深度優(yōu)先還是廣度優(yōu)先(看到某個函數(shù)調(diào)用是否需要追進(jìn)去看)；以及使用現(xiàn)代的靜態(tài)分析工具來輔助審計，比如 Fority、CodeQL 等，后續(xù)有時間再單獨進(jìn)行介紹吧。

后記

漏洞分析是技術(shù)，漏洞利用是藝術(shù)，漏洞挖掘是法術(shù)。關(guān)于漏洞利用和漏洞挖掘哪個“技術(shù)含量”更高，還存在一定爭議，但漏洞分析的基礎(chǔ)地位毫無疑問。技術(shù)可以學(xué)，藝術(shù)可以練，法術(shù)呢？其實同樣也可以通過練習(xí)提高自己的 漏洞挖掘水平。推薦一個忘了是什么地方的議題中提供的方法(也許是 CCC):

1.找到公開的漏洞通告，根據(jù)標(biāo)題的內(nèi)容自己去相關(guān)模塊中審計看是否能發(fā)現(xiàn)該漏洞2.如果發(fā)現(xiàn)不了，就回頭接著看漏洞通告的細(xì)節(jié)，反思自己的審計方法3.不斷重復(fù)，直到讓自己可以認(rèn)為找漏洞只是時間問題而不是能力問題

任何行業(yè)都沒有捷徑，你看到的所謂魔法，很可能只是某人在某些事情上付出了你意想不到的時間。最后借用一句諺語作為結(jié)尾吧:

Ever tried. Ever failed. No matter.

Try again. Fail again. Fail better.

共勉。

引用鏈接

[1] CVE-2019-2025(水滴): hhttps://nvd.nist.gov/vuln/detail/CVE-2019-2025
[2] honggfuzz: https://github.com/google/honggfuzz
[3] libFuzzer: https://llvm.org/docs/LibFuzzer.html
[4] OSS-Fuzz: https://github.com/google/oss-fuzz
[5] syzkaller: https://github.com/google/syzkaller