2019年5月，Project Zero发布了在野使用0 day的跟踪表，我们开始更加专注于分析和学习这些漏洞。这是Project Zero试图使0 day 利用变得艰难的另一种方法。这篇文章综合了我们的许多努力以及去年的分析。我们对从2019年在在野使用的0 day漏洞利用中可以学到的内容进行了回顾。结合此文章，我们今天还发布了另一篇文章，介绍了我们的根本原因分析工作，这些工作为得出的结论提供了信息。我们还将发布8个漏洞的根本原因分析，这些漏洞已从2019年开始进行了0 day在野利用。

https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=0
https://googleprojectzero.blogspot.com/2020/07/root-cause-analyses-for-0-day-in-wild.html
https://googleprojectzero.blogspot.com/p/rca.html

当我想到要写这篇“年度回顾”文章时，我立即开始集思广益，以不同的方式对数据进行切片以及得出的不同结论。我认为也许会有一些有趣的结论，说明为什么“UAF”是利用最多的bug类之一，或者在0 day的Y％的时间内如何使用给定的利用方法。在我探索的各个领域中，数据和分析得出了一个结论：我们严重缺乏检测在野使用0 day的能力，以至于我们无法得出一些结论。

文章的其余部分将详细介绍我在2019年对利用0 day进行的分析，该分析为得出这一结论提供了依据。作为一个团队，Project Zero将继续研究0 day的新检测方法。我们希望这篇文章能说服你与我们一起努力。

0x01 基础信息

在2019年，检测到20个0 day，并在在野发现了对其中0 day的利用。这个数字，以及我们的追踪范围，是“零计划”积极研究的目标和领域。你可以在此处阅读有关我们范围的更多信息。

https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=0

这似乎是2014-2017年的平均水平，在2018年检测到的0 day异常少。请注意，Project Zero仅在2014年7月团队成立时才开始跟踪数据，因此2014年的数字已接近翻倍。

检测到的0 day的数量大致稳定，这可能表明防御者检测技术的发展与攻击者技术的发展速度相同，这可能是真的，也有可能不是。电子表格中的数据仅是检测到的0 day漏洞，而不是使用的0 day漏洞。只要我们仍然不知道所有0 day漏洞利用的真实检测率，就很难就在野利用的0 day漏洞利用的数量是增加还是减少做出任何结论。例如，如果所有防御者都停止了检测工作，那么可能会发现没有0 day被利用，但我们显然知道这是漏洞的。

Project Zero跟踪表详细介绍了2019年检测到的所有0 day漏洞利用。

https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=8521108

厂商 0 day 数量

分析漏洞和安全性问题的常用方法之一是查看谁受到了影响。以下是厂商在2019年的0 day数据的细分。虽然数据显示几乎所有大型平台厂商的产品至少被检测到0 day，但仍然存在很大差异。根据数据，Microsoft产品的目标是Apple和Google产品的约5倍。然而，苹果和谷歌以及其iOS和Android产品构成了世界上绝大多数的设备。

尽管Microsoft Windows一直是使用0 day的的主要目标，但我认为由于检测偏差，我们更有可能看到更多的Microsoft 0 day。由于Microsoft在其他平台尚未发明之前就已经成为攻击目标，因此针对Microsoft产品的0 day检测解决方案已经进行了许多年的开发。Microsoft的生态系统还允许第三方（除了Microsoft自己之外）部署0 day检测解决方案。越来越多的人使用各种检测方法来寻找0 day，这意味着将发现更多0 day。

0x02 对微软 0 day 的深入分析

对于2019年，Microsoft产品中有11种通行检测为0 day的漏洞，占检测到的0 day总数的50％以上。因此，我认为有必要深入研究Microsoft的漏洞以了解更多的信息，因为它是我们拥有足够样本量的唯一平台。

在Microsoft的11个0 day中，只有4个被发现利用了Windows的最新软件版本。其他所有对象都针对Windows的早期版本，例如最初于2009年发布的Windows7。在利用Windows最新版本的4个0 day中，有3个针对Internet Explorer，而Internet Explorer不是Windows 10的默认浏览器。，仍包含在操作系统中以实现向后兼容。这意味着10/11的Microsoft漏洞针对的是旧版软件。

在Microsoft的11个0 day中，有6个针对Windows操作系统的Win32k组件。Win32k是负责Windows子系统的内核组件，从历史上看，它一直是利用的主要目标。但是，在Windows 10中，Microsoft专用资源来锁定win32k的攻击面。根据检测到的0 day数据，检测到的6个win32k漏洞均未检测到正在利用最新的Windows 10软件版本。0 day中的2个（CVE-2019-0676和CVE-2019-1132）仅影响Windows 7。

