独家：Log4j将彻底改变漏洞披露游戏规则
2021年12月9日，一条推文（现已删除，GoUpSec分析师留有截图）链接到GitHub的Log4j零日漏洞（Log4Shell）的概念证明利用(PoC)（该Github账户现已删除，GoUpSec分析师留有截图），虽然在漏洞补丁发布前一周，大约12月1日-2日，就有思科talos等国外网络安全公司发现Log4Shell存在野外利用，但真正让互联网和全球企业网络安全部门燃起熊熊大火的，正是12月9日这个PoC的“首发”（下图）。
工信部12月22日发通报暂停阿里云公司作为工信部网络安全威胁信息共享平台合作单位6个月，作为对阿里云违反今年发布的网络产品安全漏洞管理规定的处罚。因为，阿里云11月24日就向Apache软件基金会通报漏洞，但直到15天后的12月9日漏洞补丁发布，工信部网络安全威胁和漏洞信息共享平台才通过有关网络安全专业机构报告得知Apache Log4j2组件存在严重安全漏洞，向行业单位进行风险预警。
与《南华早报》及大量海外网络媒体报道声称的”阿里云因未能第一时间向工信部汇报而遭受处罚”不同，GoUpSec认为，阿里云第一时间向Apache汇报漏洞并未违反《网络产品安全漏洞管理规定》中第七条第一款：“对属于其上游产品或者组件存在的安全漏洞，应当立即通知相关产品提供者。”阿里云违反的是第七条第二款：“应当在2日内向工业和信息化部网络安全威胁和漏洞信息共享平台报送相关漏洞信息。”
谁需要为“该死的”PoC披露负责
以上对Log4j漏洞披露时间主节点的简要回顾，并非认定阿里云安全团队需要为Log4j漏洞引发的巨大安全灾难负责。相反，我们认为阿里云安全团队虽然违反了国内的相关漏洞管理规定，但是作为安全团队能够发现史诗级的重大开源漏洞并第一时间报告给开源社区，帮助Apache数天内就推出补丁（虽然第一版补丁引入了新的漏洞），这部分工作客观上是值得称赞的，也从一个侧面表明我国网络安全企业的技术能力已经跻身世界一流。
让事态失控的并不是阿里云的漏洞汇报，而是那个导致大规模漏洞利用的漏洞PoC“首发”（编者：PoC往往也是漏洞公开披露的一部分），该PoC的发布甚至早于12月9日当时Log4j漏洞的CVE编号分配！GoUpSec从目前互联网公开的残存信息中尚无法精准溯源这个“抢发“PoC的黑客的具体身份（这在安全社群内是半公开的秘密）。但我们可以确定的是，从目前的舆论监测来看，全球网络安全业界都开始集体反思和谴责这次PoC”零日披露“行为。
黑客才是PoC披露的受益者
CDL的首席信息安全官Haynes指出，随着时间的推移，研究和经验告诉我们，黑客和威胁行为者是唯一从零日PoC的公开发布中受益的人，根据CheckPoint和Sophos安全团队的监测，12月9日漏洞PoC公开披露后，就像打开了潘多拉盒子，“蜜罐中涌入了大量攻击者，数日内产生超过60个漏洞利用变种，不到一周时间全球40%的企业就遭遇了Log4j漏洞利用攻击”。这使全球企业、政府、关键基础设施甚至消费者都处于极为尴尬和危险的境地，不得不手忙脚乱地缓解漏洞。
对于Log4j漏洞来说，更加糟糕的是第一版补丁（2.15rc）本身并不完善，引入了其他漏洞，目前的最新版本已经迭代到2.17.1。漫长颠簸而复杂巨量的修补工作也给黑客的漏洞利用留下了充裕的时间和空间，不少安全专家预测，Log4j漏洞将成为互联网的慢性癌症长期困扰全球企业的安全团队。
负责任的漏洞披露通常如何运作？
目前存在各种负责任的漏洞披露机制。一些企业会发布一个官方批准和广泛宣传的漏洞披露计划，也有企业则选择通过众包平台来实施类似的项目。通常，公司会为有关其产品漏洞的信息提供资金（也称为“漏洞赏金”）。
这些披露通常要经过一个特定的过程，并且有明确定义的供应商补丁发布时间表，以便用户有足够的时间来实施它（90天是公认的标准）。通常还规定，PoC只能在获得供应商批准的情况下公开发布（这也称为“协调披露”）。最重要的是，漏洞赏金平台有时会要求参与的安全研究人员签署保密协议，这意味着即使漏洞早已修复，PoC也可能永远不会发布。
向受影响的供应商披露漏洞的流程通常如下（如果一切顺利）：
- 研究人员将漏洞告知供应商并提供随附的PoC
- 供应商确认漏洞的存在并提供修复发布的大致时间表
- 一旦开发出修复程序，供应商会要求研究人员确认修复程序是否有效
- 在研究人员“确认”修复后，供应商实施补丁
- 如果厂商同意，补丁发布后一定时间可以公布漏洞详情（90天以内都是正常的）
关于Log4j漏洞，当它被公开披露前，PoC披露过程已经在进行中（11月30日在GitHub上出现的pull request可以证明）。根据Apache软件基金会提供的信息，披露的时间线如下所示：
11月24日：通知Log4j维护者
11月25日：维护者接受了报告，保留了CV，并开始研究修复
11月26日：维护人员与漏洞报告者沟通
11月29日：维护人员与漏洞报告者沟通
12月4日：已提交更改
12月5日：已提交更改
12月7日：创建第一个候选版本
12月8日：维护人员与漏洞报告者沟通，进行了额外的修复，创建了第二个候选版本
12月9日：补丁发布
虽然大量用户在Apache Log4j GitHub项目页面上的评论表明对修复速度感到沮丧，但这已经算是很快的响应了——毕竟，这个补丁也是由志愿者开发的。
漏洞披露如何避免“核泄漏”悲剧
发布零日PoC可能有合法且可以理解的原因，其中最常见的理由是漏洞披露流程崩溃：供应商可能没有或可能停止响应，可能认为漏洞不够严重，需要修复，可能需要很长时间才能修复——或任何以上的组合。在此类情况下，安全研究人员通常会为了“共同利益”而决定发布PoC，即迫使供应商快速发布补丁程序。
零日漏洞PoC的发布往往还有其他原因，例如宣传（特别是如果研究人员与安全供应商有联系，或者在其中就职）——对于企业（某些情况下是个人）来说，没有什么比披露重大漏洞的零日PoC更棒的宣传效果了，尤其是在没有可用补丁的情况下。
但必须指出的是，现在安全业界对发布漏洞PoC漏洞的反对意见，无论从证据还是口风来看，都已经是压倒性的了。
Kenna Security完成的一项研究表明，发布PoC漏洞利用主要有利于攻击者。几年前，Black Hat的一次演讲回顾了零日漏洞的生命周期及其如何被释放和被利用，并表明如果漏洞PoC不公开，所涉及的漏洞通常平均7年内都不会被其他任何人发现（包括黑客）。
可悲的是，log4j漏洞PoC的发布者（们）显然没有意识到这一点，最初抢发漏洞PoC的推文和GitHub链接（编者：甚至连账户一起）被迅速删除，但造成的严重后果已经无法挽回。对这种伤害的集体反思导致补丁2.17.1发布的最新披露也受到了安全社区的强烈抨击，以至于研究人员公开道歉，因为披露时机不当（下图）。
值得欣慰的是，经历Log4j漏洞的互联网大地震后，业界对公开披露PoC漏洞的放任态度已经发生彻底转变，对那些急于表现自己的研究人员的严厉批评已经成为共识。但批评并不能解决问题，网络安全业界接下来要面临的一个重大议题就是为每个研究者和道德黑客设置更明确、强硬、可靠的披露流程，以便下次发现类似Log4Shell这种超级漏洞时，悲剧不会重演。
参考链接：
网络产品安全漏洞管理规定：
http://www.gov.cn/zhengce/zhengceku/2021-07/14/content_5624965.htm
南华早报：中国工信部因阿里云未先向政府报告漏洞处罚阿里云
