官方公众号企业安全新浪微博
FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。
FreeBuf+小程序
在Apache软件基金会去年11月披露Log4j漏洞一年后，虽然针对该漏洞本身的攻击数量低于最初的预期，但仍然对企业组织构成重大威胁。
安全研究人员说，仍然有很多系统没有针对该漏洞打补丁，企业在发现、修复和防止该漏洞上仍面临挑战。
"Contrast Security的首席安全信息官 David Lindner说："Log4j被用于约64%的Java应用程序，而其中只有50%的应用程序已经更新到完全固定的版本，这意味着攻击者将继续针对它。至少现在，攻击者继续在寻找通过Log4j进行攻击的途径。
攻击比预期的要少
Log4j的缺陷（CVE-2021-44228），通常被称为Log4Shell，存在于Log4j用于数据存储和检索的Java命名和目录接口（JNDI）。它可以帮助远程攻击者来控制易受攻击的系统。鉴于Log4J几乎被用于每一个Java应用环境，安全研究人员认为它是近年来最具威胁的漏洞之一，因为它很普遍，而且攻击者可以相对容易地利用它。
在过去的一年里，已经有许多关于攻击者利用该漏洞作为进入目标网络的报道。其中许多攻击涉及来自朝鲜、伊朗和其他国家的由国家支持的APT组织。例如，11月美国网络安全和基础设施安全局（CISA）警告说，一个由伊朗政府支持的APT组织利用未打补丁的VMware Horizon服务器中的Log4j漏洞，在一个联邦网络上部署了加密软件和凭证采集器。微软等其他公司也报告了类似的行为。
尽管还有其他一些关于有经济动机的网络犯罪团伙利用Log4j的报道， 但公开报道的涉及Log4的破坏事件的实际数量仍然比较低，特别是与涉及Exchange Server漏洞（如ProxyLogon和ProxyShell）的事件相比。Tenable公司的首席安全官Bob Huber说，相比于该漏洞的简单性和普遍的攻击路径，报告的攻击规模和范围出乎意料地低于预期。Huber说：只是在近期，我们才看到一些有针对性的重要报道，如最近CISA的民族性国家活动。
威胁未减弱
然而，安全研究人员指出，这并不意味着Log4j的威胁在过去一年中已经减弱。
首先，很大一部分企业仍然像一年前一样容易受到威胁。根据Tenable最近进行的一项与该漏洞有关的遥测分析显示，截至到10月1日，72%的企业容易受到Log4j的攻击，全球仅有28%的组织已经对该漏洞进行了全面修复。但当这些企业在向其环境中添加新的资产时，经常又一次地遭到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）一样重要。
参考来源：https://www.darkreading.com/application-security/one-year-later-log4shell-exposed-attack