即使在Microsoft的0 day之内，也可能存在检测偏差。旧版软件的确是Microsoft Windows中0 day的主要目标，还是因为该软件和这些漏洞利用技术的使用时间最长，所以我们才能够更好地检测到它们？

Internet Explorer JScript 0 day 分析

尽管此文章的目标不是详细说明2019年使用的每个0 day，但必须要讨论一下Internet Explorer JScript的 0 day。CVE-2019-1367和CVE-2019-1429（以及2018年12月的CVE-2018-8653和2020年2月的CVE-2020-0674）都是彼此的变体，同一攻击者在野利用的全部4种变体。

https://www.blog.google/threat-analysis-group/identifying-vulnerabilities-and-protecting-you-phishing/
https://googleprojectzero.blogspot.com/p/rca-cve-2019-1367.html

我们的根本原因分析提供了有关这些漏洞的更多详细信息，但我们将在此处总结要点。bug原因是垃圾收集器无法跟踪的JScript变量。Project Zero的Ivan Fratric在2018年1月发现了此漏洞类的多个实例。在2018年12月，Google的TAG发现了该漏洞类在在野使用（CVE-2018-8653）。然后在2019年9月，发现了另一个使用此bug类的漏洞。该漏洞已分配“ CVE-2019-1367”做了修复，但事实证明该补丁实际上并未解决问题，攻击者能够继续利用原始漏洞。同时，Ivan Fratric（P0 1947）也发现了原始bug的变体。变体和原始漏洞均已修复为CVE-2019-1429。然后在2020年1月，TAG又发现了一个利用，因为微软的补丁依然不完整，此问题被修补为CVE-2020-0674。

即将进行有关变体分析和完整补丁的更彻底的讨论，但是此时，我们只需要注意：使用0 day漏洞的攻击者有4个单独的机会可以在漏洞修补之后继续攻击用户，然后知道特定的漏洞。如果我们想要努力检测出0 day，我们就不能给攻击者四个机会来利用同一漏洞。

0x03 内存破坏漏洞

2019年被利用的0 day漏洞中有63％属于内存破坏漏洞，其中一半的内存破坏漏洞bug是UAF漏洞。内存破坏漏洞和UAF成为普遍目标并不是什么新鲜事。

http://phrack.org/issues/49/14.html

这是描述基于堆栈的内存破坏利用的开创性工作，早在1996年就已发布。但有趣的是，当对安全性研究进行了许多有趣的研究时，几乎三分之二的检测到的0 day仍在利用内存破坏漏洞。漏洞类别，例如逻辑漏洞和编译器漏洞。同样，检测到的0 day中有三分之二是内存破坏漏洞漏洞。尽管我不确定该比例是否成立，但没有更好的检测方法，因为与其他类型的漏洞相比，检测内存破坏漏洞更容易。由于普遍存在内存破坏漏洞漏洞，并且它们往往不如逻辑漏洞可靠，这可能是另一个检测偏差。内存破坏漏洞漏洞的类型在平台内往往非常相似，并且不会随着时间的推移而真正改变：十年前的“use-after-free”今天看起来像是“use-after-free”漏洞，因此我认为我们可能会更好地检测这些漏洞。另一方面，逻辑和设计漏洞看起来相似性很少，因为从本质上讲，它们利用了特定组件设计中的特定缺陷，因此比标准内存破坏漏洞更难以检测。

即使我们的数据偏向于过度代表内存破坏漏洞，内存破坏漏漏洞仍在定期针对用户进行利用，因此我们需要继续关注系统和结构性修复，例如内存标记和内存安全语言。

0x04 关于 0 day 检测的思考

到目前为止，我们的问题仍然成立：“ 0 day漏洞的检测率是多少？” 和“未检测到使用了0 day攻击次数？”。

我们只能查看和分析检测到的0 day，而不是所有使用的0 day。尽管有些人可能会看到这些数据并说Microsoft Windows的0 day攻击次数是Android的11倍，但这些声明不能真诚地提出。相反，我认为安全社区仅以比其他平台更高的速度在Microsoft Windows中检测到0 day。如果我们回顾过去，最初的反病毒和检测程序是针对Microsoft Windows而非任何其他平台构建的。随着时间的推移，Windows的检测方法也在不断发展。Microsoft构建了用于检测0 day以及第三方安全公司的工具和技术。我们在其他平台（尤其是移动平台）上看不到过多的检测工具，这意味着在这些平台上检测0 day的可能性也较小。增长最快的领域是在Microsoft Windows以外的平台上检测0 day，以及厂商提供检测的访问级别。

