從供應鏈角度看Log4j2 0day漏洞

Log4j2漏洞甫一爆發，便在全球掀起軒然大波，影響範圍之廣，危害性之大無出其右。Log4j2事件是一場典型的開源軟體導致的供應鏈事件，上游軟體提供商的漏洞殃及下游產業的產品提供者，依賴關係的錯綜複雜使影響範圍擴大，最終遍及整個網路空間。Log4j2事件為安全廠商與網路安全從業者敲響了警鐘，必須警惕開源軟體的供應鏈中暗藏的危機，並採取有效行動。

本文將從軟體供應鏈角度審視Log4j2漏洞如何被引入，並在整個軟體生命週期造成深遠的影響。透過對開源元件中Log4j2二級傳播的分析，我們將理清Log4j2漏洞的感染路徑，並基於此思考可能的攻擊場景。開源軟體的加入為軟體供應鏈安全帶來的新挑戰，呼喚各方協同作戰，構築一套行之有效的供應鏈安全方案。

Log4j2漏洞在軟體供應鏈各階段的影響

Log4j2作為一個堪比標準庫的基礎日誌庫，無數的開源 Java 元件直接或間接依賴於它。作為軟體供應鏈中的核心原始元件，元件自身的漏洞帶給整個軟體供應鏈的影響是最為直接、隱秘，也是影響最為深遠的。

在元件的整合構建階段，當 Log4j2 作為基礎元件整合到一些核心業務元件的同時，漏洞也就在有意無意之間傳播到了更為上層的核心業務當中，使產品的核心業務暴露出了一個附加的攻擊面。在此階段，由於元件之間的依賴關係相對來說還較為清晰，所以當漏洞被引入時，受到的影響面也較為容易排查。我們往往只需要將程式碼倉庫中的受影響的元件版本更換為安全的補丁版本或直接移除更換掉即可。

在元件的依賴使用階段，隨著當前軟體系統架構複雜性的提升，元件之間依賴的深度也逐漸增加。當 Log4j2 這類核心元件受到漏洞影響時，軟體系統自身的複雜性就會掩蓋影響，導致整個軟體系統的攻擊面被隱藏起來，從而容易被人忽略。所以在這個階段排查漏洞影響是最為艱難的，往往需要安全工程師們進行大規模的分析排查、抽絲剝繭，將軟體系統的各種依賴關係梳理清楚。站在攻擊、防禦的角度也同樣如此，攻擊者及防禦者往往需要透過 hook、fuzz 等方式測試元件的呼叫深度，從而找出被隱藏的漏洞觸發點。

在下游使用者使用階段，受到的影響則是更為被動的。因為複雜軟體系統對於身處下游的使用者來說就是一個黑盒，普通使用者對於其包含的元件風險一無所知，此時只能靠有責任心的軟體提供商來提供運維支援服務。如果遇到不負責任或者漏洞應急不及時的供應商，則只能依靠社群建議及旁路的安全裝置來進行臨時緩解。

Log4j2漏洞傳播渠道分析

根據Log4j2漏洞元件引入的不同方式，可分為直接依賴與間接依賴這兩種情況。前者是指專案開發時直接使用Log4j2作為日誌記錄框架；而後者則是使用的第三方元件或框架使用了Log4j2，使有漏洞的元件間接引入專案。

相較於直接依賴，間接依賴更不易為開發者所知悉，在發生漏洞事件時更不易得到修復。Sonatype在2020年度釋出的軟體供應鏈報告中的資料指出：隨著時間推移，開源元件在專案中使用的頻次不斷增加，但開發人員所能察覺的開源元件比例卻顯著下降。

 

目前我們注意到Maven庫中受此漏洞影響的元件較多，除此之外許多獨立的框架與應用也受到了影響。為研究Log4j2漏洞的二級傳播途徑，綠盟科技研究團隊對Maven倉庫中部分受影響的專案進行了統計。依據已有的統計資料，我們發現Log4j2漏洞的二級傳播主要依靠開源框架與元件。

Log4j2漏洞對供應鏈下游的潛在影響

此次漏洞的涉及範圍廣泛且危害嚴重，因此各個場景領域都應該重點關注。為了保護客戶業務的運轉和資產的安全，各個領域應該意識到該漏洞的嚴重性，並及時排查可能受到影響的部分；同時面對資產繁雜的場景，應分清楚優先順序，從對業務的對業務影響嚴重性高的入手逐步剝除該漏洞威脅的可能。以下是幾個場景領域的典型案例，幫助安全從業人員總結歸納，儘可能減少漏洞對供應鏈下游可能造成的影響。

安全產品

