Log4j 漏洞風波暫平，但下一場暴雷可能已經(jīng)在路上。

過去這一年，Log4j 頻頻暴雷。新年伊始，很多朋友可能覺得 Log4j 這事兒已經(jīng)過去了。不，還沒完呢。

2021 年，甚至很多人還根本沒聽說過 Apache Log4j 這一開源 Java 日志記錄庫。但它確實在無數(shù)應用程序中發(fā)揮著作用，包括各類 Apache 項目（Flink、Flume、Hadoop、Kafka、Solr、Spark 和 Struts 等），再到 Apple iCloud、Elastic LogStash、Twitter 以及眾多 VMware 程序。就連《我的世界》游戲里都有它的身影。但是，又能如何？這只是個友善無害的日志記錄程序……然后，麻煩就來了。

(資料圖片僅供參考)

Apache 基金會于 2021 年 12 月 4 日悄悄發(fā)布了針對 Log4j 漏洞的補丁，可幾乎沒人注意到。后來，Mojang Studios 為其熱門游戲《我的世界》推出了針對零日漏洞 CVE-2021-44228（又名 Log4Shell）的修復補丁，這才讓大家意識到問題的嚴重性。事實證明，這個漏洞不僅易被利用，而且攻擊者可以全面控制目標服務器。

嚴重程度？我打 10 分！

那問題到底有多嚴重？根據(jù)國家漏洞數(shù)據(jù)庫（NVD）的統(tǒng)計，其 CVSSv3 得分為 10.0。有些朋友可能不清楚，嚴重度評分是從 0.1 到 10.0，就是說 Log4Shell 得了個最高分。這一零日漏洞的影響甚至引起了白宮方面的關注?？傊?，出事了，出大事了！

再來看 Check Point 的數(shù)據(jù)，截至 2021 年 12 月 13 日，也就是漏洞披露后的 72 小時，全球已經(jīng)出現(xiàn)超 80 萬次利用嘗試。安全公司 Nextron Systems 的研究主管 Florian Roth 發(fā)布推文稱，“#Log4Shell 不僅僅是個 RCE（遠程代碼執(zhí)行）零日漏洞，更是一個會在各種軟件產(chǎn)品上衍生出成百上千種其他零日漏洞的缺陷。它堪稱零日漏洞中的集束炸彈?！?/p>

但，不是補丁很快就發(fā)布了嗎？到 2021 年 12 月 20 日，Log4j 2.17.0 就已經(jīng)修復了主要和次要問題。所以，這事應該過去了才對呀。

沒那么簡單

事實證明，Log4j 在軟件代碼中無處不在。更糟糕的是，即使是現(xiàn)在，很多人都無法判斷自己的代碼中是否還殘留著易受攻擊的 Log4j 版本。

到 2022 年 1 月，微軟警告稱民族國家黑客和網(wǎng)絡犯罪分子仍在利用 Log4j 漏洞對目標系統(tǒng)植入惡意軟件。與此同時，Check Point 研究人員發(fā)現(xiàn)了與伊朗有關的威脅團伙 APT35，其利用 Log4j 漏洞部署基于 PowerShell 的模塊化惡意軟件。同樣的策略至今仍然存在。微軟團隊還發(fā)現(xiàn)另一伙來自中國的黑客，他們試圖利用某些 VMware Horizon 版本中的漏洞來安裝 Night Sky 勒索軟件。

當然，“平民”一點的詐騙分子也在利用這個漏洞散播加密挖礦惡意軟件。安全漏洞被用于竊取非法經(jīng)濟所得，聽起來多么合乎邏輯。

2022 年 12 月初，網(wǎng)絡安全與基礎設施安全局（CISA）透露稱，黑客仍在使用 Log4Shell。

72% 的組織仍易受到攻擊

