Log4Shell仍然有尾巴刺

去年12月，IT员工的假期计划陷入混乱一个重大错误的披露在广泛应用中Log4j工具．这一发现导致了几个月的狂热活动修补脆弱性但一年过去了，它就销声匿迹了。安全专家说，这种威胁并没有消失，如果该行业不小心的话，这种威胁可能会卷土重来。

当它是第一个显示在2021年12月初，Log4Shell漏洞被描述为最严重的安全漏洞之一永远。它针对的是一种流行的工具，用于记录Java软件中的活动，旨在帮助跟踪错误和诊断性能问题。它广泛的实用性意味着Log4j已被嵌入到数千个软件包中，并在各种各样的商业服务中找到，包括亚马逊网络服务还有电子游戏我的世界．更重要的是，该漏洞使得攻击者能够相对简单地完全控制脆弱的系统。

这导致了一场疯狂的填补缺口的争夺战。Apache软件基金会，负责维护开源工具，迅速发布补丁，组织花了几个月的时间扫描他们的系统和更新他们的软件。但一年多后，网络安全公司Tenable表示，72%的组织仍然容易受到Log4Shell的影响．令人担忧的是，大量修复了该漏洞的组织后来通过安装易受攻击的软件将其重新引入到他们的系统中伯纳德蒙特尔他是Tenable公司的技术总监和安全策略师。

十二月的一天这这一年是自发现Log4j漏洞以来每天遭受攻击次数最多的一年。

他说:“大约一年前，当他们制定了一个修复计划时，他们以为自己已经做到了。”“他们清理了、识别了、扫描了、修补了软件，他们做了他们需要做的事情。他们只是忘记了攻击面正在移动的事实。”

据Tenable估计，易受攻击的机器比例已经从去年12月的十分之一下降到今年10月的2.5%。但其中多达三分之一已经被完全修补，并且已经被Log4Shell再次感染。Montel说，部分问题是Log4j深埋在许多常用软件库中。他补充说，通常不清楚某个工具中是否包含该实用程序，即使包含，大多数开发人员也没有足够的安全意识来检查它是否是最新的版本，特别是考虑到他们面临着快速生成代码的压力。安全公司Sonatype一年前的研究发现65%的下载量Log4j的漏洞都是易受攻击的工具版本。

在组织层面，Montel还认为，在最初几个月的巨大努力之后，一旦人们觉得他们已经解决了问题，他们就会失去注意力，这几乎是不可避免的。他认为，这与Covid-19大流行有明显的相似之处，当时封锁等严格措施迅速控制了病毒，但当形势再次放松时，病毒又会再次出现。“Log4j又回来了，”蒙特尔说。“它还在某处，所以只要观察海浪就行了。”

7月份的报告国土安全部网络安全审查委员会(Cyber Safety Review Board)的一名官员评估称，该漏洞已经成为“流行病”，可能会持续几年，甚至几十年。安全公司Imperva收集的数据显示，虽然利用该漏洞的攻击自2022年头几个月以来大幅下降，但却出现了自11月以来稳步增长年12月3日这这是自发现该漏洞以来单日攻击次数最多的一年。

一个可能的补救办法是:组织可以开始要求他们使用的所有代码都有一个软件材料清单

Imperva估计，这些攻击中约有7%是成功的。但是，尽管有一些高调的黑客攻击，包括由中国政府支持的黑客在三月和伊朗袭击美国联邦探员到目前为止，这个漏洞并没有达到去年所做的可怕预测。“尽管很多公司受到了影响，但影响远远小于预期，”他说加比StapelImperva的威胁研究分析师。尽管如此，它所做的事情揭示了许多公司对第三方和开源代码的依赖程度，而他们对这些代码几乎没有控制或可见性。斯塔佩尔说:“从历史上看，公司关注的是他们直接的供应商和他们所依赖的关键软件带来的风险。”“组织需要采用一个包括供应链所有部分的威胁模型。”

美国网络安全与基础设施安全局(CISA)负责网络安全的执行助理主任埃里克•戈尔茨坦(Eric Goldstein)表示，应对Log4Shell事件的成本和复杂性无疑推动了对保护软件供应链和提高透明度的日益关注。他说:“在过去的一年里，出现了许多新的工具、公司和产品，以帮助更好地理解软件依赖关系，Log4j经常被用作创新和采用的主要动机。”

中钢协一直在推动的一个潜在补救措施是软件材料清单(SBOM)。这是组成软件应用程序的所有组件的清单，旨在使开发人员更容易跟踪对潜在风险代码的依赖关系。美国政府已经发出信号，这些问题可能很快就会成为现实向联邦机构交付软件的要求．

不过，为了让这种方法真正产生影响，它需要进一步向上游发展布莱恩Behlendorf他是开源安全基金会(OSSF)的总经理，这样即使是开发人员组装来创建应用程序的原始开源软件包或库也有他们自己的soms。贝伦多夫表示，要做到这一点，可能需要新的工具来简化这一过程，并将其整合到现有的软件构建工具中，因为“让开发人员花费一些额外的努力可能是一个挑战”。

他说，整个行业还需要更好地协调，更积极地保护其所依赖的开源工具。Behlendorf说，单个项目根本没有资金或人力来做代码审查之类的事情。他说:“生态系统所接收到的价值与收集这些资源的能力之间存在脱节。”“我们需要的是能够汇集对这些事情进行更好审查的需求的机构，并将资源引导到有针对性的、容易实现的目标上。”

这就是为什么在五月份，OSSF和Linux基金会公布了一个开源软件安全动员计划，该报告强调了10个领域，在这些领域，少量的投资就可以极大地降低Log4Shell等漏洞的风险。这些措施包括为开发人员提供更好的安全教育，建立OSSF事件响应团队以帮助资源不足的开源团队对漏洞做出反应，以及对200个最关键的开源软件组件进行年度代码审查。

贝伦多夫说，实现这一目标需要来自行业和政府的大量资金。但他说，这将是一项明智的投资，如果没有某种协调，下一个Log4j问世的时间不会太长。