2021年12月10日，Apache Java模块Log4j库第一个远程代码执行漏洞被公开披露，该漏洞识别为CVE-2021-44228。此外，还陆续披露了漏洞——CVE-2021-45046和CVE-2021-45105。

这并非危言耸听，Log4j可能会成为现代网络安全史上最严重的漏洞，至少是近十年来我们面临的最严重的漏洞。一旦漏洞被利用遭到入侵，将令企业陷入困境。鉴于 CVE-2021-44228 的普遍性以及容易被利用，并且随着新版本漏洞的出现，以及攻击者不断创新和适应，Log4j 中的远程代码执行漏洞并不能在短时间内被全部修复，可能需要数月甚至数年时间才能得到妥善解决。我们必须为“与漏洞共存”这个漫长的过程做好所有的准备。

更新：2022年1月20日

▪    更新了来自NHS Direct的警报，报告了对VMware Horizon的攻击。

▪    更新了Apache披露的影响Log4j 1.2的三个新漏洞的细节。

更新：2021年12月24日

▪    更新了Orange Cyberdefense的计算机安全事件响应团队（CSIRT）提供的更多技术细节，特别是针对攻击字符串混淆。

更新：2021年12月23日

▪    更新了包括一个勒索软件攻击者和一个银行木马在内的现有漏洞利用的新闻。

▪    更新了关于比利时国防部被攻击的新闻。

▪    反映了Blumira安全团队利用WebSocket JavaScript连接来触发漏洞利用的替代性攻击向量。

▪    更新了关于CISA漏洞扫描工具的内容，网址为https://github.com/cisagov/log4j-scanner

▪    更新了中国工业和信息化部（MIIT）对阿里云进行制裁的消息，原因是该公司在没有按照相关法律要求及时向中国相关部门报告其率先发现Apache Log4j2组件存在安全漏洞。

更新: 2021年12月18日

▪    添加了关于Log4j 2.17版本和CVE-2021-45105的信息。

更新：2021年12月17日

▪    首次提及Conti勒索软件运营商通过Log4j漏洞获得访问权。

▪    更新了显示CVE-2021-45046在某些条件下有可能导致远程代码执行的参考。

▪    添加内容：删除JndiLookup类是危险的，必须只考虑将其作为最终解决方案。

▪    提及了Log4j 2.17版本计划在一段时间内发布。

▪    更新了时间轴图形，以配合SharePoint网站的版本。

更新：2021年12月16日

▪    反映了CVE-2021-45046可能"在某些情况下允许敏感数据外泄"，并再次强调应尽可能升级到2.16.0版本。

▪    报告了荷兰政府CERT名单上已经有超过300个产品被报告存在漏洞，且接下来一周之前可能会达到500个。

▪    宣布我们现在通过GitHub（https://github.com/Orange-Cyberdefense/log4shell_iocs）公开分享自己的入侵威胁指标（IoC）。

更新：2021年12月15日

▪    强调我们现在建议升级到2.16版本以减轻威胁。

▪    报告了在某些非默认配置(CVE-2021-45046)下，第三个CVE编号被分配给2.15版本时存在绕过漏洞。显然，这里指的并非RCE，其已被2.16版本修复。

▪    反映了JNDI查询支持LDAP、RMI、DNS、甚至IIOP等协议，我们如今终于发现了使用IIOP的漏洞利用企图。

▪    强调log4j是一个库，因此我们无法通过"已安装"软件列表来100%确认。

▪    报告了一些新确认的产品，包括IBM、AWS和Zoho，并报告了来自CISA 和NCSC-NL的新追踪器。

▪    明确指出如果漏洞利用成功，JDNI字符串实际上不会被日志记录（因其是由Log4j日志来解译的）。

▪    反映了网络应用程序防火墙（WAF）可提供合理的保护，防止大多数已知的攻击。

▪    报告了Khonsari，这是一种新的、简单的勒索软件毒株，被认为是在Log4j攻击后进行部署的。

更新：2021年12月14日

▪    更新了一个攻击字符串的示例。

▪    明确指出了易受攻击的平台本身不一定是面向互联网的。任何提供log4j路径的远程访问界面都可以作为向量被漏洞利用。

▪    分享了iPhone/iCloud攻击示例以说明上述观点。

▪    强调了环境变量的攻击场景。

