CVE-2018–8414：负责任披露的案例研究
漏洞披露过程可能充满挫折、伦理担忧和沟通失败。我有许多漏洞报告进展顺利，也有许多进展糟糕。我通过赏金计划（Bugcrowd/HackerOne）和直接报告渠道（微软）提交了许多漏洞。我不是来讨论伦理的，也不是来为“漏洞披露”大辩论提供解决方案的。我只是来分享一个让我印象深刻的经历，并希望它能引起所有供应商对报告流程的一些反思。
首先，我想简单介绍一下我自己以及我与漏洞研究的关系。我不是经验丰富的逆向工程师，也不是全职开发者。我精通C/C++吗？不。我相对较新进入这个行业（3年）。我牺牲空闲时间进行研究，以弥补知识差距。我不寻找疯狂的内核内存泄漏，而是寻找经常被忽视的用户模式逻辑漏洞（DACL覆盖漏洞，有人知道吗？）。最重要的是，我将漏洞研究（VR）作为一种爱好，以学习我感兴趣的技术概念，这些概念不一定直接适用于我的日常工作。虽然有限，但我的VR经历带来了和其他人一样的痛苦。
当我报告漏洞时，过程通常如下：
- 发现漏洞 -> 披露漏洞 -> 供应商对漏洞睁大眼睛 -> 漏洞被修复并可能发布CVE（带有相关致谢）-> 案例关闭
- 发现漏洞 -> 披露漏洞 -> 供应商未能看到影响，发布“不会修复” -> 案例关闭
在查看这两种情况时，有多种因素可以决定你的报告属于第1种还是第2种。这些因素可能包括：
- 供应商内部政治/重组
- 案例处理人员经验/职业道德/沟通（!!!!）
- 报告质量（你是否很好地解释了漏洞，并概述了漏洞对产品的影响？）
当你无法控制的因素反复出现时，它们会开始引起挫折感。这是供应商需要对其流程开放反馈，研究人员需要对其报告开放反馈的地方。
因此，让我们看一个漏洞报告出错的案例研究（随后得到纠正）：
2018年2月16日下午2:37，我发送了一封电子邮件到secure@microsoft.com，附带了Windows 10上.SettingContent-ms文件格式中RCE的详细说明和PoC。以下是原始电子邮件：
这种情况是研究人员需要开放反馈的好例子。回顾我的原始提交，我主要围绕Office 2016的OLE阻止列表和Windows Defender中攻击面减少规则的绕过来构建漏洞。然而，我在电子邮件中确实提到了“PoC zip包含武器化的.settingcontent-ms文件（允许从互联网执行代码，且用户无安全警告）”。这是非常重要的一行，但它被电子邮件的其余部分掩盖了。
2018年2月16日下午4:34，我收到了微软的模板回复，称已分配案例编号。我的理解是，当案例处理人员接手（或被分配）你的案例时，这封电子邮件是相当自动化的：
很好。在这一点上，这只是一个等待游戏，而他们正在分类报告。等待一段时间后，我在2018年3月2日下午12:27收到一封电子邮件，称他们成功复现了问题：
太棒了！这意味着他们能够使用我的详细说明和PoC确认其有效性。在这一点上，许多研究人员感到沮丧。你花时间找到漏洞，花时间报告它，几乎立即得到供应商的回应，一旦他们复现了，事情就变得安静了。这是可以理解的，因为他们可能正在对问题进行根本原因分析。这是决定漏洞是否值得修复的关键点。
我承认，我通常遵守Google Project Zero使用的90天政策。我不为GPZ工作，我也不靠找漏洞（或管理多个报告）获得报酬。如果沟通存在，我倾向于宽容。如果供应商不与我沟通，我将在90天窗口关闭后的第二天发布博客文章。
供应商们，请与你们的研究人员沟通！
在这种情况下，我做了许多研究人员在超过一个月没有任何消息时会做的事情……我要求更新：
在这一点上，我已经几乎一个半月没有听到任何消息。在要求更新后，这封电子邮件进来了：
有趣……我突然有另一个人处理我的案例？我可以理解这一点，因为微软是一个庞大的组织，有各种人员处理他们每天收到的大量报告。也许我的案例处理人员被淹没了？
让我们暂停并评估到目前为止的情况：我报告了一个漏洞。这个漏洞被分配了一个案例编号。我被告知他们复现了问题，然后我一个半月没有听到任何消息。在联系后，我发现案例被重新分配了。为什么？
供应商们，这就是引起挫折感的原因。研究人员感觉被拖着走，被蒙在鼓里。如果你不希望0day最终出现在Twitter上，沟通是关键。实际上，我们中的许多人牺牲个人时间在你的产品中寻找漏洞。如果人们觉得他们不重要或被搁置，他们就不太可能向你报告漏洞，更可能出售它们或将它们放到网上。
好吧，所以我的案例在2018年4月25日下午12:42被重新分配。几天后我说“谢谢！！”，并让案例搁置，而他们处理漏洞。
然后，一个多月过去了，没有任何消息。在这一点上，自从我提交原始报告以来已经超过90天。作为回应，我在2018年6月1日下午1:29发送了另一个跟进：
几天后，我在2018年6月4日上午10:29得到了回应：
好吧。所以，让我们从头开始。2018年2月16日，我报告了一个漏洞。在经过典型的开案和验证问题过程后，我在一段时间没有回复后随机被重新分配了一个案例处理人员。然后，在等待一段时间后，我仍然没有听到任何消息。所以，我跟进并在初始报告整整111天后得到了一个“不会修复”的回应。
我首先承认，一旦案例关闭，我不介意写博客谈论某事。毕竟，如果供应商不在乎修复它，那么世界应该知道它，在我看来。
鉴于那个回应，我于2018年7月11日继续写了博客。在我发布帖子后，我很快被Twitter上的另一位研究人员联系，让我知道我的博客文章由于.SettingContent-ms文件格式的Mark-of-the-Web（MOTW）影响导致了Chrome和Firefox的0day。鉴于这个新信息，我在2018年6月14日上午9:44向MSRC发送了一封新电子邮件：
在这一点上，我看到两个利用.SettingContent-ms文件格式影响Google Chrome和Mozilla FireFox的漏洞。在重新发送细节后，我在2018年6月14日上午11:05收到一封电子邮件，其中MSRC通知我案例将被更新：
2018年6月26日下午12:17，我向MSRC发送了另一封电子邮件，让他们知道Mozilla由于该漏洞发布了CVE-2018-12368：
同一天，MSRC通知我额外的细节将被传递给团队：
这是事情真正转折的地方。我在2018年7月3日晚上9:52收到另一封电子邮件，称我的案例再次被重新分配，并且他们正在基于各种其他MSRC案例、Firefox CVE和Google Chrome的待定修复重新评估案例：
这是同情可以发挥作用的地方。我们都只是做工作的人。虽然我经历的过程很糟糕，但我不 bitter 或生气。所以，我的回应是这样的：
一段时间后，我意识到一些犯罪软件团体以一些非常糟糕的方式利用该技术（https://www.proofpoint.com/us/threat-insight/post/ta505-abusing-settingcontent-ms-within-pdf-files-distribute-flawedammyy-rat）。在看到它在野外被使用后，我让MSRC知道：
MSRC很快让我知道他们将尽快发布修复……这与原始报告评估完全相反：
此外，还提到了“另一个MSRC案例线程上的另一封电子邮件”。这 definitely piqued 我的兴趣。几天后，我收到一封奇怪的电子邮件，带有与最初分配不同的案例编号：
在这一点上，我的下巴掉到了地上。在向一个关闭的MSRC案例发送一些额外信息后，漏洞从“不会修复”变成了“我们将尽快发布修复，并奖励你赏金”。在与微软赏金团队进行一些小的物流交流后，我看到CVE-2018-8414在cve.mitre.org上占据了一席之地。这非常有趣，因为不到一个月前，该问题还处于“不会修复”状态。所以，我问了MSRC关于它：
这时我很快发现CVE-2018-8414是为.SettingContent-ms RCE漏洞发布的：
这是过程变得酷的地方。之前，我披露了一个漏洞。那个漏洞被给予了“不会修复”状态。所以，我写了博客（https://posts.specterops.io/the-tale-of-settingcontent-ms-files-f1ea253e4d39）。然后我发现它被用来利用2个浏览器，并且它在野外被使用。我没有让事情搁置，而是主动与MSRC联系，并让他们知道所有这些。一旦8月补丁星期二到来，我收到了这封电子邮件：
耶！！！所以微软基于我提供的