超过 30% 的 Log4J 应用程序使用存在漏洞的版本库

Bleeping Computer 网站消息 ，超过大约有 38% 采用 Apache Log4j 库的的版应用程序使用的是存在安全问题的版本，其中包括 Log4Shell 漏洞，应用程用存该漏洞被追踪为 CVE-2021-44228 ，序使尽管两年多前就有了修补程序，漏洞但目前的本库严重程度仍达到了最高级别 。

Log4Shell 是超过一个未经验证的远程代码执行 (RCE) 漏洞，攻击者可以利用其完全控制使用 Log4j 2.0-beta9 及以上版本 2.15.0 的的源码下载版系统。2021 年 12 月 10 日 ，应用程用存研究人员首次发现 Log4Shell 安全漏洞作 ，序使其广泛的漏洞影响、易利用性和巨大的本库安全影响在当时引起了行业巨大的“震动”。

研究人员在发现安全漏洞问题后，超过立刻向所有受影响的的版项目维护者和系统管理员发出了安全通知，然而坏消息是应用程用存，虽然发出了无数警告依然有大量组织在补丁可用后继续使用易受攻击的版本
。免费模板更糟糕的是，漏洞披露和修复程序发布两年后 ，仍有大量目标易受 Log4Shell 影响 。

应用程序安全公司 Veracode 根据 8 月 15 日至 11 月 15 日期间收集的数据 ，编写了一份安全报告，在报告中，Veracode 强调 Log4Shell 安全漏洞带来的影响可能会持续很长一段时间  。

Veracode 从 3866 个组织收集了 90 天的数据信息，这些组织使用 38278 个依赖 Log4j 的应用程序 ，版本在 1.1 到 3.0.0 之间
。建站模板 在这些应用程序中，2.8% 使用 Log4J 版本 2.0-beta9 至 2.15.0 ，这些版本及其容易受到 Log4Shell 漏洞的直接影响。另有 3.8% 的应用程序使用 Log4j 2.17.0 
，虽然这个版本不会受到 Log4Shell 漏洞的影响  ，但却容易受到 CVE-2021-44832 漏洞的影响（CVE-2021-44832 是一个远程代码执行漏洞，已在该框架的 2.17.1 版本中得到修复。）

32% 使用的是 1.2.x 版 Log4j ，服务器租用该版本自 2015 年 8 月起已经停止支持更新 ，这些版本易受 2022 年之前发布的多个严重漏洞的影响
，其中包括 CVE-2022-23307、CVE-2022-23305 和 CVE-2022-23302等安全漏洞
。

Veracode 还发现，在其可见范围内，总共约有 38% 的应用程序使用了不安全的 Log4j 版本 ，这一比例与 Sonatype 的软件供应链管理专家在其 Log4j 面板上报告的情况非常接近，过去一周时间里，该库 25% 的高防服务器下载涉及到有漏洞的版本 。

Log4j 版本下载 (Sonatype)

根据 Veracode 的调查结果，79% 的开发人员选择在第三方库首次纳入代码库后则不再更新，以避免破坏功能 。值得一提的是，即使 65% 的开源库更新包含不太可能导致功能问题的小改动和修复  ，开发人员也不愿意更新。

此外，研究还表明 50% 的云计算项目需要 65 天以上的时间来解决高严重性安全漏洞
，在人员不足的情况下 ，修复积压项目中一半的漏洞需要比平时多花 13.7 倍的时间，而在缺乏信息的情况下 ，处理 50%的漏洞需要 7 个多月的时间。

不幸的是，从 Veracode 的调查数据来看，Log4Shell 安全漏洞并没有像许多安全从业者希望的那样敲响安全“警钟”。恰恰相反，目前每三个 Log4j 案例中就有 1 个存在安全风险 ，而且很容易成为威胁攻击者入侵特定目标的途径之一 。

最后，安全研究专家强烈建议企业及时扫描其网络环境，找出正在使用的开源库版本 ，然后为所有这些库制定紧急升级计划 。

参考文章：https://www.bleepingcomputer.com/news/security/over-30-percent-of-log4j-apps-use-a-vulnerable-version-of-the-library/