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案件线程的另一封电子邮件"。这绝对引起了我的兴趣。几天后，我收到一封奇怪的电子邮件，案件编号与最初分配的不同：

在这一点上，我震惊不已。在向一个已关闭的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、公开致谢和15000美元赏金，进展相当快。

作为一个喜欢自我批评的人，我不禁承认原始报告主要关注Office 2016 OLE和Windows Defender ASR，这两者都不是可修复的漏洞（尽管提到了RCE）。我本可以如何做得更好，我学到了什么？

如果你有一个漏洞，展示它能造成的最严重损害。不过，我不能把所有的过错都归咎于自己。虽然我可能错误地传达了漏洞的背景，但MSRC的分类和产品团队应该注意到原始报告中的影响，特别是既然我提到了"允许从互联网执行代码，且对用户无安全警告"。

这引出了我的下一个观点。我们都是人。我犯了一个错误，没有清楚地传达我的漏洞的影响/背景。MSRC在漏洞评估中犯了错误。这种情况会发生。

在这个过程中我学到的一些关键点：

• 供应商也是人。尽量对他们做正确的事，希望他们也尽量对你做正确的事。MSRC给了我一个CVE、一个致谢和一个15000美元的赏金，因为一个在修复前被积极利用的漏洞。
• 供应商：请与你们的研究人员沟通。这是我在漏洞披露中最大的问题。这不仅适用于微软，也适用于每个供应商。如果你让研究人员蒙在鼓里，没有任何主动回应（或实际回应），你的漏洞最终会出现在你最不希望它们出现的地方。
• 如果你认为你的漏洞被误诊了，请通过跟进并陈述你的情况来坚持到底。是否可以提供任何可能有用的额外信息？如果你得到一个被标记为"不予修复"的漏洞，然后你看到它被到处利用，请让供应商知道。这些信息可能会改变你和他们客户的游戏规则。

漏洞披露是，并将继续是一个难题。为什么？因为有些供应商不会善待他们的研究人员。由于与"VendorX"（澄清一下，不是微软）的敌对关系，我手头有一些产品的0day。我也把我认为可能稍微像漏洞的任何东西发送给其他供应商，因为他们对我很好。

归根结底，以你希望被对待的方式对待他人。这既适用于供应商，也适用于研究人员。我们都是为了让事情变得更好。停止设置障碍。

时间线：

• 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.