面對(duì)漏洞海洋，要理清到底哪個(gè)IT安全問題應(yīng)該首先處理幾乎是不可能任務(wù)。廠商咨詢服務(wù)提供了一種行之有效的駕馭已知攻擊方法的途徑。不過，還有另一種更權(quán)宜的選擇：直接竊聽攻擊者。

鑒于越來越大的攻擊面，大多數(shù)公司都將他們的漏洞管理周期與廠商發(fā)布綁定。但安全漏洞的初始披露并不總是來自廠商，而等待官方發(fā)布有可能耗去數(shù)天甚至數(shù)周時(shí)間，讓公司企業(yè)遠(yuǎn)遠(yuǎn)落后于在漏洞冒頭數(shù)小時(shí)內(nèi)就開始討論和共享利用教程的攻擊者。

安全公司 Recorded Future 曾對(duì)外語論壇上的漏洞討論進(jìn)行過深入分析，認(rèn)為漏洞初始公開披露的24到48小時(shí)內(nèi)，黑客們通常就開始在網(wǎng)上交換意見了。

廠商資訊、博客帖子、郵件列表消息、國(guó)土安全計(jì)算機(jī)應(yīng)急響應(yīng)小組(CERT)警報(bào)——關(guān)注這些發(fā)布的不僅僅是防御者。知道哪些東西是攻擊者感興趣的，清楚他們計(jì)劃怎樣在廠商響應(yīng)之前利用漏洞，是趕在下一波攻擊涌來之前做好準(zhǔn)備的妙招。

黑客聊天

去年的Java對(duì)象序列化漏洞就是一個(gè)極佳的例子。最初，2015年1月一次會(huì)議討論上首次披露的時(shí)候，該漏洞并沒有引起重視，直到當(dāng)年11月6號(hào)，安全公司 FoxGlove Security 發(fā)現(xiàn)該問題影響到多個(gè)諸如WebSphere、JBoss這樣的核心企業(yè)應(yīng)用，人們才大驚失色。然后，甲骨文公司又花了12天才發(fā)布 WebLogic Server 的正式補(bǔ)丁；Jenkins開源持續(xù)集成引擎的補(bǔ)丁則更慢，19天后才推出。

但是，攻擊者社區(qū)，卻在數(shù)小時(shí)之內(nèi)便開始討論 FoxGlove Security 的博客帖子，概念驗(yàn)證漏洞利用代碼僅6天后便現(xiàn)身。一份詳細(xì)的漏洞利用教程在11月13號(hào)出現(xiàn)，比甲骨文動(dòng)作快了5天。在12月的第一個(gè)星期，攻擊者已經(jīng)在交易受影響企業(yè)的名稱和觸發(fā)其中漏洞的具體鏈接了。

很明顯，漏洞確認(rèn)和廠商補(bǔ)丁發(fā)布或規(guī)避方法出臺(tái)之間的時(shí)間差，對(duì)威脅行為人而言是寶貴的，但當(dāng)詳細(xì)的漏洞利用指南在多國(guó)語言論壇出現(xiàn)時(shí)，該時(shí)間差對(duì)企業(yè)而言就是災(zāi)難性的。

PHP 7 的 0Pcache 緩存引擎 Binary Webshell 漏洞，是攻擊者在攻防戰(zhàn)中領(lǐng)先一步的另一個(gè)例子。安全公司GoSecure在4月27號(hào)描述了這一新漏洞利用，僅3天后，4月30號(hào)，一份解釋如何利用GoSecure博文所述概念驗(yàn)證代碼的教程便流傳開來了。GoSecure提到，該漏洞并沒有廣泛影響PHP應(yīng)用。但隨著教程的出現(xiàn)，攻擊者可以更容易地發(fā)現(xiàn)存在危險(xiǎn)配置，可供利用文件上傳漏洞的服務(wù)器。

甚至鮮為人知的博客都會(huì)成為黑客獲取信息的來源。

對(duì)大多數(shù)人而言，GoSecure的博客無足輕重。安全報(bào)道那么多，如果在防御者社區(qū)沒有足夠影響力，帖子里討論的潛在攻擊方式是會(huì)分分鐘被忽略的。然而，另一方面，攻擊者卻在討論該漏洞，分享漏洞利用工具的信息。

等待廠商會(huì)使你更加無助

攻擊者領(lǐng)先廠商和安全專家一大步的一個(gè)原因，在于漏洞發(fā)布過程本身。

廠商通告通常在安全漏洞獲得了公共漏洞與暴露(CVE)標(biāo)識(shí)之時(shí)。CVE系統(tǒng)由MITRE公司維護(hù)，是作為公開已知信息安全漏洞中央資料庫(kù)的一個(gè)非盈利項(xiàng)目。只要有人發(fā)現(xiàn)安全漏洞，無論是應(yīng)用開發(fā)者、研究人員還是第三方代理實(shí)體，MITRE都會(huì)收到新CVE標(biāo)識(shí)的請(qǐng)求。

一旦MITRE指派了類似漏洞身份證號(hào)的漏洞標(biāo)識(shí)，安全行業(yè)、廠商和企業(yè)就可以識(shí)別、討論和共享該漏洞的細(xì)節(jié)，以便進(jìn)行修復(fù)。在初始披露并非來自廠商的情況下，比如Java對(duì)象序列化漏洞的情況，攻擊者便會(huì)比還在等CVE指派的防御者領(lǐng)先一步。

