CVE-2018–8414: 负责任披露的案例研究
漏洞披露过程可能充满挫折、伦理担忧和沟通失败。我有许多漏洞报告进展顺利，也有许多进展不佳。
我通过赏金计划（Bugcrowd/HackerOne）和直接报告渠道（Microsoft）提交了大量漏洞。我在这里不是为了讨论伦理，也不是为了解决“漏洞披露”这一大辩论。我只是想分享一次让我印象深刻的经历，并希望它能引起所有供应商对报告流程的反思。
首先，我想简单介绍一下我自己以及我与漏洞研究的关系。
我不是经验丰富的逆向工程师，也不是全职开发者。我精通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压缩包包含武器化的.settingcontent-ms文件（允许从互联网执行代码，且用户无安全警告）”。这是非常重要的一行，但它被电子邮件的其余部分掩盖了。
2018年2月16日下午4:34，我收到了Microsoft的模板回复，称已分配案例编号。我的理解是，当案例处理人员接手（或被分配）你的案例时，这封电子邮件是相当自动化的：
很好。此时，这只是一场等待游戏，等待他们对报告进行分类。等待一段时间后，我在2018年3月2日中午12:27收到一封电子邮件，称他们成功复现了问题：
太棒了！这意味着他们能够根据我的详细说明和PoC确认其有效性。在这一点上，许多研究人员会感到沮丧。你花时间发现漏洞，花时间报告它，几乎立即得到供应商的回应，一旦他们复现了，事情就变得安静了。这是可以理解的，因为他们可能正在对问题进行根本原因分析。这是决定漏洞是否值得修复的关键点。
我承认，我通常遵循Google Project Zero使用的90天政策。我不为GPZ工作，我找漏洞（或管理多个报告）也没有报酬。如果沟通存在，我往往会宽容一些。如果供应商不与我沟通，我会在90天窗口关闭后的第二天发布博客文章。
供应商们，请与你们的研究人员沟通！
在这种情况下，我像许多研究人员一样，在一个多月没有任何消息后……我请求更新：
此时，距离我上次听到任何消息已经快一个半月了。在请求更新后，这封电子邮件来了：
有趣……我突然有了另一个人处理我的案例？我可以理解这一点，因为Microsoft是一个庞大的组织，有各种各样的人处理他们每天收到的大量报告。也许我的案例处理人员忙不过来了？
让我们暂停一下，评估到目前为止的情况：我报告了一个漏洞。这个漏洞被分配了一个案例编号。我被告知他们复现了问题，然后一个半月没有消息。在联系之后，我发现案例被重新分配了。为什么？
供应商们，这就是引起挫折的原因。研究人员觉得他们被拖着走，被蒙在鼓里。如果你不希望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案例发送一些额外信息后，漏洞从“不予修复”变成了“我们将尽快发布修复，并奖励你赏金”。在与Microsoft赏金团队进行一些小的物流交流后，我看到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月的补丁星期二到来，我收到了这封电子邮件：
耶！！！所以Microsoft根据我提供的、技术公开后的新信息，重新评估了一个“不予修复”的漏洞。又过了几天，与Microsoft进行了一些物流电子邮件交流后，我收到了这个：
我必须称赞Microsoft让事情变得正确。这个漏洞报告从“不予修复”变成了CVE、公开致谢和15000美元赏金，速度相当快。
作为一个喜欢自我批评的人，我不禁承认原始报告主要关注Office 2016 OLE和Windows Defender ASR，这两者都不是可服务的漏洞（尽管提到了RCE）。我本可以做得更好，我学到了什么？
如果你有一个漏洞，展示它能造成的最大的损害。不过，我不能把所有过错都归咎于自己。虽然我可能错误地传达了漏洞的背景，但MSRC的分类和产品团队应该抓住原始报告中的影响，特别是既然我提到了“允许从互联网执行代码，且用户无安全警告”。
这引出了我的下一个观点。我们都是人。我犯了一个错误，没有清楚地传达我的漏洞的影响/背景。MSRC在漏洞评估中犯了一个错误。这会发生。
以下是我在这个过程中学到的一些关键点：
- 供应商是人。尽量对他们做正确的事，希望他们也尽量对你做正确的事。MSRC给了我一个CVE、致谢和15000美元赏金，因为一个漏洞在修复前被积极利用。
- 供应商：请与你们的研究人员沟通。这是我在漏洞披露中最大的问题。这不仅适用于Microsoft，也适用于每个供应商。如果你让研究人员蒙在鼓里，没有任何主动回应（或实际回应），你的漏洞最终会出现在你最不希望它们出现的地方。
- 如果你认为你的漏洞被误诊，通过跟进并陈述你的情况来坚持到底。是否可以提供任何可能有用的额外信息？如果你得到一个被标记为“不予修复”的漏洞，然后看到它被左右利用，让供应商知道。这些信息可能会改变你和他们客户的游戏规则。
漏洞披露是，并将继续是一个难题。为什么？因为有些供应商不会对他们的研究人员做正确的事。由于与“VendorX”（澄清一下，不是Microsoft）的敌对关系，我手上还有一些产品的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：奖励15000美元赏金
在发布这篇博客文章之前，我请MSRC审阅并提供任何评论。他们要求我包含他们的官方回应声明，你可以在下面找到：
干杯， Matt N.