獨家：Log4j將徹底改變漏洞披露游戲規則

2021年12月9日，一條推文（現已刪除，GoUpSec分析師留有截圖）鏈接到GitHub的Log4j零日漏洞（Log4Shell）的概念證明利用(PoC)（該Github賬戶現已刪除，GoUpSec分析師留有截圖），雖然在漏洞補丁發布前一周，大約12月1日-2日，就有思科talos等國外網絡安全公司發現Log4Shell存在野外利用，但真正讓互聯網和全球企業網絡安全部門燃起熊熊大火的，正是12月9日這個PoC的“首發”（下圖）。

工信部12月22日發通報暫停阿里云公司作為工信部網絡安全威脅信息共享平臺合作單位6個月，作為對阿里云違反今年發布的網絡產品安全漏洞管理規定的處罰。因為，阿里云11月24日就向Apache軟件基金會通報漏洞，但直到15天后的12月9日漏洞補丁發布，工信部網絡安全威脅和漏洞信息共享平臺才通過有關網絡安全專業機構報告得知Apache Log4j2組件存在嚴重安全漏洞，向行業單位進行風險預警。

與《南華早報》及大量海外網絡媒體報道聲稱的”阿里云因未能第一時間向工信部匯報而遭受處罰”不同，GoUpSec認為，阿里云第一時間向Apache匯報漏洞并未違反《網絡產品安全漏洞管理規定》中第七條第一款：“對屬于其上游產品或者組件存在的安全漏洞，應當立即通知相關產品提供者。”阿里云違反的是第七條第二款：“應當在2日內向工業和信息化部網絡安全威脅和漏洞信息共享平臺報送相關漏洞信息。”

誰需要為“該死的”PoC披露負責

以上對Log4j漏洞披露時間主節點的簡要回顧，并非認定阿里云安全團隊需要為Log4j漏洞引發的巨大安全災難負責。相反，我們認為阿里云安全團隊雖然違反了國內的相關漏洞管理規定，但是作為安全團隊能夠發現史詩級的重大開源漏洞并第一時間報告給開源社區，幫助Apache數天內就推出補丁（雖然第一版補丁引入了新的漏洞），這部分工作客觀上是值得稱贊的，也從一個側面表明我國網絡安全企業的技術能力已經躋身世界一流。

讓事態失控的并不是阿里云的漏洞匯報，而是那個導致大規模漏洞利用的漏洞PoC“首發”（編者：PoC往往也是漏洞公開披露的一部分），該PoC的發布甚至早于12月9日當時Log4j漏洞的CVE編號分配！GoUpSec從目前互聯網公開的殘存信息中尚無法精準溯源這個“搶發“PoC的黑客的具體身份（這在安全社群內是半公開的秘密）。但我們可以確定的是，從目前的輿論監測來看，全球網絡安全業界都開始集體反思和譴責這次PoC”零日披露“行為。

黑客才是PoC披露的受益者

CDL的首席信息安全官Haynes指出，隨著時間的推移，研究和經驗告訴我們，黑客和威脅行為者是唯一從零日PoC的公開發布中受益的人，根據CheckPoint和Sophos安全團隊的監測，12月9日漏洞PoC公開披露后，就像打開了潘多拉盒子，“蜜罐中涌入了大量攻擊者，數日內產生超過60個漏洞利用變種，不到一周時間全球40%的企業就遭遇了Log4j漏洞利用攻擊”。這使全球企業、政府、關鍵基礎設施甚至消費者都處于極為尷尬和危險的境地，不得不手忙腳亂地緩解漏洞。

對于Log4j漏洞來說，更加糟糕的是第一版補丁（2.15rc）本身并不完善，引入了其他漏洞，目前的最新版本已經迭代到2.17.1。漫長顛簸而復雜巨量的修補工作也給黑客的漏洞利用留下了充裕的時間和空間，不少安全專家預測，Log4j漏洞將成為互聯網的慢性癌癥長期困擾全球企業的安全團隊。

負責任的漏洞披露通常如何運作？

目前存在各種負責任的漏洞披露機制。一些企業會發布一個官方批準和廣泛宣傳的漏洞披露計劃，也有企業則選擇通過眾包平臺來實施類似的項目。通常，公司會為有關其產品漏洞的信息提供資金（也稱為“漏洞賞金”）。