這一時(shí)間差非常關(guān)鍵。當(dāng)然，要研究、評(píng)估和緩解的漏洞太多，用以對(duì)抗漏洞的安全資源又有限，以是否獲得CVE標(biāo)識(shí)為基準(zhǔn)來過濾漏洞報(bào)告，便是一種“合理的態(tài)度”了，也會(huì)讓公司企業(yè)小心謹(jǐn)慎行事。這里面蘊(yùn)含的意思是，有CVE標(biāo)識(shí)的漏洞才是需要注意的真實(shí)漏洞。

但最近，CVE系統(tǒng)自身已成為了瓶頸。好幾個(gè)安全專家抱怨說，他們不能及時(shí)從MITRE獲取CVE。這種延遲影響巨大——如果沒有一套系統(tǒng)確保每個(gè)人指的都是同樣的問題，將很難與軟件廠商、合作伙伴和其他研究人員協(xié)調(diào)合作修復(fù)漏洞。當(dāng)前問題有部分源于規(guī)模，隨著軟件產(chǎn)業(yè)越做越大，漏洞的數(shù)量也越來越多。CVE分配上的延遲，會(huì)給攻擊者留出開發(fā)和改進(jìn)攻擊工具與技術(shù)的時(shí)間。

很多人都認(rèn)為，只要沒有CVE，便不是真正的問題。這種認(rèn)知本身便問題巨大。

另一個(gè)問題是，不是所有的漏洞都能有CVE分配，比如在服務(wù)器端更新而無需客戶互動(dòng)的Web應(yīng)用。不幸的是，需要客戶互動(dòng)來安裝更新的手機(jī)App漏洞，同樣收不到CVE。2015年共報(bào)告了14185個(gè)漏洞，比國(guó)家漏洞數(shù)據(jù)庫(kù)和CVE中報(bào)告的多了6000個(gè)。

CVE系統(tǒng)對(duì)客戶和信息安全從業(yè)者的真正價(jià)值，并不是實(shí)際衡量風(fēng)險(xiǎn)和安全影響，而是不考慮嚴(yán)重程度地分類所有已知風(fēng)險(xiǎn)。

開始監(jiān)聽吧

由于CVE沒有涵蓋每一個(gè)漏洞，你必須查看CVE以外的來源以獲得當(dāng)前形勢(shì)的整體景象。這意味著你得停止只靠廠商發(fā)布進(jìn)行漏洞管理的行為，開始探索其他信息來源以跟上最新漏洞披露。如果你的漏洞管理團(tuán)隊(duì)關(guān)注網(wǎng)上提及概念驗(yàn)證的信息，注意公司環(huán)境中漏洞利用活動(dòng)的跡象，他們的工作將會(huì)更有效。

官方廠商通告以外，還有很多公共漏洞信息可用，太多了，防御者沒辦法與全部揭露各種漏洞的博客、研究人員就某一安全漏洞的郵件列表討論，以及其他公共通告保持同步。不用試圖訂閱每個(gè)可能的郵件列表和RSS反饋，你的漏洞管理團(tuán)隊(duì)可以直接去論壇，直接聽潛在攻擊者們?cè)诹氖裁础＿@才是提前預(yù)警的正確方式。

你防不了零日漏洞，但你可以關(guān)注論壇聊天，尋找有關(guān)具體漏洞的實(shí)質(zhì)性討論，抓住那些要等幾個(gè)星期才可以從廠商處拿到指南的漏洞。

作為一家威脅情報(bào)公司，Recorded Future 希望企業(yè)采用它的平臺(tái)偵聽論壇威脅聊天，英語區(qū)或外國(guó)語言地區(qū)都有，但選擇不止它一家。企業(yè)可以選擇一堆論壇、IRC在線聊天頻道和其他在線源監(jiān)視討論。事實(shí)上，Recorded Future 分析師注意到有用戶始終在分享可被認(rèn)為是可信信息源的博客。簡(jiǎn)單地跟蹤這些“專家”的發(fā)言，有助于發(fā)現(xiàn)圍繞最新漏洞的討論。時(shí)刻關(guān)注GitHub上的分享，也能很大程度上跟進(jìn)攻擊者計(jì)劃。

威脅情報(bào)有助于降低信噪比，發(fā)現(xiàn)有用信息，但也不是找出這些在線聊天的唯一途徑。

防御者應(yīng)該關(guān)注自身網(wǎng)絡(luò)上增加的掃描活動(dòng)。掃描活動(dòng)的增加，預(yù)示著有人在討論怎樣觸發(fā)漏洞的可能性。例如，Recorded Future 就注意到，在遠(yuǎn)程代碼執(zhí)行漏洞披露之后，幾乎馬上就出現(xiàn)了針對(duì)Elasticsearch搜索服務(wù)器中Groovy腳本引擎的掃描。論壇上總有關(guān)于如何利用并持久駐留在被入侵系統(tǒng)中的討論。

遠(yuǎn)程代碼執(zhí)行漏洞很容易馬上引發(fā)在線討論。本地漏洞，就是那些需要攻擊者先在設(shè)備上拿下某種程度上的立足點(diǎn)的漏洞，則引發(fā)的討論規(guī)模往往沒那么大。