從供應鏈角度看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版本中的遠程代碼調用漏洞,防止漏洞在代碼中被利用。