使用了很多開源軟件，但你知道怎么處理對應的漏洞嗎？

作者：Rami Sass來源：聊聊架構

盡管在 2017 年 9 月的 Equifax 遭受黑客攻擊后引發(fā)了沖擊波，但是業(yè)界在保護產(chǎn)品方面仍然有很長的路要走。一個需要關注的關鍵領域是占據(jù)現(xiàn)代應用程序整個代碼庫 60%-80% 的開源組件。讓我們來了解一下如何檢測易受攻擊的開源組件并確保產(chǎn)品的安全性。

去年 9 月，當圍繞著信用評級機構 Equifax 被黑客攻擊的新聞流傳開來時，世界上大部分的人才突然知道開源漏洞這個概念。攻擊者利用了 Apache Struts2 開源組件的一個漏洞，竊取了大約 1.479 億人的身份信息，其中大部分是美國人。

從表面上看，該公司沒有意識到其 web 應用程序中正在使用易受攻擊的開源組件，并且沒有及時打上補丁以避免受到攻擊。

盡管像 Heartbleed 這樣的黑客攻擊在短時間內(nèi)吸引了大眾的注意力，但是在本次攻擊中被竊取信息的數(shù)量和質(zhì)量范圍引起了公眾更多的關注。

這也給組織敲響了一次警鐘，他們有更大的責任來保護那些用于保衛(wèi)其用戶數(shù)據(jù)的代碼，即使這些代碼不是他們編寫的也應如此。這些代碼通常以開源組件的形式出現(xiàn)，可以免費試用，并被開發(fā)者出于及時向市場交付產(chǎn)品的目而廣泛采用。開發(fā)人員依賴開源組件提供的有用功能，如果不使用開源組件的話，他們就得自己編寫。據(jù)報道，開源組件的使用在不斷增長，Gartner 預計，在我們知道并喜愛的大多數(shù)產(chǎn)品中開源代碼占據(jù)了 80%。

然而，盡管有這些漏洞，但是開源組件的安全性仍然被太多公司忽視，他們沒有意識到這種威脅的規(guī)模，甚至沒有意識到他們真正使用的開源組件的數(shù)量。

缺乏關注的主要原因之一似乎是，這些組織無視開源漏洞是什么、它們是如何被發(fā)現(xiàn)的以及他們應該怎樣保護自己和客戶。

回到最基本的問題：什么是開源漏洞

開源中的漏洞和專有產(chǎn)品中的漏洞類似。這些代碼要么是編寫出錯導致黑客可以加以利用的，要么是允許黑客以開發(fā)人員不希望的方式執(zhí)行有害的操作。

在某些情況下，可以利用開源漏洞發(fā)起拒絕服務攻擊（denial of service，簡稱 DoS）并使服務下線，而其他更嚴重的漏洞則可能允許黑客進行遠程訪問，讓他們擁有進入系統(tǒng)的“鑰匙”。

然而，開源代碼和專有代碼之間的相似之處僅此而已。內(nèi)部代碼是由一組開發(fā)人員遵循其組織集中指導編寫出來的，而開源代碼高度分散于編寫、修復和維護項目的社區(qū)成員中。

集中控制系統(tǒng)和分布式系統(tǒng)常常被稱為大教堂（Cathedral）和集市（Bazaar）。開源代碼沒有一個獨立組織的中心設計來規(guī)劃其邏輯，并且缺乏標準化的系統(tǒng)來解決新特性的添加和修復事宜，它們遵循的是一個不同的、通常更松散的規(guī)則集，使得它們更加難以管理。

對于組織來說，涉足這個混亂的領域是很復雜的且難以掌控的，但是對于黑客們來說，開源代碼缺乏集中控制則是個福音。很多時候，開發(fā)人員會從像 GitHub 等網(wǎng)站上的眾多存儲庫中獲取源代碼，而不會去檢查組件是否存在任何已知漏洞。更糟糕的是，很少有人會在其代碼庫或產(chǎn)品中跟蹤開源代碼的解決方案。

