作者 | Steven J. Vaughan-Nichols
译者 | 核子可乐
策划 | 冬梅
Log4j 漏洞风波暂平，但下一场暴雷可能已经在路上。
过去这一年，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 引发的问题出现。我们暂时能做的，唯有祈祷麻烦小一点、影响弱一点。
原文链接：
https://thenewstack.io/one-year-of-log4j