根據(jù)安全公司 Tenable 的說法，“截至 2022 年 10 月 1 日，72% 的組織仍易受到 Log4Shell 漏洞的攻擊?！睘槭裁磿@樣？“在全面修復之后，仍有近三分之一（29%）的資產(chǎn)中再次出現(xiàn)了 Log4Shell 漏洞?！?/p>

簡單來說，原本的代碼確實修復了，但之后有人引入了“新代碼”，而新代碼里又包含舊的 Log4j 版本。然后，漏洞就又復活了。

Tenable 公司首席安全官 Bob Huber 強調(diào)，“對于普及度如此之高的漏洞，其實已經(jīng)很難完全修復。更重要的是，漏洞修復絕不是「一勞永逸」的過程。雖然組織可能在某個時刻實現(xiàn)了完全修復，但隨著將新資產(chǎn)添加到業(yè)務環(huán)境當中，Log4Shell 可能會一次又一次反復出現(xiàn)。根除 Log4Shell 是一場持續(xù)斗爭，要求組織不斷評估環(huán)境中的缺陷及其他已知漏洞?！?/p>

依賴項、依賴項，還是依賴項

但這真的可能嗎？Tenable 并沒有深入探討，可 Endor Labs 的 Station 9 發(fā)布了一份“依賴項管理狀態(tài)”研究報告，也許給出了一點啟示。在很多廠商的開源代碼庫中，95% 的漏洞并非源自開發(fā)者的主動選擇，而是被間接引入了項目之內(nèi)。

Endoir Labs 聯(lián)合創(chuàng)始人兼 CEO Varun Badhwar 表示，“從部分指標來看，開發(fā)者每在軟件項目中引入一個依賴項，平均被同時傳遞進來的其他依賴項多達 77 到 78 個。”因此，“實際發(fā)現(xiàn)的漏洞有 95% 都源自這些傳遞的依賴項，也就是那些「搭便車」的乘客。我們需要在環(huán)境中跟蹤所有依賴項，并了解哪些應用程序究竟在使用哪些軟件包。”

于是乎，軟件物料清單（SBOM）和軟件工件供應鏈級別（SLSA）變得空前重要。如果沒有二者的保障，企業(yè)在部署代碼前根本無法評判其中包含著什么。

根據(jù) Tenable 的統(tǒng)計，截至 2022 年 10 月 1 日，全球有 28% 的組織已經(jīng)完全修復了 Log4Shell，較 2022 年 5 月提高了 14%。但這還遠遠無法令人安心。

如同一場流行病

Thales 公司首席產(chǎn)品安全官 Bob Burns 表示，Log4j 就如同“一場流行病，將在未來幾年內(nèi)持續(xù)保持威脅和傳播力。”這也引發(fā)了人們對于開源軟件底層安全的擔憂。當然，從之前震驚全球的 SolarWinds 事件來看，專有軟件也同樣談不上可靠。

關于專有軟件安全的問題，安全廠商 ReversingLabs 的軟件保險布道師 Charlie Jones 預計，Log4Shell 造成的影響可以與 MS-17-10 相媲美。MS-17-10 也就是大名鼎鼎的微軟“永恒之藍”SMB 漏洞，曾直接催生出 NotPetya 和 WannaCry 擦除惡意軟件。而且，“Log4Shell 造成的挑戰(zhàn)比 MS-17-10 還更復雜，因為其往往被深嵌在應用程序的依賴項內(nèi)，因此難以用標準工具快速加以識別?！?/p>

Log4j 帶來的真正教訓是，哪怕我們努力想要清除和修復，首先也得搞清楚程序里到底有些什么。在這個影響軟件供應鏈根基的問題被自動化工具攻克之前，預計將有更多由 Log4j 引發(fā)的問題出現(xiàn)。我們暫時能做的，唯有祈禱麻煩小一點、影響弱一點。

原文鏈接：

https://thenewstack.io/one-year-of-log4j

關鍵詞： 惡意軟件 應用程序 我的世界