因此，就像我們在 Equifax 的案例中看到的那樣，他們并不知道他們正在依賴易受攻擊的代碼，而且根本不知道這些漏洞的存在，因此也無法為其打補丁。跟很多開發(fā)代碼的組織一樣，Equifax 可能一直在用某個工具測試他們應用程序中的代碼，但是，很明顯，他們沒有一個為分析開源組件而構建的工具。

開源代碼的漏洞是怎么找到的？誰在尋找這些漏洞？

靜態(tài)應用程序安全測試（Static Application Security Testing，簡稱 SAST）或動態(tài)應用程序安全測試（Dynamic Application Security Testing，簡稱 DAST）這樣的安全工具知道如何與專有代碼良好協(xié)作。它們采用組織內(nèi)編寫代碼的邏輯，使用一組像白名單（Whitelist）這樣的規(guī)則來查找代碼中可能被攻擊者入侵的潛在缺陷。

然而，由于開源組件是按照不同的方式搭建的，因此這些工具對于查找漏洞來說用處不大。相反，我們要依靠大量的研究人員和社區(qū)成員，他們會花費時間在整個代碼中查找漏洞。他們沉浸于代碼之中，對代碼進行細致檢查、嘗試各種可能會使程序出錯的理論、編寫攻擊代碼，目的就是讓應用程序失去保護自己的能力。

盡管他們確實會利用一些自動化工具去找出代碼中那些容易找到的漏洞，但是，這個測試過程是一項漫長而艱巨的任務。據(jù)估計，研究人員可能平均要花 3 個月的時間才能找到一個漏洞。

從本質(zhì)上講，開源軟件是個活生生的、有生命力的實體，由一群開發(fā)人員維護，他們貢獻自己的時間以構建更好的項目。為了使項目更加健壯，很多社區(qū)成員自己花時間來尋找漏洞，當他們發(fā)現(xiàn)可能被對社會不滿者、罪犯甚至在有些情況下是國家行為者利用的代碼時，會提醒項目管理人員。很多這樣的研究人員出于對開源代碼的熱愛和尊敬，為了幫助代碼更安全做出了自己的貢獻。

然后，那些賞金獵人（用了最好聽的方式來稱呼他們）為了那些冷冰冰的現(xiàn)金獎勵而尋找漏洞。最近幾年，一個迷你行業(yè)正在興起，幫助黑客們改邪歸正，允許他們利用自己邪惡的本領來做好事。很多像微軟這樣的大型組織已經(jīng)為白帽黑客設立了漏洞賞金計劃，以用于報告漏洞并獲得報酬。

HackerOne 和 Bugcrowd 是為各家公司甚至美國政府運營這些漏洞賞金計劃的兩大巨頭。為了避免錯失其中的樂趣，在開源社區(qū)里也有一些 bug 賞金倡議，它們得到了一些主要參與者的支持。

早在 2014 年，Linux 基金會（Linux Foundation）為了應對 Heartbleed 漏洞而建立核心基礎架構聯(lián)盟（Core Infrastructure Initiative）計劃。他們成功地引進了微軟、英特爾、谷歌、IBM、亞馬遜、VMware 和許多其他的行業(yè)領導者，募集了 3 百多萬美元賞金。另一個眾所周知的開源計劃是非營利性 bug 懸賞項目（Internet Bug Bounty，簡稱 IBB）倡議，獲得了臉書、福特基金會（Ford Foundation）以及最重要的 GitHub 的支持，每一家都提供了 10 萬美元以支付研究人員。

暴露開源漏洞之后的響應

當研究人員最終在項目中發(fā)現(xiàn)漏洞時，會通知相關各方以啟動一系列操作。

