修完又複活！史詩級 Log4j 漏洞爆發1年仍“陰魂不散”

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

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

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

嚴重程度？我打 10 分！

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

再來看 Check Point 的資料，截至 2021 年 12 月 13 日，也就是漏洞披露後的 72 小時，全球已經出現超 80 萬次利用嘗試。安全公司 Nextron Systems 的研究主管 Florian Roth 釋出推文稱，“#Log4Shell 不僅僅是個 RCE（遠端代碼執行）零日漏洞，更是一個會在各種軟體産品上衍生出成百上千種其他零日漏洞的缺陷。它堪稱零日漏洞中的集束炸彈。”

但，不是更新檔很快就釋出了嗎？到 2021 年 12 月 20 日，Log4j 2.17.0 就已經修複了主要和次要問題。是以，這事應該過去了才對呀。

沒那麼簡單

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

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

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

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

72% 的組織仍易受到攻擊

根據安全公司 Tenable 的說法，“截至 2022 年 10 月 1 日，72% 的組織仍易受到 Log4Shell 漏洞的攻擊。”為什麼會這樣？“在全面修複之後，仍有近三分之一（29%）的資産中再次出現了 Log4Shell 漏洞。”

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

Tenable 公司首席安全官 Bob Huber 強調，“對于普及度如此之高的漏洞，其實已經很難完全修複。 更重要的是，漏洞修複絕不是「一勞永逸」的過程。雖然組織可能在某個時刻實作了完全修複，但随着将新資産添加到業務環境當中，Log4Shell 可能會一次又一次反複出現。根除 Log4Shell 是一場持續鬥争，要求組織不斷評估環境中的缺陷及其他已知漏洞。”

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

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

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

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

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

如同一場流行病

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

關于專有軟體安全的問題，安全廠商 ReversingLabs 的軟體保險布道師 Charlie Jones 預計，Log4Shell 造成的影響可以與 MS-17-10 相媲美。MS-17-10 也就是大名鼎鼎的微軟“永恒之藍”SMB 漏洞，曾直接催生出 NotPetya 和 WannaCry 擦除惡意軟體。而且，“Log4Shell 造成的挑戰比 MS-17-10 還更複雜，因為其往往被深嵌在應用程式的依賴項内，是以難以用标準工具快速加以識别。”

Log4j 帶來的真正教訓是，哪怕我們努力想要清除和修複，首先也得搞清楚程式裡到底有些什麼。在這個影響軟體供應鍊根基的問題被自動化工具攻克之前，預計将有更多由 Log4j 引發的問題出現。我們暫時能做的，唯有祈禱麻煩小一點、影響弱一點。