Log4j 漏洞（也称为“Log4Shell”）被视为是有史以来最具灾难性的软件缺陷之一。Apache 于 2021 年 12 月修补了该漏洞，但它仍然是安全团队关注的问题。事实上，它仍然是最容易遭到利用的安全漏洞之一。
Log4Shell 之所以持续存在，是因为它影响的 Apache Log4j 2 软件包是全球使用最广泛的日志记录库之一。据 美国国土安全部称，查找和修复 Log4Shell 的每个实例预计需要十年时间。
与此同时，安全团队可以采取一些措施，加快在其网络中缓解和修复 Log4Shell 漏洞的进程。
在深入探讨如何检测和修补 Log4Shell 漏洞之前，了解该漏洞的性质非常重要。
Log4j 是一个由 Apache 软件基金会维护的开源日志记录器，用于记录程序中的信息和事件。Log4j 不是独立的软件，而是开发人员可以插入到自己的 Java 应用程序中的代码包。Apache Log4j 框架被广泛应用于一些全球最大的网络服务中，从 Amazon Web Services (AWS) 和 Cisco 等网络基础设施，到 Twitter 和 Minecraft 等热门应用程序，均有使用。
Log4j 的某些版本（尤其是 Log4j 2.17.0 及更低版本）存在严重漏洞。其中最危险的漏洞是 Log4Shell（CVE-2021-44228；CVSS 评分：10），这是在 Log4j 2.14.1 及更早版本中发现的一个远程代码执行 (RCE) 零日漏洞。
Log4Shell 是易受攻击的 Log4j 版本如何处理 Java 命名和目录接口 (JNDI) 的结果，JNDI 是 Java 应用程序用来访问外部服务器上托管的资源的 API。威胁参与者几乎可以完全控制易受攻击的系统，通过 Log4j 发送恶意 JNDI 查找命令。这些命令会诱使应用程序运行任意代码，而这些代码几乎可以做任何事情：窃取数据、安装勒索软件、使设备离线等等。
典型的 Log4Shell 网络攻击运作方式如下：
在 Apache 修补 Log4Shell 的同时，安全研究人员在某些 Log4j 版本中发现了一些相关缺陷。其中包括：
在网络中找到每个易受攻击的 Log4j 实例可能很困难。据估计，Log4j 出现在数百万个应用程序中，这意味着安全团队需要检查大量资产。
此外，Log4j 通常作为间接依赖项存在。这意味着它并非直接包含在资产的源代码中，而是作为资产所依赖的软件包或整合的依赖项出现。Google 报告称，大多数易受攻击的 Log4j 实例在依赖链中超过一层，有些甚至深达九层。
也就是说，安全团队可以通过正确的计策和工具来检测 Log4j漏洞。
从 2.0-beta9 到 2.17 的所有 Log4j 2 版本都易受 Log4Shell 或相关漏洞的影响。换句话说，安全团队必须查找并处理任何早于 2.17.1 版本的 Log4j。
Log4Shell 及其相关漏洞仅存在于“Log4j-core”文件中，这些文件提供 Log4j 的核心功能。这些漏洞不存在于 “Log4j-api” 文件中，该文件负责管理应用程序与 Log4j 日志记录器之间的接口。
Log4j 可以出现在公司控制的资产、公司使用的第三方资产（例如，云服务）以及可访问公司网络的服务提供商使用的资产中。虽然 Log4j 最有可能出现在基于 Java 的应用程序中，但也可能通过依赖项和整合出现在非 Java 应用程序中。
在 Java 应用程序中，像 Log4j 这样的库通常打包在 Java 存档文件（即“JAR 文件”）中。JAR 文件可以包含其他 JAR 文件，其他 JAR 文件又可以包含自己的 JAR 文件，依此类推。要找到 Log4j 的所有易受攻击的版本，安全团队必须检查各级的 JAR 文件，而不仅仅是顶级文件。
专家建议使用多种技术组合来查找 Log4j 漏洞。
手动搜索。安全团队可以手动搜索 Log4j 漏洞。他们可以使用 Apache Maven 等开发工具生成依赖关系树，映射应用程序中的所有依赖关系；或者，他们可以使用外部威胁情报来识别受影响的资产。例如，网络安全和基础设施安全局 (CISA) 编制了一份已知遭受 Log4Shell 攻击的软件列表。该列表可在 GitHub 上找到。
在 Linux、Microsoft Windows 和 macOS 操作系统上，安全团队可以使用命令行界面在文件目录中搜索 Log4j 实例。
漏洞扫描工具。在发现 Log4Shell 漏洞后，一些组织发布了用于检测 Log4j 漏洞的免费工具。其中的例子包括 Palantir 的 Log4j-sniffer 和 CERT 协调中心的扫描工具，以及许多其他工具。
虽然专用扫描工具仍然可用，但许多标准安全解决方案，如漏洞扫描器、攻击面管理 (ASM) 平台以及端点检测与响应 (EDR) 解决方案，现在也能够检测 Log4j 漏洞。
因为 Log4Shell 可能深藏在依赖链中，安全团队可以用更动手的方法来补充自动化扫描，比如渗透测试。
威胁搜寻。根据 CISA 的报告，攻击者已知会利用 Log4Shell 入侵网络，然后修补他们所攻破的资产以掩盖痕迹。因此，建议安全团队假设入侵已经发生，并主动搜索 Log4Shell 漏洞被利用的迹象。
安全信息和事件管理 (SIEM) 解决方案以及扩展检测和响应 (XDR) 平台等网络安全工具可以帮助检测与 Log4Shell 相关的异常活动，例如奇怪的日志条目或可疑的流量模式。鉴于攻击后果可能非常严重，安全团队应该对任何可能存在 Log4Shell 的迹象启动全面的事件响应和调查程序。
安全团队在解决 Log4j 漏洞时有几种选择。
要完全修复 Log4Shell 及相关漏洞，组织必须将其网络中的所有 Log4j 实例更新到最新版本（或至少更新到版本 2.17.1）。最新版本的 Log4j 删除了攻击者可以利用的功能，并删除了对 LDAP 等经常被滥用的协议的支持。
没有可用于整个系统的单一补丁，更新 Java 本身也无法解决该问题。安全团队必须更新每个受影响资产中的每个 Log4j 实例。
安全研究人员一致认为，修补是理想的解决方案。如果修补不可行，组织可以采取其他缓解措施来最大限度地降低遭受攻击的可能性。
禁止在易受攻击的应用程序中查找消息。攻击者利用 Log4j 的“消息查找替换”功能向易受攻击的应用程序发送恶意命令。安全团队可以通过将系统属性“Log4j2.formatMsgNoLookups”设置为“true”，或将环境变量“LOG4J_FORMAT_MSG_NO_LOOKUPS”的值设为“true”，来手动禁止此功能。
虽然删除消息查找替换功能会使攻击者更难攻击，但它并非万无一失。恶意行为者仍然可以利用 CVE-2021-45046 向具有非默认设置的应用程序发送恶意 JNDI 查找。
从易受攻击的应用程序中删除 JNDIlookup 类。在 Log4j 中，JNDIlookup 类负责管理日志记录器如何处理 JNDI 查询。如果此类从 Log4j 的类目录中删除，则无法再执行 JNDI 查找。
Apache 指出，以下命令可用于从易受攻击的应用程序中删除 JNDIlookup 类：
zip -q -d Log4j-core-*.jar org/apache/logging/Log4j/core/lookup/JndiLookup.class
虽然这种方法比禁止消息查询更有效，但它并不能阻止攻击者发起其他利用尝试，例如通过递归查询触发拒绝服务攻击。
阻止潜在的 Log4Shell 攻击流量。安全团队可以使用 Web 应用程序防火墙 (WAF)、入侵检测和防御系统 (IDPS)、EDR 和其他网络安全工具，通过阻止常用协议如 LDAP 或 RMI，拦截与攻击者控制的服务器之间的流量。安全团队还可以阻止与攻击相关的 IP 地址，或攻击者在恶意请求中常用的字符串，例如“jndi”、“ldap” 和 “rmi”。
但是，攻击者可以通过使用新协议和 IP 地址或混淆恶意字符串来绕过这些防御。
隔离受影响的资产。如果其他方法都无效，安全团队可以隔离受影响的资产，等待补丁发布。一种方法是将易受攻击的资产放置在无法直接从互联网访问的隔离网络段中。可以在该网络段周围部署 WAF 以提供额外保护。
修复 Log4Shell 的一个棘手之处在于，它并不总是能保持被修补状态。2022 年 11 月，Tenable 报告称，仍然易受 Log4Shell 攻击的资产中有 29% 是“复发”案例，即这些资产曾被修补，但漏洞再次出现。当开发人员不小心使用包含未打补丁的 Log4j 版本的软件库来构建或更新应用程序时，就会发生重复出现的问题。
虽然开发人员可以更仔细地检查他们使用的框架，但当 Log4j 的易受攻击版本嵌套在多层 JAR 文件中时，很容易被忽略。
实施正式的漏洞管理和补丁管理计划，可为安全团队提供更有效的方法，监控资产是否存在 Log4j 漏洞。定期进行漏洞扫描和渗透测试可以帮助快速发现新的漏洞，无论是 Log4Shell 漏洞还是其他漏洞。补丁管理可确保供应商发布修复程序后立即关闭新漏洞。