研究人員首先要做的是，把他們的發(fā)現(xiàn)發(fā)送給受美國政府支持的非營利 MITRE 公司，該公司是維護通用漏洞披露平臺（Common Vulnerabilities and Exposures，簡稱 CVE）漏洞注冊的機構。然后，MITRE 的工作人員將分析漏洞以確認，并提供關于漏洞的信息。這通常包括嚴重性評級，漏洞如何被利用的細節(jié)，最好還要有到修補程序的鏈接以便于修復該漏洞。在這個階段，漏洞會得到一個 ID。其中包括被報告的年份和唯一的 ID 號碼。比如，用于攻擊 Equifax 的 Apache Struts2 漏洞被標識為 CVE-2017-5638。

MITRE 維護的 CVE 系統(tǒng)的組織化程度還遠遠不夠，因此，漏洞信息會在國家漏洞數(shù)據(jù)庫（National Vulnerability Database，簡稱 NVD）上列出，該數(shù)據(jù)庫是一個很好的目錄。

與此同時，研究人員還將聯(lián)絡開源組件的項目管理人員，通知他們有問題要處理。在正常情況下，根據(jù)公平競爭原則，研究人員在把他們的發(fā)現(xiàn)公布于眾之前，會給項目管理人員大概 60 到 90 天的時間以找出漏洞的修復方案。幸運的話，項目管理人員會在截止時間前提出解決方案。

在 CVE 公布于眾后，所有人都能獲得該信息，其成為已知漏洞。這其中包括好人，他們會利用該信息為自己的應用程序打補丁，而那些得到免費信息的壞人，則能利用該信息攻擊那些打補丁很慢的公司。

正因為如此，已知漏洞是開源組件的主要威脅。既然大量漏洞的詳細信息在 NVD 上免費列出，黑客們?yōu)槭裁催€要浪費時間自己去找漏洞呢？

保護你的開源組件

正如我們在這里看到的那樣，當涉及開源代碼時，安全團隊面臨的挑戰(zhàn)就不是自己在代碼里面找出漏洞，而是在已知漏洞變得可用時，他們得做好準備。

要保持這些開源組件的安全，有兩件事需要解決。

第一件要解決的事情就是需要掌握在代碼庫和產(chǎn)品中所使用的開源組件是否包含現(xiàn)有漏洞。如果你的開發(fā)人員還沒有使用工具去跟蹤他們擁有的組件以及那些組件的安全狀態(tài)，那么他們可能會發(fā)現(xiàn)自己跟 Equifax 一樣，處于缺乏關鍵可見性信息的境地。

除此之外，盡管我們可以修復脆弱的“必備”的組件中的問題，開發(fā)人員還是應該避免在構建新產(chǎn)品時，使用那些有已知漏洞的組件。這意味著，在把開源組件加入到你的代碼庫或產(chǎn)品中前，要利用可以檢測脆弱組件的解決方案，甚至可以利用自動化策略，如果開發(fā)人員試圖提交一段有風險的代碼時，該策略就讓構建失敗。

保證產(chǎn)品和產(chǎn)品中內(nèi)含數(shù)據(jù)的安全，已經(jīng)成為客戶的期望，因此需要應用正確的工具以在黑客們攻擊之前就能找到含有已知漏洞的組件。

由于大量的開源組件在業(yè)界廣泛使用，開發(fā)人員和安全團隊需要采用自動化的解決方案來跟蹤所有在他們的代碼庫和產(chǎn)品中用到的開源組件，同時監(jiān)控像 NVD 這樣的漏洞數(shù)據(jù)庫以在研究人員發(fā)現(xiàn)新的漏洞時接收到警報。

像 WhiteSource 和 Flexera 這樣的軟件組件分析（Software Composition Analysis，簡稱 SCA）工具正是為此目的而設計的，也是應用程序安全策略的重要組成部分，通過這種方式，我們就能趕在黑客的前面，這樣的話才能維護客戶信任同時保持產(chǎn)品的安全。未能實施 SCA 工具會讓組織面臨攻擊，老實說，沒人想成為下一個 Equifax。