Log4j漏洞CVE-2021-44228披露后一年，对该漏洞的攻击并未停止

2021年11月Apache软件基金会披露Log4j漏洞已过1年，尽管针对该漏洞本身披露的攻击数量远低于预期，但它仍对企业组织构成重大威胁。

安全研究人员表示，仍有很大一部分系统未针对该漏洞进行修补，组织在发现、修复和防止该漏洞上仍面临挑战。

Contrast Security的首席安全信息官 David Lindner说表示："Log4j被用于近64%的Java应用程序，而其中只有50%的应用程序已经更新到完全固定的版本，这意味着攻击者将继续针对它发起入侵。至少目前，攻击者仍在继续寻找通过Log4j进行攻击的途径。

不断遭受攻击，但比预期的要少很多

Log4j漏洞（CVE-2021-44228），通常被称为Log4 Shell，存在于 Log4j 的 Java 命名和目录接口 （JNDI） 函数中，用于数据存储和检索。它为远程攻击者提供了一种非常简单的方法来控制易受攻击的系统 ， 考虑到Log4J几乎被用于每个Java应用程序环境。安全研究人员认为它是近年来最具威胁的漏洞之一，因为它的普遍存在以及攻击者可以相对容易利用它。

在过去一年，有许多关于攻击者利用该漏洞作为初始访问目标网络的方式进行报道。其中，许多攻击涉及来自朝鲜、伊朗和其他国家的由国家支持的高级持续威胁 （APT） 组织。例如，去年11月，美国网络安全和基础设施安全局（CISA）警告说，一个由伊朗政府支持的APT组织利用未打补丁的VMware Horizon服务器中的Log4j漏洞，在联邦网络上部署了加密软件和凭证采集器。此外，关于朝鲜Lazarus Group使用相同的载体在目标系统上部署后门分发自己的后门的警告以及微软等其他公司也报告观察到伊朗的磷组织等国家行为使用Log4在受感染的系统上投掷反向炮弹。

尽管还有其他一些关于有经济动机的网络犯罪团伙利用Log4j的报道， 但公开报道的涉及Log4的破坏事件的实际数量仍然较低，特别是与涉及ProxyLogon和ProxyShel等Exchange Server漏洞的事件相比。Tenable公司的首席安全官Bob Huber说，相比于该漏洞的简单性和普遍的攻击路径，报告的攻击规模和范围出乎意料地低于预期。Huber说：直到近期，我们才看到一些有针对性的重要报道，如最近CISA的民族性国家活动。

威胁一直都在，未曾减弱

安全研究人员指出，这并不意味着Log4j的威胁在过去一年中已经减弱。

首先，很大一部分企业仍然像一年前一样容易受到威胁。根据Tenable最近进行的一项与该漏洞有关的遥测分析显示，截至到10月1日，72%的企业容易受到Log4j的攻击，全球仅有28%的组织已经对该漏洞进行了全面修复。但当这些企业在向其环境中添加新的资产时，经常又一次地遭到Log4j的漏洞攻击。

在许多情况下（实际上是 29%），服务器、Web 应用程序、容器和其他资产在初始修复后不久就容易受到 Log4j 的攻击。

Huber说：假设企业在软件的构建管道中建立修复，那么再一次地遭到Log4j漏洞攻击的概率会减少。是否会再一次地遭到Log4j漏洞攻击很大程度上取决于一个企业的软件发布周期。

此外，尽管网络安全社群对这个漏洞的认识几乎无处不在，但由于应用程序如何使用Log4j，在许多企业中仍然很难找到有漏洞的版本。Sonatype公司首席技术官Brian Fox说，一些应用程序可能将开源日志组件作为其应用程序的直接依赖项，而在其他情况下，一些应用程序可能将Log4j作为一个交叉依赖项或另一个依赖项的依赖。

Fox说：由于过渡性依赖是从你的直接依赖项的选择中引入的，它们可能并不总是被你的开发人员所了解或直接看到。

Fox说，当Apache基金会首次披露Log4Shell时，公司不得不发出成千上万的内部电子邮件，在电子表格中收集结果，并递归扫描文件系统。这不仅仅花费了公司宝贵的时间和资源来修补该组件，而且延长了该漏洞的恶意影响程度。

来自Sonatype维护的Maven Central Java仓库的数据显示，目前35% 的 Log4 下载仍来自该软件的易受攻击版本。许多公司甚至在开始响应之前仍在尝试建立他们的软件清单，并且没有意识到传递依赖性的影响。

根据上述所有的问题，美国国土安全部审查委员会今年早些时候得出结论：Log4是一个地方性的安全风险，企业将需要与之抗衡多年。委员会成员评估说，Log4j的脆弱实例将在未来许多年里留在系统中，并使企业面临攻击的风险。

正面的影响

跟踪该漏洞的安全研究人员表示，Log4j的积极成果是它引起了人们对软件构成分析和软件材料清单（SBOM）等实践的高度关注。企业在确定他们是否有漏洞或在他们的环境中可能存在的漏洞时所面临的挑战，促进了人们更好地理解对其代码库中所有组件的可见性需要，特别是那些来自开源和第三方的组件。

ReversingLabs的CISO Matthew Rose说：对Log4J问题的调查再次证实，除了跟上DevOps速度的SBOMs之外，还需要更好的软件供应链证明。应用安全和架构团队已经意识到，仅仅在源代码、API或开放源码包等部分寻找风险是不够的。他们现在意识到，全面了解应用程序的架构与寻找SQLI或跨站脚本错误（XSS）一样重要。