漏洞公告：Apache Log Binary（Log4J）

11 年 2021 月 XNUMX 日 | , 博客

Apache 中的 Log4J 漏洞

22 年 2022 月 4 日：Log4j、LogXNUMXShell 漏洞详情更新

CISA 刚刚发布了新的公告：https://www.cisa.gov/uscert/ncas/alerts/aa21-356a

在我25多年的网络安全生涯中，我从未想过像Log4j这样，需要处理如此多的关键补丁更新。Code Red、MS Blaster、SQL Slammer、Melissa，以及最近的HeartBleed或Exchange Server 2021，修复失败的次数有这么多吗？

修复历史记录（最近 10 天）

log4j 2.15.0 发布后不久，研究人员发现了拒绝服务条件漏洞。后续研究表明，这些 DOS 条件实际上可能是远程代码执行漏洞（哎呀！）。这促使 2.16.0 版本发布，软件开发人员争相测试该版本。

22 月 2.17.0 日，发现了一种新的 DOS 条件，导致 Java 8 发布了 XNUMX 版本。其他版本针对旧版本的 Java 发布了。

第三方供应商曝光？

到目前为止，Log12j 事件已经过去 4 天了，如果您的供应商尚未明确声明他们没有受到 Log4j 威胁，那么您必须假设他们已经暴露在风险之中，并忙着用最新版本 2.17 来修补漏洞。这会对您的公司造成什么影响？

开始考虑关闭可能暴露的应用程序上的这些服务。寻找入侵指标。请查看 CISO 在其最新公告 (开始).

CyberHoot 建议：

如果您的公司面临 log4j 漏洞，您需要考虑您的服务器可能已经受到攻击。这 CISO 咨询提出了一些值得遵循的建议，包括寻找妥协指标。

CyberHoot 非常担心黑客可能会趁着假期发动勒索软件攻击等，趁人们不注意窃取我们的数据和身份信息。现在正是修复、打补丁和寻找入侵迹象的时候。祝你好运！

CyberHoot 11 月 XNUMX 日的原始帖子

互联网上正出现一个严重等级为 10（最高）的漏洞。该高危漏洞名为“Log4Shell”，存在于 Apache Log4j（版本 2.0 至 2.14.1）中，并于 9 年 2021 月 4 日披露。Log1j 由 Apache 软件基金会开发，该基金会运行着近三分之一的网站。Log3Shell (CVE-2021-44228) 允许在易受攻击的服务器上执行远程代码。

CyberHoot 的漏洞警报管理流程 (VAMP) 评估了此风险，将其评定为 0 级事件，并将其上报给我们的 vCISO 客户和 MSP 以采取行动。由于 CyberHoot 中未使用任何 Log4j Java 代码，因此我们自己的服务器不存在风险。

如何回应：

公司应该验证他们没有运行任何暴露的 Log4j Java 代码。以下是受影响的第三方软件供您参考。如果您发现服务器存在风险，有以下三种潜在的修复方法。

三种潜在解决方案

1. 升级 Log4j： 将 log4j 修补至 2.15.0 及更高版本可解决风险，但需要访问受影响的 Apache 服务器并重新启动 Apache。

2. 配置更改： 在 Log4j 版本（>=2.10）中，可以通过设置系统属性来缓解此漏洞 log4j2.formatMsgNoLookups 至 true 或者从类路径中删除 JndiLookup 类。此外，如果服务器的 Java 运行时版本 >= 8u121，则默认情况下，设置 com.sun.jndi.rmi.object.trustURLCodebase 和 com.sun.jndi.cosnaming.object.trustURLCodebase 设置为“false”，以减轻这种风险。

3. 使用疫苗来保护你的服务器: CyberReason一家网络安全公司发表了一种可修补/接种的疫苗受影响的服务器消除了利用此漏洞的可能性。