▪    更新了一张更完善的图片来解析攻击面。

▪    更新了时间线。

▪    更新了来自Nordic CyberSOC的事件趋势数据。

▪    更新了新的补丁细节。

▪    更新了SwitHalk Blueteam备忘单的链接，Orange Cyberdefense为此表做出了贡献。

▪    添加了漏洞决策树的内容。

▪    添加了 formatMsgNoLookups=true 这一暂时性解决方案的参考。

攻击面几乎是无限的，只要攻击字符串能找到易受攻击的组件。在一个实例中，在常用的Minecraft游戏平台上，只需在游戏聊天窗口中输入一个专门制作的信息，该漏洞就会被利用。在另一个具有启示性的示例中，一名研究人员表示，通过在iPhone设置界面的设备名称字段中插入适当的格式化字符串，苹果iCloud基础设施可能会遭受到攻击。还有一些说法提到可以通过向自动化后台系统发送短信来触发漏洞利用。在这些例子中，成功的漏洞利用方式是通过DNS回调来确认的，通过发出命令来解决攻击者监控下的域名中的DNS名称问题。

Apache log4j漏洞的消息在2021年12月10日被官方公开。然而，有证据表明，至少从12月1日起就有人试图利用这个问题，这表明在公开披露之前，这个漏洞利用已经在野利用了至少9天。我们日后也许还会发现这一漏洞利用甚至比这更早之前就已存在。

自12月10日被公开披露以来，已经发现并发布了几个漏洞利用，并且有广泛传播的通用扫描和目标攻击的报告。

12月13日Bitdefender报告称，他们发现有人试图利用log4j漏洞来部署一个新的勒索软件家族，他们称之为Khonsari（https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild）。后来发现，Kharen Konsari是一个真实的人，赎金条中显示的电话号码和电子邮件可能指向她。因此，整个事件可能只是一个精心策划的诡计。虽然我们还没有看到，但我们预计在不久的将来，勒索软件背后的攻击者会开始愤怒地利用这一漏洞。这类攻击已经被归结为国家级攻击者，类似Phosphorus、Nemesis Kitten和Hafnium。

12月17日，AdvIntel发表了一篇博客，声称Conti勒索软件团伙已经开始针对Log4j漏洞，并将其追踪为CVE-2021-44228。AdvIntel特别提到，Conti对同样包含这一漏洞的VMware vCenter Server和vCenter Cloud Gateway抱有兴趣。

截至12月23日，有两个新的恶意攻击者在野利用这一漏洞——一个勒索软件运营商和一个银行木马。

这一新的勒索软件运营商被称为"TellYouThePass"团伙。该勒索软件自2020年夏季以来一直处于休眠状态，但当发现新的大型漏洞时，它会经常被使用。例如，去年的永恒之蓝（Eternal Blue）就是这种情况。TellYouThePass不作为RaaS（勒索软件即服务）运作。

第二个利用这一漏洞的攻击者是Dridex，这是一个银行木马，最初是为窃取网上银行凭证而开发的。随着时间的推移，该恶意软件已发展成为一种更通用的恶意软件加载程序，尤其会被用来进行勒索软件攻击，据称这由Evil Corp 黑客团伙所主导。感染包括BitPaymer、DoppelPaymer和可能的其他勒索软件变种。

12 月 23 日也出现了第一批有关备受瞩目的受害者的报道。比利时国防部已确认利用 Log4j 漏洞对其网络进行攻击。

NHS Digital 于 2022 年 1 月 5 日发布警报，指出攻击者正在积极针对 VMware Horizon 服务器中的 Log4Shell 漏洞，以建立 Web Shell。他们报告说，这些攻击所利用的是嵌入在 VMware Horizon 中的 Apache Tomcat 服务的 Log4Shell 漏洞。

2022 年 1 月 18 日，Apache 披露了影响 Log4j 1.2 的另外三个严重漏洞的详细信息，针对Log4j 1.2的支持自 2015 年 8 月已截止，因此这些新漏洞将无法得到修复。新的漏洞是：

CVE-2022-23302：经过身份验证的远程攻击者可以利用它来启动可能会导致远程代码执行的 JNDI 请求；

▪.   CVE-2022-23305：远程攻击者可以通过包含特制 SQL 属性的查询，利用它来访问或更改数据库信息；

