1.4 里程碑案例二：Log4j

虽然 SolarWinds 网络攻击是针对软件供应商的，但 Log4j 事件却大不相同，因为它针对的是广泛使用的开源软件 (OSS)。Log4j 事件于 2021 年 12 月 9 日开始引起公众关注，当时安全研究人员发现了流行软件库 Log4j 中的一个漏洞。Log4j 是一个基于 Java 的日志实用程序，是 Apache 软件基金会项目 Apache Logging Services 的一部分。当时，Log4j 主要用于记录与调试和其他活动相关的信息，以帮助开发人员。在事件发生时，据估计 Log4j 存在于超过 1 亿个环境和应用程序中。

2021 年 12 月 10 日，NIST 的国家漏洞数据库 (NVD) 将 Log4j 漏洞在其通用漏洞评分系统 (CVSS) 上归类为 10.0，并将其与通用漏洞和暴露 (CVE) CVE-2021-44228 相关联。随后还发布了与 Log4j 相关的 CVE，其中不仅包括远程代码执行漏洞，还包括拒绝服务 CVE。

零日漏洞公布后不久，新西兰计算机应急响应小组 (CERT) 警告称，该漏洞已在野外被利用 (http://cert.govt.nz/it-specialists/ advisories/log4j-rce-0-day-actively-exploited)。随后，CISA 发布了一项紧急指令 (http://cisa.gov/news/2021/12/17/cisa-issuesemergency-directive-requiring-federal-agencies-mitigate-apache-log4j)，要求联邦机构缓解 Apache Log4j 漏洞。不久之后，2021 年 12 月 22 日，CISA、FBI、NSA 和国际合作伙伴发布了一份联合公告 (http://cisa.gov/news/2021/12/22/cisa-fbi-nsa-andinternational-partners-issue-advisory-mitigate-apache-log4j)，以缓解 Apache Log4j 漏洞。此联合公告是为了应对全球范围内对 Log4j 漏洞的积极利用而发布的。CISA 主任 Jen East 曾称 Log4j 漏洞对世界各地的组织和政府构成了严重且持续的威胁，合作伙伴国家也表达了类似的看法。您可以在图 1.6 (http://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228) 中查看 Log4j 事件时间线。

与影响特定供应商的特定产品系列的 SolarWinds 不同，Log4j 的影响更加多样化和分散。Log4j 的应用范围非常广泛，从开发人员工具、云服务产品到安全供应商产品，无所不包。正如我们将在本书以云为重点的章节中讨论的那样，最大的云服务提供商 (CSP)，例如 Amazon Web Services (AWS)、Microsoft Azure 和 Google Cloud，都发布了有关 Log4j 的指导，因为在事件发生时，Log4j 已用于他们的许多云服务产品中。当然，这不仅会对直接使用云服务的客户产生下游影响，还会对在 CSP 的基础设施和服务之上构建的其他组织产生下游影响，这不仅强调了易受攻击的软件组件的影响，还强调了由于软件供应链中的服务提供商，它可能产生的连锁影响.

除了 GAO 和其他机构提供的见解外，网络安全安全审查委员会 (CSRB) 还将 Log4j 作为其调查和报告的第一个网络事件 (http://cisa.gov/sites/default/files/publications/CSRB-Report-on-Log4-July-11-2022_508.pdf)。CSRB 是根据网络安全行政命令 (EO)“改善国家网络安全”成立的 (http://cisa.gov/sites/default/files/publications/Cyber​​%20Safety%20Review%20Board%20Charter_508%20Compliant.pdf)。CSRB 的成立也类似于国家运输安全委员会 (NTSB)，其目标是审查重大网络事件并提出具体建议，以推动公共和私营部门的改进。委员会的成员包括具有不同独特专业知识的公共和私营部门领导人。他们的第一份报告（如前所述）重点关注 Log4j，其中大量提到了软件透明度、库存和治理的必要性，而软件物料清单 (SBOM) 是这一追求的核心组成部分。该报告呼吁组织利用 SBOM 来提高 IT 资产和应用程序清单的准确性，并呼吁管理和预算办公室 (OMB)、国家网络总监办公室 (ONCD) 和 CISA 等组织在生态系统成熟时提供有效使用 SBOM 的指导。该报告 18 次提到 SBOM，呼吁公共和私营部门组织在 SBOM 和软件透明度领域采用并增加投资

CSRB 的 Log4j 报告内容全面，将其建议分为四类。这些建议包括解决 Log4j 的持续风险、推动现有的安全卫生最佳实践、构建更好的软件生态系统以及进行未来投资。报告承认，组织将在未来几年内努力应对 Log4j 漏洞，并应继续报告和观察 Log4j 的利用情况。报告呼吁组织投资于识别易受攻击系统的能力，建立漏洞响应程序，并继续开发准确的 IT 和应用程序清单，这是 SBOM 在软件组件和 OSS 消费环境中发挥作用的地方。企业中拥有强大软件组件清单的组织将能够更好地应对下一次 Log4j 类型的事件，了解其组织是否易受攻击以及在何处易受攻击。报告呼吁 OSS 开发人员参与基于社区的安全计划，并投资培训开发人员进行安全软件开发，这是 OpenSSF OSS 安全动员计划中的一项关键建议，我们将在本书后面讨论。它还呼吁改进 SBOM 工具和采用，并投资于关键服务的 OSS 维护支持。最后，该报告还呼吁在关键领域进行投资，例如联邦政府供应商的软件透明度基本要求、探索网络安全报告系统 (CSRS) 以及研究构建安全软件的激励结构。所有这些建议都与公共和私营部门其他领先组织的建议一致，例如 NIST、Linux 基金会、OpenSSF 等。

为了承认易受攻击的 OSS 组件（例如本案中的 Log4j）威胁的普遍性，FBI 和 CISA 于 2022 年 11 月发布了联合网络安全咨询，宣布美国联邦民事行政部门 (FCEB) 的一个机构遭受了伊朗政府支持的攻击。恶意行为者利用未打补丁的 VMware Horizo​​n 服务器中的 Log4Shell 漏洞，安装加密挖掘软件，甚至横向移动到域控制器 (DC) 并泄露凭据以实施反向代理，从而在环境中保持持久性 (www.cisa.gov/uscert/sites/default/files/publications/aa22-320a_joint_csa_iranian_government-sponsored_apt_actors_compromise_federal%20network_deploy_crypto%20miner_credential_harvester.pdf)