谁在做检测？

检测的另一个有趣方面是，安全研究员ClémentLecigne的Google TAG在2019年在以下四个平台上检测到的21个0 day中有7个被认为是可靠的：Apple iOS（CVE-2019-7286，CVE-2019-7287） ，Google Chrome（CVE-2019-5786），Microsoft Internet Explorer（CVE-2019-0676，CVE-2019-1367，CVE-2019-1429）和Microsoft Windows（CVE-2019-0808）。换句话说，如果不是Clément和团队使用的话，我们可以检测到在野实际使用的0 day少三分之一。当我们把卡巴斯基实验室的0 day（CVE-2019-0808，CVE-2019-3568，CVE-2019-13720，CVE-2019-1429）中的4个0 day加入时，在2019年检测到的0 day中，有两个实体占了50％以上。如果整个全球安全社区中有两个实体负责检测一年中超过0 day的一半，这对于我们如何使用我们的资源来说是一个令人担忧的信号。安全社区在这方面可以做很多工作，以使我们有信心在检测在野使用的大多数0 day漏洞。

在20个0 day中，只有一个（CVE-2019-0703）是厂商发现的，甚至那个也是外部研究人员发现的。对我来说，这是令人惊讶的，因为我希望平台的厂商能够通过访问最多的数据，日志，在平台中进行检测的功能，有关漏洞利用的“提示”，来最好地检测0 day。这引出了一个问题：具有最大访问权限的厂商安全团队是否没有将资源用于检测0 day，还是在内部发现它们时才发现它们而只是不公开它们？无论哪种方式，这都不理想。当你考虑锁定的移动平台时，这尤其令人担忧，因为外部研究人员很难进入这些平台并检测出利用情况。

秘密 0 day报告

有趣的是，我们知道有时会秘密地报告漏洞，这意味着它们仅是另一个漏洞，而不是被积极利用的漏洞。这会损害安全性，因为如果用户及其企业知道自己的漏洞已被积极利用，他们可能会根据自己独特的威胁模型采取不同的措施。厂商和第三方安全专业人员还可以创建更好的检测结果，投资于相关研究，确定分析的优先级或采取其他措施，如果他们知道攻击者已经利用了安全漏洞，则利用这些漏洞和用户将直接增加攻击者的成本。如果所有人都可以透明地披露利用漏洞的时间，那么我们的检测数字也可能会上升。

0x05 在移动平台上进行0 day检测

如上所述，一个特别有趣且需要开发的领域是移动平台，iOS和Android。在2019年，只有3个移动设备的0 day被检测到：2个iOS设备（CVE-2019-7286和CVE-2019-7286）和1个Android设备（CVE-2019-2215）。但是，据Zerodium称，有数十亿手机用户，Android和iOS漏洞的售价是PC漏洞的两倍或更多。我们知道这些漏洞正在被利用中，只是无法检测它们。由于iOS的“walled garden”和两个平台的沙箱，iOS和Android移动平台可能是部署第三方安全解决方案最困难的两个平台。对于用户安全至关重要的相同功能也使第三方难以部署设备上的检测解决方案。由于非厂商很难部署解决方案，因此我们作为用户和安全社区，依靠厂商在寻找针对这些平台的0 day活动中保持主动和透明。因此，一个关键问题就变成了，作为安全专家，我们如何激励厂商做这样的考虑呢？

分析时出现的另一件有趣的事情是CVE-2019-2215是自从我们开始跟踪针对Android的0 day以来首次检测到0 day。直到那时，最接近的是针对Linux的CVE-2016-5195。但是，在2019年（自2014年以来）以来发现的唯一Android 0 day是CVE-2019-2215，它是通过文档而不是通过找到0 day漏洞利用示例来检测到的。因此，在2019年，2018年，2017年，2016年，2015年和2014年上半年均未检测到（或至少公开披露）0 day漏洞利用样本。基于对攻击性安全行业的了解，我们知道并不意味着没有人使用过。相反，这意味着我们检测得还不够好，并且在没有公开信息的情况下利用了0 day的时间。因此，那些0 day未进行修补，用户和安全社区将无法采取其他防御措施。研究新方法以检测针对移动平台（iOS和Android）的0 day是2020年“project zero”的重点。