安全產品作為企業抵禦入侵者的甲冑，時刻保護著企業的資產安全。一旦安全產品的防護被突破，企業資產便唾手可得。同時出於防護的需要，某些安全產品對於企業資產擁有監視和管控的許可權，如果被攻破則會幫助攻擊者進一步擴大對企業的危害。

Bitdefender中的雲產品GravityZone Cloud包含被Log4j2漏洞攻擊的潛在風險，該產品能夠對雲環境下的主機集中管理，一旦被攻擊會導致攻擊者直接接管整個雲環境。

大資料

資料往往是攻擊者入侵的首要目標，大資料平臺中往往包含大量使用者隱私資料，平臺淪陷所致的隱私資料洩露會造成不可估量的影響。

ElasticSearch作為一個功能強大的開源資料庫，由於搜尋速度快和配置靈活等優點被廣泛應用於各種企業和組織，往往儲存著海量的資料。2019年10月和12月由於暴露於公網的ElasticSearch沒有配置密碼保護，導致幾十億使用者資訊洩露。ElasticSearch5以上版本的外掛XenForo Enhanced Search中包含了可利用的Log4j2。攻擊者利用Log4j2漏洞將導致大量暴露在公網的ElasticSearch資料庫淪陷，造成海量的資料洩露。

虛擬化平臺

虛擬化產品中部署的虛擬容器中常常包含某些重要的使用者業務，一旦虛擬容器被攻擊後會造成使用者的業務中斷或資料洩露和加密，更甚者如果虛擬平臺中的管理服務被攻擊後，會造成整個虛擬化平臺的淪陷。

VMWare vCenter作為VMWare vSphere雲端計算基礎架構虛擬化平臺中的核心元件，可用於集中管理VMWare vSphere環境。3月14日針對VMWare虛擬化環境的勒索病毒攻擊導致大量使用者在虛擬機器中的生產業務受到影響，部分Windows系統的資料也被加密。一旦攻擊者能夠成功利用Log4j2漏洞攻擊vCenter伺服器，便能夠透過vCenter伺服器管理整個虛擬環境中的所有虛擬機器，導致vSphere環境中虛擬機器的業務中斷或資料洩露。

軟體供應鏈安全呼籲各方行動

開源軟體的開發方應該具備漏洞情報收集、影響範圍定位和及時提供修復補丁的能力。但開源軟體專案的維護者卻經常以疲於奔命的狀態義務維護著專案，無暇顧及潛在的安全風險。本次事件中Log4j2專案組僅有三位社群貢獻者進行開源與漏洞修復，維護著足以撼動網際網路大廈的專案。使開源專案維護者的角色專業化，在專案開發過程中採取保障供應鏈安全的有效措施，或是解決開源軟體供應鏈安全的必經之路。

企業在選擇開源軟體時應該關注開發方的能力，這就會衍生出對開發方能力評價的服務，也同時衍生了開發方能力建設的服務，這種服務一部分可以來自於安全公司，也可以是直接購買分發方提供的SaaS服務（比如漏洞情報）。

對於分發方，應該要跟開發方和使用者建立直接的聯絡，及時提供更新補丁和最新修復的版本，並通知下載過原版本的使用者進行修復。那麼分發方應該也是要做一個能力建設和評價。

作為使用者方在收到漏洞情報後要及時修復閉環，這裡使用者也可能是使用開源元件進行開發的一個軟體整合商，那麼對於軟體整合商的能力評價和建設也會是一個重要方面。

因此漏洞威脅情報、各方軟體供應鏈安全能力評估、漏洞閉環管理和安全能力平臺建設會是一些通用的供應鏈安全方案。

總結

開源軟體的引入在減少開發時間的同時，增加了軟體供應鏈安全的複雜度，類似Log4j2這樣應用廣泛的基礎元件在供應鏈的各階段均存在深入的影響。大型專案中依賴關係數量與依賴層級數量的複雜度，增加了廠商對漏洞的排查難度。對漏洞元件間接依賴的開源元件及框架所導致的二級傳播大大擴充了Log4j2漏洞的影響範圍。上游軟體供應鏈產品中漏洞累積的影響，最終會在下游應用場景中浮現，下游產品服務提供商應當採取有效手段，對涉及漏洞的資產進行排查。

產品開發中複雜多層級的依賴關係，與客戶資產的紛繁複雜均呼喚一種行之有效的解決方案。目前綠盟科技的程式碼安全審計產品SDA，透過多維BOM分析技術，豐富的漏洞知識庫，能夠準確檢測程式碼中所使用的Log4j2元件2.0到2.15-rc1版本中的遠端程式碼呼叫漏洞，防止漏洞在程式碼中被利用。