Sean Michael Kerner 2022-01-27
Log4j 被嵌入在众多流行的服务和框架中，到 2021 年底已成为许多企业的“头痛”问题。受影响的企业包括苹果（Apple）、微软（Microsoft）和 VMware。
什么是 Log4j？
Apache Log4j 项目是部署最广泛的开源软件之一，为 Java 应用程序提供日志记录功能。
Log4j 是 Apache Logging Services 项目的一部分——这是 Apache 软件基金会内的一个开源项目。Apache Logging Services 项目包含多个 Log4j 日志框架的变体，适用于不同的编程部署和使用场景。其他属于 Apache Logging Services 的项目还包括 Log4j Kotlin、Log4j Scala 和 Log4Net。
Log4j 最初于 1999 年 10 月发布，1.0 版本于 2001 年 1 月正式推出。目前主流版本是 Log4j 2 分支，于 2014 年 7 月正式发布，并在此后持续进行定期更新。
Log4j 通常作为软件库嵌入在应用程序或 Java 服务中。因此，并非所有用户或组织都清楚自己正在使用 Log4j 作为嵌入式组件。
什么是 Log4j 漏洞？
Log4j 在 2021 年 12 月之前并未引起太多关注，直到一系列严重漏洞被公开披露。
Log4j 漏洞最初表现为一个单一漏洞，但随后演变为一系列与 Log4j 和 Java 命名与目录接口（JNDI）相关的问题，而 JNDI 正是该漏洞的根本原因。
CVE-2021-44228
Log4j 的初始漏洞编号为 CVE-2021-44228。该漏洞最早由阿里云安全团队的陈兆军于 2021 年 11 月 24 日报告给 Apache 软件基金会。Log4j 开发团队在 12 月 6 日完成了修复，但该项目当时并未公开披露这一高危安全漏洞。
2021 年 12 月 9 日，安全公司 LunaSec 的研究人员通过推特公开披露了 Log4j 中存在严重的远程代码执行（RCE）漏洞。LunaSec 将该漏洞命名为 Log4Shell，此后媒体普遍以此名称指代 CVE-2021-44228 及其后续相关漏洞。
事实上，在公开披露前，已有其他机构知晓该漏洞。Cloudflare 首席执行官 Matthew Prince 表示，该公司早在 12 月 1 日就发现了相关攻击证据；思科（Cisco）则称首次发现针对 Log4j 的攻击是在 12 月 2 日。
CVE-2021-44228 是一个影响多个 Log4j 版本的远程代码执行漏洞，涵盖 Log4j2 2.0-beta9 至 2.15.0（不包括安全版本 2.12.1 和 2.13.0）。该漏洞源于 Log4j 在处理 JNDI 请求时未对所有请求进行适当验证。这意味着攻击者一旦能够控制日志消息内容，就可以注入恶意消息，从而在目标系统上执行任意代码。
美国国家标准与技术研究院（NIST）国家漏洞数据库（NVD）将 CVE-2021-44228 的严重性评分定为 10.0（满分），即通用漏洞评分系统（CVSS）中的最高级别。
CVE-2021-45046
Log4j 项目于 12 月 6 日发布了首个针对 CVE-2021-44228 的补丁（Log4j 2.15.0），但该补丁并不完善，未能完全阻止攻击者利用 JNDI。这一缓解措施不足的问题被标识为 CVE-2021-45046。
该漏洞在第二个更新（Log4j 2.16.0）中得到修复，该版本于 12 月 13 日公开发布。新版本默认禁用了 JNDI 功能，开发者必须显式启用并配置相应权限才能使用。
CVE-2021-41014
最初人们认为 Log4j 漏洞仅影响 2.x 版本，不影响较旧的 1.x 版本。然而，2021 年 12 月 15 日披露的 CVE-2021-41014 证明事实并非如此。
虽然 Log4j 1.x 默认未直接支持 JNDI，但用户可通过 JMSAppender 对象执行 JNDI 请求。由于 Log4j 1.x 已于 2015 年 8 月终止维护，官方不再为此漏洞提供补丁，建议用户升级至最新的 Log4j 2.x 版本。
CVE-2021-45105
2021 年 12 月 17 日发布的 Log4j 2.17.0 修复了另一个问题。CVE-2021-45105 是一个拒绝服务（DoS）漏洞，由递归查找（recursive lookup）触发，可能导致系统资源耗尽。递归查找是指对同一信息反复查询，直至获得明确结果。
CVE-2021-44832
尽管 Log4j 2.16.0 默认禁用了 JNDI，但仍存在一些边缘情况可能带来风险。CVE-2021-44832 是一个与 Java 数据库连接（JDBC）通过 JNDI 以不安全方式交互相关的漏洞，可能导致远程代码执行。该漏洞已在 Log4j 2.17.1（2021 年 12 月 27 日发布）中修复。
受影响的企业和系统
在首个漏洞公开披露后，攻击数量激增，黑客纷纷试图利用未打补丁的系统。由于 Log4j 日志库被广泛嵌入各类流行服务和框架中，其影响范围极为广泛。以下是一些已知受影响的产品：
- Apache Struts：Log4j 是 Apache Struts 2 应用框架的默认配置组件。Struts 近年来多次曝出漏洞，曾是 2017 年 Equifax 数据泄露事件的根源。由于 Struts 本身又被嵌入大量企业应用中，许多组织可能在不知情的情况下暴露于风险之中。
- Apache Solr：Log4j 默认集成在 Apache Solr 搜索平台中，用户需更新至最新修复版本以规避风险。
- Apple iCloud 服务：iCloud 服务曾受 Log4j 漏洞影响，苹果已在其端完成修复。若未修复，攻击者可能获取数百万用户的信息。
- Microsoft Minecraft：微软旗下的《我的世界》（Minecraft）游戏于 12 月 10 日被发现存在风险，当日即发布了安全公告和补丁。
- VMware 产品：多款 VMware 产品受到影响，包括 VMware Horizon、vCenter Server 和 vRealize Operations。
上述列表仅反映了 Log4j 漏洞影响的一小部分。美国政府目前正在追踪一份冗长的受 Log4j 漏洞影响的软件清单。
美国政府对 Log4j 的响应
从事件初期起，美国政府就在 Log4j 漏洞的应对中发挥了主导作用。
网络安全与基础设施安全局（CISA）于 2021 年 12 月 17 日发布 紧急指令 22-02（Emergency Directive 22-02），要求所有联邦政府机构立即对受 Log4j 漏洞影响的应用和服务进行缓解、打补丁或移除，并须在 12 月 28 日前上报受影响的应用清单。CISA 计划于 2022 年 2 月 15 日前向国土安全部部长提交关于该紧急指令执行情况及 Log4j 影响的报告。
CISA 并非唯一发布相关指令的美国政府机构。2022 年 1 月 4 日，联邦贸易委员会（FTC）警告企业必须及时修复 Log4j 漏洞，否则将面临法律后果。
如何防范 Log4j 漏洞？
Log4j 漏洞所暴露的风险类型同样存在于其他嵌入式开源或专有代码组件中。关键挑战在于识别风险所在，并采取有效措施加以缓解。以下是组织可采取的若干防护步骤：
实施 DevSecOps 策略
一些业内人士乐观地认为，Log4j 事件将成为 DevSecOps 的“警钟”，促使组织避免在生产环境中仓促修复漏洞。理想情况下，开发和运维全生命周期中应已建立流程，用于早期发现问题并快速部署修复。
使用基于网络的过滤
许多组织面临的难题是“不知道自己是否处于风险中”，另一难题是依赖 Log4j 的供应商尚未发布补丁。对此，可采用基于网络的过滤或 Web 应用防火墙（WAF） 云服务（如 Cloudflare、Imperva 或 Akamai），在攻击到达脆弱应用前将其拦截。
扫描应用以识别风险
对于自行管理的应用，建议扫描其中是否存在易受攻击的 Log4j 实例。目前有多款工具可用于此目的，其中最受欢迎的是 CERT-CC 和 CISA 提供的开源扫描工具。
打补丁并持续跟进
一旦确认应用使用了存在漏洞的 Log4j 版本，最佳做法是升级至最新版 Log4j，这可修复所有目前已知且公开披露的漏洞。
监控恶意流量
自 2021 年 12 月初以来，Log4j 攻击持续不断，组织可能在完成修复前已被攻破。因此，应采用 威胁狩猎（threat hunting）技术，结合日志和运维监控工具，主动检测是否已遭入侵，并持续监控可疑流量。