0x06 在其他平台上检测

有趣的是，其他流行的平台在同一时期内未检测到0 day：例如Linux，Safari或macOS。尽管在这些操作系统中未公开检测到0 day，但我们可以确信，它们仍然是感兴趣的目标，具体取决于他们拥有的用户数量。如果确实是这样，那么它又使我们回到了检测思路上。我们还应记住，尽管某些平台可能不需要0 day就可以成功利用。例如，此文章详细介绍了iOS漏洞利用链是如何使用公开已知的n day来利用WebKit的。但是如果没有更完整的数据，我们将无法确定每个平台发生了0 day利用的情况。

https://googleprojectzero.blogspot.com/2019/08/jsc-exploits.html

0x07 0 day 在野利用的根本原因分析

当0 day在野外被利用和被检测到，我们需要知道尽可能多的有关漏洞的信息，这样做的主要方法之一是对0 day进行根本原因分析（RCA）。

我们为此做出了认真的努力，于2019年最后一个季度开始。今天，我们开始发布已完成的0 day在野利用的根本原因分析。虽然我们现在正在批量发布一些内容以进行“追赶”，但将来，我们计划在发现并披露每个消息后及时发布它们。我们认为及时发布技术细节对于提高透明度很重要，因此整个安全界可以做出明智的决定和采取行动。

0 day利用漏洞根本原因分析：

https://googleprojectzero.blogspot.com/p/rca.html

对于每一个根本原因分析，我们都使用一个模板。我们根据Project Zero发现的关于在野 0 day利用的重要且可行的内容开发了此模板。

在完成根本原因分析时，我们重点关注以下领域。

· bug种类

· 漏洞的详细信息，例如如何触发，实现效果。

· 利用方法及其是否为已知方法

· 关于漏洞发现方式的假设（代码审计，模糊测试，补丁分析等）

· 补丁分析和发现的补丁区域

· 相似0 day的潜在检测方法

我们选择这些区域是因为漏洞详细信息和漏洞利用方法提供了漏洞利用事实的深入解释：漏洞是什么，漏洞如何发挥作用以及如何被利用。一旦我们记录了事实，我们就可以使用这些事实来告知我们的假设并集思广益，我们如何才能防止攻击者再次这样做。尽管其中一些想法可能被厂商认为不可行，或者在实践中效果不佳，但其中一些想法是（并且已经是合理的）并且能够被提出。总体目标是强制进行头脑风暴，以期采取在检测到的0 day的时候采取措施：更好地检测的措施，更好地缓解的措施，防止引入新漏洞的措施，使0 day困难的措施。

在2019年的20个0 day中，我们完成了8个漏洞的根本原因分析，今天我们将其发布在此处。在2019年8月或之后的0 day中，有6个0 day。此外，我们还将发布2019年2月以来的两个iOS 0 day，Project Zero与Google的Threat Analysis Group合作向苹果报告了该报告;以及iOS 0 Project向Firefox报告的一个Firefox 0day。

· CVE-2019-7286: iOS use-after-free in CFPrefsDaemon

· CVE-2019-7287: iOS buffer overflow in ProvInfoIOKitUserClient

· CVE-2019-1107: Firefox type confusion in Array.pop 

· CVE-2019-1367: JScript use-after-free in Internet Explorer

· CVE-2019-2215: Android use-after-free in Binder

· CVE-2019-13720: Chrome use-after-free in webaudio

· CVE-2019-1429: JScript use-after-free in Internet Explorer (See CVE-2019-1367)

· CVE-2019-1458: Windows win32k uninitialized variable in task switching

我们希望这些分析对安全和技术社区中的其他人有帮助，使其对从检测到的0 day漏洞中收集的数据采取行动，并帮助确定使攻击者更昂贵，更耗时且更难于使用0 day攻击的方法。

0x08 分析总结

这是我们在在野利用0 day的第一年回顾。随着该计划的发展，基于你的反馈以及我们自己的知识和经验的不断增长，我们将发布的内容也将不断增长。我们以发现大量不同结论（主要是“技术性”）为前提开始了这项工作，但是一旦开始分析，就很清楚一切都归结为一个结论：我们在检测0 day漏洞利用方面存在很大差距。

本文翻译自：https://googleprojectzero.blogspot.com/2020/07/detection-deficit-year-in-review-of-0.html如若转载，请注明原文地址：