使用 Elastic Security 检测 CVE-2021-44228 (log4j2) 的漏洞利用

原创

点火三周

发布于 2021-12-11 19:28:16

4.7K0

发布于 2021-12-11 19:28:16

文章被收录于专栏：Elastic Stack专栏Elastic Stack专栏

重要的提示： 要了解 Elastic 当前如何评估我们产品中此漏洞的内部风险，请参阅此处

概述

这篇博文提供了 CVE-2021-44228 的摘要，并为 Elastic Security 用户提供了检测，以发现他们环境中对该漏洞的主动利用。

随着我们了解更多信息，我们将持续提供更多的更新。截至 2021 年 12 月 11 日星期六，此版本是准确的。可以通过Log4j2的安全页面直接调查来自 Apache 的更新。

CVE-2021-44228 (Log4Shell) 摘要

Log4j2 是一个开源日志框架，并被广泛的集成到最终用户系统和服务器上的许多基于 Java 的应用程序中。2021年11 月末，阿里巴巴的Chen Zhaojun发现了一个远程代码执行漏洞，最终被报告到 CVE：CVE-2021-44228，于 2021 年 12 月 10 日向公众发布。该漏洞是通过对传入框架的用户输入进行不当的反序列化而被利用的。它允许远程执行代码，并允许攻击者泄漏敏感数据，例如环境变量，或在目标系统上执行恶意软件。

该漏洞影响从 2.0-beta9 到 2.14.1 版本的所有 Log4j2 版本。早期修补该问题的方法导致了一些候选版本的出现，最终在本文发布时建议将框架升级到 Log4j2 2.15.0-rc2。

考虑到该日志库的已被广泛采用以及漏洞利用的复杂性，在任何已确定使用 Log4j2 易受攻击版本的软件环境中，缓解措施都应被视为至关重要。

使用Elastic Security检测对Log4Shell的漏洞利用

Elastic Security 用户可以使用以下事件关联检测规则来识别对 log4j2 漏洞的主动利用。

sequence by host.id with maxspan=1m
 [network where event.action == "connection_attempted" and 
  process.name : "java" and
  /* 
     outbound connection attempt to 
     LDAP, RMI or DNS standard ports 
     by JAVA process 
   */ 
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and 

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh", 
                   "bash", 
                   "dash", 
                   "ksh", 
                   "tcsh", 
                   "zsh", 
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*", 
                   "wget")] by process.parent.pid

该检测规则特定的相关行为序列：1，即试图向外连接LDA、RMI和DNS的标准端口（最近观察到的最被滥用的JAVA/JNDI注入攻击）。2，同一Java进程实例创建了子进程。

现在，让我们演示一下这个规则是如何检测到利用log42j漏洞的行为的。

上面的截图显示了一个攻击者利用漏洞，在目标上安装了base-64编码的，通过Christophe Tafani-Dereeper创建的一个有漏洞的应用实例。

这张截图显示了在Elastic Security中对CVE-2021-44228渗透的检测，详细说明了该渗透的警报和时间线视图。

上面的截图显示，在对检测警报的调查中，Java执行了一个shell脚本，下载并运行一个bash脚本。

来自社区的检测规则

参与讨论该被漏洞广泛利用话题的一些社区成员提供了一些早期检测方法与见解，分析人员可以利用这些方法来确定他们正在使用的系统是否已被利用或正在被积极利用。

GreyNoise团队分享了一系列有效攻击载荷，其中包括包含编码和解码变体的有效载荷，可供分析人员在其系统日志中进行检测。此外，还补充了一份试图利用该漏洞的初始标记IP清单。
Nextron系统公司的Florian Roth提供了一系列使用grep/zgrep进行本地检查的脚本，并在他Github账户上列出的一些初始YARA签名。Florian还分享了一种生成Thinkst CanaryTokens的方法，以测试你管理的系统的可渗透性。
Rob Fuller (Mubix)在这里分享了有漏洞的log4j版本的哈希值。

其他缓解策略

除了 Apache 团队关于部署最新的、修补过的 Log4j2 框架版本的推荐指南之外，还广泛建议了许多缓解措施来防止漏洞利用：

Fastly建议检查你的Log4j版本是否支持在JVM中用JAVA_OPTS=-Log4j2.formatMsgNoLookups=true- 禁用对远程服务器的查询功能。这应该适用于2.10.0到2.15.0版本。
为了防止从易受攻击的主机横向移动，或通过网络进行利用，建议限制从潜在易受攻击的系统到外部资源的连接，仅允许信任的应用程序和/或服务。