▪.   CVE-2022-23307：远程攻击者可以通过特制请求，利用它来执行任意代码。

这些漏洞（以及其他已知的 log4j 版本 1.x）有望说服开发者转而采用另一个安全的日志记录组件，例如最新版本的 Log4j 2版本 ，因为使用生命周期结束（End-of-Life）的代码代表着存在较高的风险会遭入侵。幸运的是，目前还没有针对这些漏洞的在线漏洞利用代码。

您的底线很简单：首先，您可能在过去某个时候已经成为了此漏洞利用的攻击目标。其次，您面向互联网的网络系统肯定会面临如此境况，仅对漏洞的一般表现形式进行扫描，亦或可能对僵尸网络或加密货币矿工等常见的形式进行扫描，从而遭到入侵。最后，您应该预计在不久的将来，该漏洞将在更为复杂的针对性攻击中被利用，并且一旦以其他方式完成初始攻击，就会在您的网络中横向移动。

您需要找到所有 log4j 实例并将其升级到2.17.0版本以上以缓解所有已识别的威胁。

Log4j 版本 2.16.0 于 2021 年 12 月 14 日发布。这解决了版本 2.15.0 中修复的远程代码执行漏洞。在某些非默认配置下，已将第三个 CVE 编号 (CVE-2021-45046) 分配给了 2.15 版本的漏洞。因此，2.15 及更早的版本被认为是不安全的，我们强烈建议至少升级到 2.16.0 版本。

此外还报告了一个影响版本 1.x 的漏洞，但没有影响 v2.x 的漏洞那么严重，因为需要一组特定的条件才能利用它。此错误已分配了不同的 CVE 编号 (CVE-2021-4104)，但版本已终止，应尽可能升级到最新分支。

12 月 17 日，Apache Log4j 团队发布了 2.17.0 版本，以解决被跟踪为 CVE-2021-45105 的本地拒绝服务漏洞。自 2021 年 12 月开始以来，此漏洞已获得了4个CVE编号。该漏洞是特定配置的结果，由于该库的模式处理部分中的逻辑缺陷，可能导致“不受控制的递归自引用查找”。攻击者可以利用此漏洞使应用程序无法使用或使其不稳定。Apache 提供的缓解措施可用于通过配置解决此问题。

为了解决所有这些易受攻击的版本，截至 2021 年 12 月 17 日，Java 8 的推荐 Log4j 版本是 2.17.0 或更高版本，而 2.12.2 或更高版本仍然是 Java 7 的首选版本。CVE-2021-45105 不影响2.12.2 版。

另请注意，Java 7 于 2022 年 7 月（2011 年发布）和 Java 8 于 2030 年 12 月结束生命周期。

最初，人们认为更高版本的 Java 具有保护功能，但在2021年 12 月 14 日星期二log4j爆出之后发现情况并非如此。

有各种商业和免费工具可用于“扫描”易受攻击的 log4j 实例。由于各种原因，此类扫描工具的结果会有所不同。美国网络安全和基础设施安全局 (CISA) 以 Python 脚本形式发布了一个更有用的免费扫描选项，可在此处找到：https://github.com/cisagov/log4j-scanner。然而，正如我们上面提到的，远程扫描不足以识别您环境中的此漏洞。

已讨论的一种缓解措施是从 Log4j 模块中删除有问题的类。请尽量避免走这条路。只有在您评估了影响之后，才能将此操作视为最后的手段，因为你不知道删除了一个类会对您的系统造成多大的影响。Apache Log4j 团队提供了有关如何删除 JndiLookup 类的说明。手动删除类可能会破坏或破坏应用程序的稳定性。这是解决问题的极端方法，但必须暂时处理。您需要跟踪修改后的工件，以确保以后不会重新引入该漏洞。

修改JAR、WAR 或EAR文件等已签名的Java工件将导致应用程序在启动时失败，因为组件的完整性受到影响。此行为符合设计，可防止代码修改。在处理 WAR 和 EAR 文件中的嵌套 Java 代码工件时，您需要隐秘地遍历每个文件以找到 JndiLookup 类。系统上可能还存在提取的 WAR 或 EAR 文件的缓存副本。这些将需要被删除。在大多数情况下，重新启动受影响的应用程序是更改反映的唯一方法，因为 Java 类加载器会将此文件缓存在内存中。