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的待定修复重新评估案例：
这是同情可以发挥作用的地方。我们都只是做工作的人。虽然我经历的过程很糟糕，但我并不苦涩或生气。所以，我的回应是这样的：
一段时间后，我意识到一些犯罪软件团体以一些非常糟糕的方式利用该技术（https://www.proofpoint.com/us/threat-insight/post/ta505-abusing-settingcontent-ms-within-pdf-files-distribute-flawedammyy-rat）。在看到它在野外被使用后，我让MSRC知道：
MSRC很快让我知道他们将尽快发布修复……这与原始报告评估完全相反：
此外，还提到了“另一个MSRC案例线程上的另一封电子邮件”。这 definitely 激起了我的兴趣。几天后，我收到一封奇怪的电子邮件，其案例编号与最初分配的不同：
在这一点上，我惊呆了。在向一个关闭的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月的补丁星期二到来，我收到了这封电子邮件：
耶！！！所以微软根据我提供的、在该技术公开后的新信息，重新评估了一个“不予修复”的漏洞。又过了几天，并与微软进行了一些物流电子邮件交流后，我收到了这个：
我必须称赞微软让事情变得正确。这个漏洞报告从“不予修复”变成了CVE、公开确认和15,000美元的赏金，速度相当快。
作为一个喜欢自我批评的人，我不禁承认原始报告主要关注Office 2016 OLE和Windows Defender ASR，这两者都不是可服务的漏洞（尽管提到了RCE）。我本可以做得更好，我学到了什么？
如果你有一个漏洞，展示它能造成的最大的损害。不过，我不能把所有的过错都归咎于自己。虽然我可能错误地传达了漏洞的背景，但MSRC的分类和产品团队应该抓住原始报告中的影响，特别是既然我提到了“允许从互联网执行代码，且对用户没有安全警告”。
这引出了我的下一个观点。我们都是人类。我犯了一个错误，没有清楚地传达我的漏洞的影响/背景。MSRC在漏洞评估中犯了一个错误。这会发生。
在这个过程中我学到的一些关键点：
- 厂商是人。尽量对他们做正确的事，希望他们也尽量对你做正确的事。MSRC给了我一个CVE、一个确认和15,000美元的赏金，因为一个在修复前被积极利用的漏洞。
- 厂商：请与你们的研究人员沟通。这是我在漏洞披露中最大的问题。这不仅适用于微软，也适用于每个厂商。如果你让研究人员蒙在鼓里，没有任何主动回应（或实际回应），你的漏洞最终会出现在你最不希望的地方。
- 如果你认为你的漏洞被误诊，通过跟进并陈述你的案例来坚持到底。能否提供任何可能有用的额外信息？如果你得到一个被发出“不予修复”的漏洞，然后你看到它被左右利用，让厂商知道。这些信息可能改变游戏规则，对你和他们的客户都是如此。
漏洞披露是，并将继续是一个难题。为什么？因为有些厂商不会对他们的研究人员做正确的事。由于与“VendorX”（明确说，不是微软）的敌对关系，我手上还有一些产品的0day。我也将我认为可能 remotely 像漏洞的任何东西发送给其他厂商，因为他们对我做正确的事。
归根结底，以你希望被对待的方式对待他人。这适用于厂商和研究人员。我们都是为了让事情变得更好。停止增加障碍。
时间线：
- 2018年2月16日下午2:37 EDT：报告提交至secure@microsoft.com
- 2018年2月16日下午4:34 EDT：MSRC确认报告并开案
- 2018年3月2日下午12:27 EDT：MSRC回应说明他们可以复现问题
- 2018年4月24日下午4:06 EDT：要求案例更新
- 2018年4月25日下午12:42 EDT：案例被重新分配给另一个案例处理人员。
- 2018年6月1日下午1:29 EDT：向新案例处理人员要求案例更新
- 2018年6月4日上午10:29 EDT：被告知问题低于服务门槛；案例关闭。
- 2018年7月11日：通过博客文章公开披露问题
- 2018年6月14日上午9:44 EDT：在听说2个浏览器漏洞使用该漏洞后向MSRC发送跟进
- 2018年6月14日上午11:05 EDT：案例用新信息更新
- 2018年6月26日下午12:17 EDT：通知MSRC关于mozilla CVE（CVE-2018-12368）
- 2018年6月26日下午1:15 EDT：MSRC将mozilla CVE传递给产品团队
- 2018年7月3日晚上9:52 EDT：案例被重新分配给另一个案例处理人员
- 2018年7月23日下午4:49 EDT：让MSRC知道.settingcontent-ms在野外被滥用。
- 2018年7月27日晚上7:47 EDT：MSRC通知我他们将尽快发布修复
- 2018年7月27日晚上7:55 EDT：MSRC通知我赏金资格
- 2018年8月6日下午3:39 EDT：询问MSRC CVE-2018-8414是否与案例相关
- 2018年8月6日下午4:23 EDT：MSRC确认CVE-2018-8414被分配给案例
- 2018年8月14日：补丁推送给公众
- 2018年9月28日下午4:36 EDT：15,000美元赏金 awarded
在发布这篇博客文章之前，我请MSRC审查并提供任何他们可能有的评论。他们要求我包括他们的官方回应声明，你可以在下面找到：
干杯， Matt N.