公开漏洞披露——即向全世界揭示某个软件、库、扩展等中存在错误的行为，并发布利用它的 PoC——经常发生，涉及范围广泛的漏洞软件，从最深奥的到最普通的（和广泛使用的）。

随着时间的推移，研究和经验表明，威胁行为者是唯一从 0-DAY的PoC 的公开发布中受益的人，因为这种事件会突然让相关公司陷入尴尬的境地，不得不缓解该问题（即供应商的补丁）。

负责任的漏洞披露通常如何运作？

目前存在各种负责任的漏洞披露机制。一些公司有一个官方批准和广泛宣传的漏洞披露计划，也有公司通过众包平台组织和运行它。通常，公司会为有关其产品漏洞的信息（也称为“漏洞赏金”）提供奖金。

这些披露通常要经过一个特定的过程，并且有明确定义的供应商补丁发布时间表，以便用户有足够的时间来实施它（90天是公认的标准）。通常还规定，PoC只能在获得供应商批准的情况下公开发布（这也称为“协同披露”）。最重要的是，漏洞赏金平台有时会要求参与的安全研究人员同意保密协议，这意味着即使漏洞早已修复，PoC也可能永远不会发布。

向受影响的供应商披露漏洞的过程通常遵循以下顺序（如果一切顺利）：

  • 研究人员将漏洞告知供应商并提供相应的PoC

  • 供应商确认漏洞的存在并提供补丁发布的大致时间表

  • 一旦开发出修复程序或补丁，供应商会要求研究人员确认修复程序是否有效

  • 在研究人员“确认”补丁有效后，供应商实施补丁

  • 如果厂商同意，补丁发布后一定时间可以公布漏洞详情（90天以内都是通常的惯例）

关于Log4Shell漏洞，当它被公开披露时，披露过程已经在进行中（如11月30日在 GitHub上出现的证明）。根据Apache软件基金会提供的信息，披露的时间线如下所示：

  • 11 月 24 日：通知Log4j维护者

  • 11 月 25 日：维护者接受了报告，保留了CV，并开始研究修复

  • 11 月 26 日：维护人员与漏洞报告者沟通

  • 11 月 29 日：维护人员与漏洞报告者沟通

  • 12 月 4 日：已提交更改

  • 12 月 5 日：已提交更改

  • 12 月 7 日：创建第一个候选版本

  • 12 月 8 日：维护人员与漏洞报告者沟通，进行了额外的修复，创建了第二个候选版本

  • 12 月 9 日：补丁发布

虽然用户在Apache Log4j GitHub项目页面上的评论表明对修复的速度感到沮丧，但在修复漏洞方面，这是个规范的过程——正如每个人不断指出的那样，补丁毕竟是由志愿者构建的。

发布0-day漏洞PoC的原因以及反对它的论据

发布0-day漏洞的PoC 可能有合法且可以理解的原因。其中最常见的是漏洞披露流程的中断：供应商可能没有响应或可能停止响应，可能认为漏洞不够严重，需要修复，可能需要太长时间来修复——或任何以上的组合。在此类情况下，安全研究人员通常会为了“共同利益”而决定发布 PoC，即迫使供应商快速发布修复程序。

可能还有其他原因，例如宣传（特别是如果研究人员与安全供应商有联系）——没有什么比对广泛使用的软件进行0-day漏洞披露更快的新闻报道了，尤其是在没有可用补丁的情况下。

但必须指出的是，现在反对发布漏洞PoC的证据是强有力的和压倒性的。

Kenna Security完成的一项研究表明，发布漏洞PoC对攻击者最有利。2017年，Black Hat上的一次演讲回顾了零日漏洞的生命周期以及它们是如何被发布和被利用的，并表明如果漏洞PoC不公开，所涉及的漏洞通常平均7年不会被其他任何人（包括威胁行为者）发现。这项研究由兰德公司主持。

由Kenna Security公司和Cyentia Institute共同完成的最新报告《预测的优先次序》第七卷:建立防守者优势》解释了这一发现。Kenna Security是基于风险的漏洞管理领域的企业领导者，Cyentia Institute为网络安全领域持续时间最长的争论问题提供了明确的答案。

Kenna Security创始人兼首席技术官埃德•贝利斯(Ed Bellis)表示，这项数据驱动的研究历时数年，应该可以消除任何疑虑。长期以来一直是网络安全生态系统核心的做法，我们很多人认为是有益的，但实际上对防御者是有害的。

多年来，网络安全行业一直依靠“白帽”黑客来识别潜在的漏洞，并开发利用代码来证明安全漏洞不仅仅是理论。在大约三分之一的情况下，这些代码会在软件开发人员发布补丁之前公开。几十年来，软件开发人员和安全研究人员一直在争论，这种做法是否能提高整体安全性，因为它能识别出漏洞并促使安全团队对其进行修补，还是因为它本质上为攻击提供了一个路线图，从而使攻击者获得了优势。

研究发现，当漏洞代码出现在补丁之前时，攻击者比防御者获得了98天的优势——也就是说，攻击者针对漏洞资产实施漏洞利用的时间，比防御者采取缓解措施止损的时间，要早三个月以上。

可悲的是，这在log4j争夺期间意识到有点太晚了。最初的推文和披露被迅速退回，但危害已经造成。即使是导致补丁2.17.1发布的最新漏洞披露也受到了安全社区的强烈抨击，以至于研究人员公开道歉，因为披露时机不当。

公开披露漏洞PoC的态度已经发生转变，这是令人欣慰的。对决定采取行动的研究人员的批评是值得的，但总的来说，安全社区需要专注于为每个人设置更强大的披露流程，以便下次发现类似Log4Shell这类漏洞时不会重蹈公开PoC的覆辙。

参考来源

1、https://www.helpnetsecurity.com/2022/01/06/log4j-debacle/

2、https://www.kennasecurity.com/news/publishing-exploits-does-more-harm-than-good-new-research-finds/

声明：本文来自网空闲话，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。