這些披露通常要經過一個特定的過程，并且有明確定義的供應商補丁發布時間表，以便用戶有足夠的時間來實施它（90天是公認的標準）。通常還規定，PoC只能在獲得供應商批準的情況下公開發布（這也稱為“協調披露”）。最重要的是，漏洞賞金平臺有時會要求參與的安全研究人員簽署保密協議，這意味著即使漏洞早已修復，PoC也可能永遠不會發布。

向受影響的供應商披露漏洞的流程通常如下（如果一切順利）：

• 研究人員將漏洞告知供應商并提供隨附的PoC
• 供應商確認漏洞的存在并提供修復發布的大致時間表
• 一旦開發出修復程序，供應商會要求研究人員確認修復程序是否有效
• 在研究人員“確認”修復后，供應商實施補丁
• 如果廠商同意，補丁發布后一定時間可以公布漏洞詳情（90天以內都是正常的）

關于Log4j漏洞，當它被公開披露前，PoC披露過程已經在進行中（11月30日在GitHub上出現的pull request可以證明）。根據Apache軟件基金會提供的信息，披露的時間線如下所示：

11月24日：通知Log4j維護者

11月25日：維護者接受了報告，保留了CV，并開始研究修復

11月26日：維護人員與漏洞報告者溝通

11月29日：維護人員與漏洞報告者溝通

12月4日：已提交更改

12月5日：已提交更改

12月7日：創建第一個候選版本

12月8日：維護人員與漏洞報告者溝通，進行了額外的修復，創建了第二個候選版本

12月9日：補丁發布

雖然大量用戶在Apache Log4j GitHub項目頁面上的評論表明對修復速度感到沮喪，但這已經算是很快的響應了——畢竟，這個補丁也是由志愿者開發的。

漏洞披露如何避免“核泄漏”悲劇

發布零日PoC可能有合法且可以理解的原因，其中最常見的理由是漏洞披露流程崩潰：供應商可能沒有或可能停止響應，可能認為漏洞不夠嚴重，需要修復，可能需要很長時間才能修復——或任何以上的組合。在此類情況下，安全研究人員通常會為了“共同利益”而決定發布PoC，即迫使供應商快速發布補丁程序。

零日漏洞PoC的發布往往還有其他原因，例如宣傳（特別是如果研究人員與安全供應商有聯系，或者在其中就職）——對于企業（某些情況下是個人）來說，沒有什么比披露重大漏洞的零日PoC更棒的宣傳效果了，尤其是在沒有可用補丁的情況下。

但必須指出的是，現在安全業界對發布漏洞PoC漏洞的反對意見，無論從證據還是口風來看，都已經是壓倒性的了。

Kenna Security完成的一項研究表明，發布PoC漏洞利用主要有利于攻擊者。幾年前，Black Hat的一次演講回顧了零日漏洞的生命周期及其如何被釋放和被利用，并表明如果漏洞PoC不公開，所涉及的漏洞通常平均7年內都不會被其他任何人發現（包括黑客）。

可悲的是，log4j漏洞PoC的發布者（們）顯然沒有意識到這一點，最初搶發漏洞PoC的推文和GitHub鏈接（編者：甚至連賬戶一起）被迅速刪除，但造成的嚴重后果已經無法挽回。對這種傷害的集體反思導致補丁2.17.1發布的最新披露也受到了安全社區的強烈抨擊，以至于研究人員公開道歉，因為披露時機不當（下圖）。

值得欣慰的是，經歷Log4j漏洞的互聯網大地震后，業界對公開披露PoC漏洞的放任態度已經發生徹底轉變，對那些急于表現自己的研究人員的嚴厲批評已經成為共識。但批評并不能解決問題，網絡安全業界接下來要面臨的一個重大議題就是為每個研究者和道德黑客設置更明確、強硬、可靠的披露流程，以便下次發現類似Log4Shell這種超級漏洞時，悲劇不會重演。

參考鏈接：

網絡產品安全漏洞管理規定：

http://www.gov.cn/zhengce/zhengceku/2021-07/14/content_5624965.htm

南華早報：中國工信部因阿里云未先向政府報告漏洞處罰阿里云

https://www.scmp.com/tech/big-tech/article/3160670/apache-log4j-bug-chinas-industry-ministry-pulls-support-alibaba-cloud

（來源：@GoUpSec）