这是我们第三次对在野利用的0-day漏洞进行年度回顾[2020年，2019年]。每年，我们都对所有已检测到并公之于众的在野0-day漏洞进行回顾，并总结我们认为的趋势和收获。这份报告的宗旨，并非详细说明各个漏洞，而是把当年的漏洞作为整体进行分析，寻找趋势、差距、经验教训、成功案例等。如果您对单个漏洞的分析感兴趣的话，可以访问我们的根本原因分析库。

我们之所以进行这项工作并公之于众，旨在为“天下无0-day”出一份力：增加攻击者使用0-day漏洞的成本，使其需要耗费更多的资源，从而总体上提高攻击者利用这些漏洞的难度。2021年，我们强调了坚持不懈地增加攻击者利用0-day漏洞的难度对用户是多么重要。我们一次一次又一次地听到攻击者是如何针对记者、少数族裔人口、政治家、人权维护者，甚至是世界各地的安全研究人员发起有针对性的攻击的。我们在安全和科技界做出的决定会对社会和我们人类同胞的生活产生真正的影响。

对于上述观点，我们将在这篇文章中提供相应的证据以及论证的过程，并在结论中总结我们对下一步的想法，以及对2022年的期望。如果您不喜欢深入研究这些细节，那么可以直接阅读概述和结论部分。

概述

2021年，我们总共检测和披露了58个0-day漏洞，这是自2014年年中启动Project Zero项目以来的最高记录。这比之前在2015年检测到的28个最高纪录高出一倍多；如果考虑到2020年只检测到25个0-day漏洞，那么这个记录就更令人瞠目结舌了。自2014年年中以来，我们每年披露的0-day漏洞数量，可参考链接https://docs.google.com/spreadsheets/d/1lkNJ0uQwbeC1ZTRrxdtuPLCIl7mlUreoKfSIgajnSyY/edit#gid=0。

虽然我们经常谈论野外使用的0-day漏洞exploit数量，但我们实际上讨论的是被检测到并被披露为在野0-day漏洞的数量。这就引出了我们的第一个结论：我们相信，2021年在野0-day漏洞数量的大幅上升，只是因为检测并披露的在野0-day漏洞数量大幅增加了，而不是在野0-day漏洞自身的数量大幅增加了。

在分析这58个0-day漏洞的过程中，我们发现：攻击者所使用的方法与前几年相比并没有发生什么变化。攻击者使用相同的漏洞模式和利用技术，在相同的攻击面上取得了成功。Project Zero的任务是“提高0-day漏洞的利用难度”——总的来说，当攻击者无法使用公开的方法和技术来利用0-day漏洞时，我们的目的就达到了。当我们考察2021年发现的这58个0-day漏洞时，发现它们与以前公开的0-day漏洞非常相似。实际上，只有两个0-day漏洞被认为是新颖的：一个是其利用的技术复杂性，另一个是利用逻辑漏洞来实现沙箱逃逸。

因此，虽然我们承认业界在检测和披露在野0-day漏洞方面取得了长足进步，但我们也不能否认，还有很多事情需要有待改进。随着对攻击者如何实际利用0-day漏洞的“基本事实”的广泛了解，我们发现：攻击者采用以前已知的技术和方法就能取得成功，而不必投资开发新的技术。这对科技行业来说是一个明显的机会领域。

与过去相比，我们在2021年获得了更多的数据，这可以帮助我们更加深入地了解攻击者的行为。不过，数据越多，给我们带来的问题也随之增加。不幸的是，积极利用0-day漏洞的攻击者既不会主动分享自己正在使用的漏洞，也不会告诉我们这部分漏洞所占的比例，所以，我们永远也无从知晓目前被发现和公开披露的0-day漏洞的确切比例。

根据我们对2021年0-day漏洞的分析，我们希望在2022年能够取得以下进展，以便继续提高利用0-day漏洞的难度：

• 所有供应商都同意在其安全公告中披露漏洞的在野利用状态。
• 更广泛地分享漏洞利用的样本或详细的技术描述。
• 继续协同努力，减少内存损坏型漏洞或使其无法利用。启动缓解措施，将大大降低内存损坏型漏洞的可利用性。

2021年发现的在野0-day漏洞数量创新高

2021年发现的在野0-day漏洞数量创了历史新高，下面，让我们看看到底发生了什么？

那么，读者可能会问：是软件的安全性越来越差了么？还是攻击者利用了更多的0-day漏洞？还是我们检测和披露0-day漏洞的能力提高了？从2020年到2021年的显著增长来看，我们认为这主要是由后者造成的。虽然我们认为在过去几年中，攻击者对0-day漏洞的兴趣和投资一直在稳步增长，并且安全性仍然迫切需要改进，但安全行业检测和披露在野0-day漏洞的能力似乎是2021年观察到的0-day漏洞数量陡增的主要原因。

虽然我们经常谈论“在野使用的0-day漏洞exploit”，但我们实际跟踪的却是“检测到并披露为在野使用的0-day漏洞exploit”。除了使用的0-day漏洞数量之外，还有更多的因素促成了这一数字的增加，最明显的是：检测和披露0-day漏洞的能力的提高。更好的0-day exploit检测能力和更透明地披露被利用的0-day漏洞，这本身就是安全行业进步的一个积极指标。

总的来说，我们可以将在野0-day漏洞数量的上升分解为：

• 更多的在野0-day漏洞利用代码被发现
• 更多的在野0-day漏洞利用技术被披露

更多的在野0-day漏洞利用代码被发现

在2019年的年度回顾中，我们谈到了“检测赤字”。我们在报告中写到：“作为一个社区，我们检测在野外被利用的0-day漏洞的能力严重不足，致使所收集的数据严重不足（并存在偏差），所以无法得出重大结论。” 在过去的两年里，我们相信自己在这方面已经取得了长足的进步。

这么说吧，我们从更多的人那里听说他们已经开始更多地致力于检测0-day exploit。从数量上看，虽然数量只是一个非常粗略的衡量标准，但我们也看到报告在野0-day漏洞的机构数量与日俱增。按理说，如果致力于寻找0-day exploit的人数越来越多，那么检测到的在野0-day exploit的数量也会有所增加。

我们还看到，在自家的产品中检测在野0-day漏洞的供应商数量也在增加。无论这些供应商之前是否致力于检测这些漏洞，他们似乎在2021年找到了取得更大成功的途径。这些供应商通常对自家产品具有最多的遥测数据，以及更全面的知识和可见性，所以，如果他们投资于针对自家产品的0-day漏洞的检查技术的话，则更有可能获得成功——这一点很重要。如上图所示，各供应商在自家产品中发现的在野0-day漏洞的数量已经明显增加。例如，谷歌在自家的产品中发现了7个在野0-day漏洞，而微软则在自家产品中发现了10个!

更多的在野0-day漏洞利用技术被披露

检测到的在野0-day漏洞的数量增加的第二个原因，是由于被披露的漏洞变多了。苹果和谷歌Android（我们之所以将“谷歌Android”与“谷歌”区分开来，是因为谷歌Chrome浏览器在过去几年中一直在发布自己的安全公告）分别于2020年11月和2021年1月开始起在其安全公告中标注安全漏洞潜在的在野利用信息。当供应商不提供这些信息时，除非发现这些漏洞的利用代码的研究人员站出来，否则我们根本无法知道这些0-day漏洞的在野利用情况。如果苹果和谷歌Android没有发布其安全漏洞的在野利用信息，公众很可能无从得知野外至少已经存在7个针对苹果产品的0-day漏洞，以及5个针对Android系统的0-day漏洞。为什么呢？因为这些漏洞是由 “匿名”研究人员报告的，如果他们不想为此邀功，就不会公开说这些漏洞已经发现被利用的迹象。如果苹果和谷歌Android系统没有透明地公布其安全公告，这12个0-day漏洞就不会被列入今年的名单。

在此我们要向微软、谷歌Chrome和Adobe致敬，感谢他们多年来一直在为其安全公告添加注释以提高透明度！同时，我们也要感谢Apache，他们在过去的一年里也为CVE-2021-41773漏洞的安全公告提供了相应的注释。

在Android系统的安全公告中，高通和ARM产品的“在野0-day漏洞”被标注为“in-the-wild”，但在供应商自己的安全公告中则没有给出相应的标注。

极有可能的情况是：在2021年，还有其他0-day漏洞已经在野外被利用并被检测到，但供应商并没有在其安全公告中并没有提及这一点。在2022年，我们希望更多的供应商在修复已经在野利用的漏洞时，一定要指出这一点。在我们确信所有供应商都透明地披露在野利用状态之前，还存在一个大问题，即有多少在野0-day漏洞早已被发现，但供应商却没有披露出来。

新瓶装老酒

在2021年，我们有创纪录数量的“数据点”，用于了解攻击者如何实际使用0-day exploit的。但让我们有点惊讶的是，在所有这些数据点中，没有任何新的数据。0-day exploit被认为是入侵者可以使用的最先进的攻击方法之一，因此，我们很容易得出这样的结论：攻击者一定在使用特殊的技巧和攻击面。但相反，我们在2021年看到的0-day漏洞通常都具有相同的漏洞模式、攻击面和之前在公开资料中见过的exploit“形式”。如果“0-day漏洞是难以利用的”，我们就会想到，要想成功利用它们，攻击者就必须通过新的攻击面使用以前从未见过的漏洞利用方法来挖掘新型的安全漏洞。总的来说，今年的数据并不支持这一假设。在58个漏洞中，除了两个例外（在下面的iOS部分中描述），我们看到的一切都是很“稀松平常”或标准的漏洞。

在今年的58个在野0-day漏洞中，有39个，即67%的漏洞为内存损坏型漏洞。在过去的几十年里，内存损坏型漏洞已经成为攻击软件的标配，而且到目前为止这种方法仍然屡试不爽。在这些漏洞中，大多数都是非常流行和著名的漏洞类型：

• 17个释放后使用漏洞
• 6个越界读写漏洞
• 4个缓冲区溢出漏洞
• 4个整数溢出漏洞

在接下来的章节中，我们将深入探讨今年发现的、针对各个平台的在野0-day漏洞。我们将分享这些趋势，并解释为什么我们看到的是相当不寻常的。

Chromium (Chrome)

在2021年，人们在Chromium中发现并披露了14个0-day漏洞，创下了历史新高。在这14个漏洞中，有10个是渲染器远程代码执行漏洞，2个是沙盒逃逸漏洞，1个是信息泄露漏洞，1个是用于在谷歌Chrome以外的Android应用程序中打开网页的漏洞。

这14个0-day漏洞分别存在于以下组件中：

• 6个针对JavaScript引擎——v8的0-day漏洞 (CVE-2021-21148, CVE-2021-30551, CVE-2021-30563, CVE-2021-30632, CVE-2021-37975, https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html)
• 2个针对DOM引擎——Blink的0-day漏洞(CVE-2021-21193 & CVE-2021-21206)
• 1个针对WebGL的0-day漏洞 (CVE-2021-30554)
• 1个针对IndexedDB的0-day漏洞 (CVE-2021-30633)
• 1个针对webaudio的0-day漏洞 (CVE-2021-21166)
• 1个针对Portals的0-day漏洞 (CVE-2021-37973)
• 1个针对Android Intents的0-day漏洞 (CVE-2021-38000)
• 1个针对内核的0-day漏洞(CVE-2021-37976)

当我们看到这些漏洞所针对的组件时，就会发现它们都是以前在公开的安全研究和以前的exploit中见过的攻击面。与以前相比，现在的DOM漏洞少了一些，而更多的是针对浏览器的其他组件，如IndexedDB和WebGL。在14个Chromium 0-day中，有13个是内存损坏型漏洞。与去年类似，这些内存损坏型漏洞中的大多数都是释放后使用漏洞。

其中，有几个Chromium漏洞甚至与以前的在野0-day漏洞相似。CVE-2021-21166是webaudio组件的ScriptProcessorNode::Process()函数中的一个问题，其中缺乏相应的锁机制，以至于主线程和音频渲染线程都能同时访问缓冲区。CVE-2019-13720是2019年发现的一个在野0-day漏洞。它是webaudio组件的ConvolverHandler::Process()函数的一个漏洞，其中也缺乏相应的锁机制，以至于主线程和音频渲染线程中的缓冲区可以同时访问。

CVE-2021-30632是2021年在Chromium中发现的另一个在野0-day漏洞。它是Chromium浏览器的JavaScript引擎V8中TurboFan JIT的一个类型混淆漏洞，在属性映射被更改后，TurboFan无法对代码进行解优化。CVE-2021-30632则涉及存储全局属性的代码。CVE-2020-16009也是一个在野0-day漏洞，是由于Turbofan在废除映射后未能对代码进行解优化。

WebKit (Safari)

在2021年之前，苹果公司只承认了1个公开的、针对WebKit/Safari的在野0-day漏洞，它是由外部研究人员的分享。在2021年，则披露了7个。这使得我们很难评估趋势或变化，因为我们没有历史样本可以参考。相反，我们将在其他不为人知的Safari漏洞和其他浏览器的在野0-day漏洞的背景下，来看待2021年的WebKit漏洞。

这7个在野0-day漏洞是针对以下组件的：

• 4个针对Javascript引擎——JavaScript核心的0-day漏洞（CVE-2021-1870, CVE-2021-1871, CVE-2021-30663, CVE-2021-30665)
• 1个针对IndexedDB的0-day漏洞 (CVE-2021-30858)
• 1个针对存储组件的0-day漏洞 (CVE-2021-30661)
• 1个针对插件的0-day漏洞(CVE-2021-1879)

有点出乎意料的是，并没有发现或披露针对DOM的安全漏洞。在前几年，DOM引擎中的漏洞通常占在野浏览器0-day漏洞的15-20%，但在2021年，却没有发现或披露针对WebKit的任何漏洞。

如果攻击者开始转向其他模块，如第三方库或像IndexedDB这样的组件，者一点也并不令人惊讶。毕竟对于未来的攻击者来说，这些模块可能更有希望，因为漏洞更有可能存在于多个浏览器或平台上。例如，Chromium中的webaudio漏洞，即CVE-2021-21166，也存在于WebKit中，并被作为CVE-2021-1844进行修复，尽管没有发现WebKit在野外遭受该漏洞攻击的证据。2021年针对Safari的IndexedDB的在野0-day漏洞，即CVE-2021-30858，与2020年1月在Chromium中修复的一个漏洞是非常相似的。

IE

自从我们开始追踪在野0-day漏洞以来，IE浏览器每年的0-day漏洞数量都相当稳定。尽管IE浏览器的市场占有率继续下降，但是在2021年与2016年所曝光的0-day漏洞数量是持平的。

那么，尽管市场份额发生了变化，为什么0-day漏洞数量变化如此之小呢？IE浏览器仍然是一个初步入侵Windows机器的成熟攻击面，即使用户不再使用IE作为其互联网浏览器。虽然0-day漏洞的数量几乎没变，但这些漏洞所针对的组件和exploit的交付方式却发生了较大的变化。2021年出现的4个0-day漏洞中，有3个针对的是MSHTML浏览器引擎，并且不是通过Web进行投递的，相反，它们是通过Office文档或其他文件格式投递给目标的。

这4个0-day漏洞是针对以下组件的：

• MSHTML浏览器引擎（CVE-2021-26411, CVE-2021-33742, CVE-2021-40444)
• Javascript引擎——JScript9 (CVE-2021-34448)

对于CVE-2021-26411漏洞，其攻击目标最初收到的是一个.mht文件，并提示用户使用IE打开。一旦使用IE打开了该文件，就会下载并运行相应的exploit。而CVE-2021-33742和CVE-2021-40444是通过恶意的Office文档传递给攻击目标的。

CVE-2021-26411和CVE-2021-33742是两个常见的内存损坏型漏洞：由于在使用一个对象的两个动作之间有一个用户控制的回调，而用户在该回调期间释放了该对象，因此出现了释放后使用漏洞。

在使用CVE-2021-40444的漏洞链中，存在多个不同的漏洞，但MSHTML中的漏洞的作用是，一旦打开Office文档，payload就会运行：下载CAB文件，解压缩，然后执行该CAB的DLL库中的一个函数。与前两个MSHTML漏洞不同，这是与URL解析相关的逻辑漏洞，而不是内存损坏型漏洞。

Windows

与前几年相比，Windows是我们看到的目标组件变化最大的平台。然而，这种已经延续了多年，随着2020年Windows 7的寿终正寝，这也在预料之中。

在2021年，发现了10个Windows在野0-day漏洞，它们分别针对7个不同组件：

• 2个针对增强型加密提供程序的0-day漏洞（CVE-2021-31199, CVE-2021-31201)
• 2个针对NTOS内核的0-day漏洞(CVE-2021-33771, CVE-2021-31979)
• 2个针对Win32k的0-day漏洞 (CVE-2021-1732, CVE-2021-40449)
• 1个针对Windows update medic服务的0-day漏洞 (CVE-2021-36948)
• 1个针对SuperFetch的0-day漏洞 (CVE-2021-31955)
• 1个针对dwmcore.dll的0-day漏洞 (CVE-2021-28310)
• 1个针对ntfs.sys的0-day漏洞 (CVE-2021-31956)

在过去几年内，漏洞所针对的组件的数量的变化较大。例如，在2019年，75%的Windows 0-day漏洞都是针对Win32k组件的；而在2021年，针对Win32k的漏洞只占Windows 0-day漏洞的20%。之所以说这是意料之中的，是因为2019年针对Win32k的那些0-day漏洞中，有8个并不是针对当时最新发布的Windows 10的，相反，它们针对的是旧版本的系统。随着Windows 10的推出，微软开始投入越来越多的资源来锁定Win32k的攻击面，所以随着那些旧版本生命周期的结束，Win32k作为攻击面的吸引力将越来越小。

与多年来看到的许多Win32k漏洞类似，2021年Win32k的两个在野0-day漏洞也是由于自定义的用户回调函数所致。用户在回调期间调用了改变对象状态的函数，而Win32k并没有正确处理这些变化。CVE-2021-1732是一个类型混淆漏洞，主要是由于xxxClientAllocWindowClassExtraBytes中的用户回调，导致了越界读写问题。如果NtUserConsoleControl在回调过程中被调用，就会在window结构体中设置一个标志，表示某个字段是内核堆的偏移量。2022年检测到并披露的第一个在野0-day漏洞，即CVE-2022-21882，就是由于CVE-2021-1732实际上没有被完全修复所致：攻击者找到了绕过原始补丁的方法，从而触发了该漏洞。CVE-2021-40449是NtGdiResetDC中的释放后使用漏洞，主要是由于对象在用户回调期间被释放导致的。

iOS/macOS

正如上文提到的，苹果公司从2021年开始披露相关漏洞的在野利用情况。这一年，他们发现并披露了5个iOS在野0-day漏洞，其中包括首次公开的macOS在野0-day漏洞（CVE-2021-30869）。在本节中，我们将针对iOS和macOS系统的漏洞放到一起讨论，因为：1）这两个操作系统包括类似的组件，2）macOS的样本量非常小（只有这一个漏洞）。

对于2021年披露的5个iOS和macOS在野0-day漏洞来说，针对的攻击面有3个：

• IOMobileFrameBuffer (CVE-2021-30807, CVE-2021-30883)
• XNU Kernel (CVE-2021-1782 & CVE-2021-30869)
• CoreGraphics (CVE-2021-30860)
• CommCenter (FORCEDENTRY沙箱逃逸漏洞——已经申请CVE编号，但是尚未获批)

这4个攻击面并不新鲜。IOMobileFrameBuffer多年来一直是公共安全研究的重点对象。例如，2016年的盘古越狱就使用了CVE-2016-4654漏洞，即IOMobileFrameBuffer的堆缓冲区溢出漏洞。我们知道，IOMobileFrameBuffer用于管理屏幕的帧缓冲区。对于iPhone 11（A13）及以下版本，IOMobileFrameBuffer是一个内核驱动程序。从A14开始，它运行在一个协处理器上，即DCP。这是一个流行的攻击面，因为从历史上看，它可以通过沙箱化的应用程序中访问。2021年，在IOMobileFrameBuffer中发现了2个在野0-day漏洞。其中，CVE-2021-30807是一个越界读取漏洞，CVE-2021-30883是一个整数溢出漏洞，两者都是常见的内存损坏型漏洞。在2022年，我们已经在IOMobileFrameBuffer中发现了另一个在野0-day漏洞，即CVE-2022-22587。

在这些漏洞中，iOS和macOS系统都有一个0-day漏洞利用了XNU内核的安全漏洞，并且这2个漏洞都位于与XNU的进程间通信（IPC）功能相关的代码中：CVE-2021-1782利用了mach凭证中的一个漏洞，而CVE-2021-30869则利用了mach消息中的一个漏洞。这不是人们第一次在iOS发现针对mach凭证和mach消息的在野0-day漏洞，更不是第一次公开的安全研究。CVE-2019-6625被用作iOS 11.4.1-12.1.2的漏洞链的一部分，也是mach凭证中的一个漏洞。

Mach消息也一直是公共安全研究的热门对象。2020年，mach消息中就曝出过2个在野0-day漏洞：CVE-2020-27932与CVE-2020-27950。而2021年披露的CVE-2021-30869，则是一个与2020年的CVE-2020-27932漏洞相当接近的变种。Tielei Wang和Xinru Chi实际上在2021年4月的zer0con 2021上就发表了关于这个漏洞的演讲。在他们的演讲中，他们解释说，他们是在对CVE-2020-27932做变种分析时发现的。Tielei Wang通过Twitter解释说，他们在2020年12月发现了这个漏洞，并注意到它在iOS 14.4和macOS 11.2的测试版中得到了修复，这就是他们在Zer0Con上展示该漏洞的原因。虽然在野的exploit只针对macOS 10版本，但使用的漏洞利用技术与演讲中展示的完全相同。

实际上，2021年，只有两个FORCEDENTRY漏洞（CVE-2021-30860和沙盒逃逸漏洞）让我们“眼前一亮”。对于CVE-2021-30860，即CoreGraphics中的整数溢出漏洞，它的特别之处在于：

多年来，我们都听说过攻击者是如何利用0-click iMessage漏洞的，现在终于得到了公开的样本，而且
这个exploit是一个令人印象深刻的艺术作品。

沙盒逃逸漏洞（CVE编号已经申请，尚未获批）之所以令人印象深刻，是因为它是我们见过的为数不多的仅使用逻辑漏洞而非标准内存损坏型漏洞的在野沙箱逃逸漏洞。

就CVE-2021-30860而言，该漏洞本身并不特别引人注目：位于CoreGraphics PDF解码器的JBIG2解析器内的典型整数溢出漏洞。但是，这个exploit被Samuel Gro? & Ian Beer赞叹为“他们所见过的技术上最复杂的exploit之一”。他们在自己的文章中分享了所有的细节，但亮点是，该exploit使用JBIG2中的逻辑运算符构建NAND门，进而建立自己的计算机架构。然后，它使用新的自定义架构来编写其余的exploit。他们在自己的文章中称：

他们使用70,000多条段命令来定义逻辑位操作，进而创建了一个小型计算机体系结构，具有寄存器和一个完整的64位加法器和比较器等功能，他们使用这些加法器和比较器搜索内存和执行算术操作。虽然它没有Javascript那么快，但从根本上说，在计算功能上是等价的。

沙箱逃逸漏洞的exploit的引导操作被写成在这个逻辑电路上运行，整个过程都是在这个奇怪的、模拟的环境中运行的，这个环境是通过一个JBIG2流的单一解压过程创建的。这是非常不可思议的，同时也是非常可怕的。

这就是一个让0-day漏洞难以利用的例子：攻击者必须开发一种崭新的方法来利用安全漏洞，并且这种方法需要大量的专业知识和/或时间。这一年的58个0-day漏洞中，只有这2个FORCEDENTRY的漏洞给我们留下了深刻的印象。希望在未来，随着漏洞利用门槛的提高，新型利用方法将成为是任何成功的漏洞利用的必要条件。

Android

这一年共发现并披露了7个针对Android系统的在野0-day漏洞。在2021年之前，只发现过一个此类漏洞，而且是在2019年：即CVE-2019-2215。与WebKit一样，这类数据的匮乏使我们很难评估相应的趋势和变化。相反，我们会将其与公开安全研究进行比较。

对于这7个Android 0-day漏洞，分别针对以下组件：

• Qualcomm Adreno GPU驱动程序（CVE-2020-11261, CVE-2021-1905, CVE-2021-1906)
• ARM Mali GPU驱动程序（CVE-2021-28663, CVE-2021-28664)
• 上游Linux内核（CVE-2021-1048, CVE-2021-0920)

2021年的这7个0-day漏洞中，有5个是针对GPU驱动程序的。当我们考虑到Android生态系统的演变以及最近对Android的公开安全研究时，这实际上没啥令人惊讶的。Android生态系统是相当分散的：具有许多不同的内核版本，不同的制造商定制版本，等等。如果攻击者想获得针对“Android设备”的入侵能力，他们通常需要维护许多不同的exploit，以覆盖Android生态系统中的大部分版本。但是，如果攻击者选择攻击GPU内核驱动程序而不是其他组件，则只需要两个exploit足以，因为大多数Android设备会使用的GPU为：Qualcomm Adreno GPU或ARM Mali GPU。

在过去几年中发布的安全研究也反映了这一点。在开发针对Android设备的完整exploit链（用于防御目的）时，Guang Gong、Man Yue Mo和Ben Hawkes都选择了攻击GPU内核驱动程序以实现本地提权。同时，我们发现的许多在野0-day漏洞也都是针对GPU的，这更像是一种确认，而不是一种启示。在针对GPU驱动程序的5个0day漏洞中，有3个位于Qualcomm Adreno驱动程序中，2个位于ARM Mali驱动程序的。

此外，还有2个非GPU驱动程序的0-day漏洞（CVE-2021-0920和CVE-2021-1048）是针对上游Linux内核的。不幸的是，这2个漏洞与2019年发现的Android在野0-day漏洞有一个共同的特点：所有这3个漏洞在Android中被利用之前都是上游已知的。虽然样本量很小，但已知针对内核的Android 在野0-day漏洞中，100%都是在利用之前就已经知道的漏洞，还是很令人震惊。

现在被称为CVE-2021-0920的漏洞实际上是在2016年9月发现的，并在Linux内核邮件列表中讨论过。甚至在2016年就已经开发了一个安全补丁，但最终没有提交。2021年7月，在检测到针对Android的在野exploit后，该漏洞终于在Linux内核中得到修复。然后，该补丁在2021年11月进入了Android安全公告。

对于CVE-2021-1048漏洞，虽然当时在Linux内核中已经得到了修复，但是直到14个月后Android仍有没有提供相应的安全补丁。实际上，Linux内核受这个问题的影响的时间只有几周，但由于Android系统的补丁机制，对于一些Android设备来说，这几周时间几乎变成了一年多。如果一个Android设备制造商与上游内核保持同步，那么他们很可能当时就修复了这个漏洞。但许多设备，如最近的三星设备，并没有这样做，因此，它们仍然面临这些漏洞的威胁。

Microsoft Exchange Server

2021年，发现了5个针对Microsoft Exchange Server的在野0-day漏洞。这是自我们开始追踪在野0-day漏洞以来，首次发现和披露针对Exchange服务器的在野0-day漏洞。其中，前四个（CVE-2021-26855、CVE-2021-26857、CVE-2021-26858和CVE-2021-27065）漏洞都是在同一时间披露和修复的，并且在同一个攻击活动中被使用；第五个（CVE-2021-42321）漏洞是在2021年11月单独进行修复的。CVE-2021-42321漏洞是在“Tianfu Cup”大赛中被披露的，然后被微软作为在野0-day漏洞公之于众。虽然在CVE-2021-42321漏洞链中没有披露其他在野0-day漏洞，但由于CVE-2021-42321是一个需要经过身份验证后才能利用的安全漏洞，因此，攻击者至少需要另一个0-day漏洞，才能成功利用它。

在同一个攻击活动中使用的4个Exchange在野0-day漏洞中，CVE-2021-26855，也被称为“ProxyLogon”漏洞，是唯一一个无需身份验证的0-day漏洞。CVE-2021-26855是一个服务器端请求伪造（SSRF）的漏洞，允许未经身份验证的攻击者以Exchange服务器的身份发送任意的HTTP请求。其他3个漏洞是需要经过身份验证的漏洞。例如，CVE-2021-26858和CVE-2021-27065漏洞允许攻击者向系统写入任意文件。CVE-2021-26857漏洞则是一个远程代码执行漏洞，它是由于统一消息服务中的一个反序列化漏洞所致。这允许攻击者以具有特权的SYSTEM用户身份运行代码。

对于CVE-2021-42321漏洞，像CVE-2021-26858一样，也是因不安全的反序列化造成的身份验证后的RCE漏洞。微软似乎在尝试加固Exchange时无意中引入了另一个反序列化漏洞。

虽然2021年在Exchange中检测到并披露了大量的0-day漏洞，但重要的是要记住，它们都只在两个不同攻击者活动中被用作0-day漏洞。这就是一个很好的例子，说明为什么我们不建议使用产品中的0-day数量作为评估产品安全的指标。与仅凭一个0-day漏洞就能得手相比，要求借助四个0-day漏洞才能成功，其利用难度要大得多。

虽然这是自Project Zero开始追踪在野漏洞以来，第一次发现和披露Exchange服务器的在野0-day漏洞，但这并不意外。在2020年，针对Exchange服务器的n-day漏洞利用代码就出现了。不管这是攻击者开始利用0-day漏洞攻击Exchange服务器的第一年，还是防御者开始检测到相应0-day漏洞利用代码的第一年，这都不是一个意外的变化，2022年这一趋势将大概率延续。

悬而未决问题

虽然在检测和披露方面取得了进展，但这种进展表明仍有许多工作要做。我们获得的数据越多，面临的问题就越多，如检测中的偏差，我们遗漏了什么，为什么会遗漏，以及供应商和研究人员都需要提供更高的透明度。

除非攻击者决定愉快地与我们分享他们所有的漏洞，否则，我们无从知晓已经披露的0-day漏洞所占的比例到底是多少。然而，然而，当我们将自己作为安全研究人员的专业知识与业内其他人的见闻结合在一起时，就能弥补一部分缺失数据。所以，当我们迈向2022年时，我们会问自己一些关键问题：

0-day漏洞在哪里？

尽管2021年发现的0-day漏洞的数量很多，但在发现的0-day漏洞中，缺乏针对关键目标的漏洞。例如，我们知道像WhatsApp、Signal、Telegram等即时通讯软件都是攻击者感兴趣的目标，但在过去的一年中，只发现了1个针对此类程序的0-day漏洞，具体来说是针对iMessage的漏洞。自我们从2014年年中开始跟踪0-day漏洞以来，总共发现了2个针对这类目标的漏洞：2019年的WhatsApp 0-day漏洞，以及2021年发现的iMessage 0-day漏洞。

除了时通讯软件，我们还希望看到针对其他平台/目标的0-day漏洞，但遗憾的是，基本上没有或很少有公开的样本。例如，自2014年年中以来，针对macOS和Linux分别只找到1个在野0-day漏洞。此外，目前还没有发现针对云计算、CPU漏洞或其他手机部件（如WiFi芯片或基带）的在野0-day漏洞。

这就导致了这样一个问题：之所以出现这种情况，到底是由于没有检测到、没有披露，还是两者兼而有之？

对于某些供应商，至今尚未公布针对自家产品的在野0-day漏洞，是因为他们从未发现这类漏洞，还是因为他们知情不报？

除非厂商告诉我们，他们会公开披露其平台上所有漏洞的利用状态，否则我们这些公众根本就不知道：没有披露是否意味着没有发现漏洞已被利用的证据，或者有证据，但厂商只是没有公开分享这些信息。值得庆幸的是，这个问题有一个相当明确的解决方案：所有设备和软件供应商都同意在有证据表明其产品中的漏洞正在被在野利用时公开披露这些信息。

发现的漏洞具有相同的模式，是因为我们只熟悉这类漏洞的检测方式所致吗？

正如我们在本报告前面所描述的，我们在2021年看到的所有0-day漏洞都与之前看到的漏洞有相似之处。这让我们怀疑这是否真的能代表攻击者正在使用的东西。攻击者是否真的只利用已知类型和组件中的漏洞获得了成功？还是我们只能检测到所有这些具有已知漏洞模式的0-day漏洞，因为那是我们已经熟悉这类漏洞的检测方法？已经发表的安全研究表明，攻击者在大多数情况下仍然能够利用已知组件和已知类型的漏洞获得成功。但我们仍然期望发现一些新奇的、意想不到的漏洞类型。我们早在2019年的年度回顾中就提出了这个问题，目前仍未找到答案。

spl0itz在哪里？

对于一个成功的漏洞利用代码来说，由两个关键部分组成：被利用的漏洞以及漏洞利用方法（如何将该漏洞武器化）。

不幸的是，这份报告只能真正分析其中一个部分：漏洞本身。虽然去年找到了58个0-day漏洞，但是公开的exploit样本却只有5个。在野外发现的0-day漏洞是攻击者的失败案例，也是防御者了解攻击者正在做什么，进而提高漏洞利用的难度、耗时、资金成本的难得机会。然而，如果没有exploit样本或基于样本的详细的技术分析，我们只能专注于修复漏洞，而无法找到阻止漏洞被利用的方法。这记忆意味着，攻击者能够继续使用他们现有的攻击方法，而不必大费周章地设计和开发新型的攻击方法。虽然分享exploit样本可能面临巨大的挑战（我们也是如此！），但是我们仍然希望在2022年能与大家分享更多的漏洞样本或详细的技术分析，这样的话，我们就能充分利用各种信息，进一步提高安全漏洞的利用难度。

顺便说一句，如果您乐于分享的exploit样本的话，欢迎与我们取得联系。无论是与我们分享，让我们写一份详细的技术描述和分析，还是让我们公开分享，我们都很期待。

小结

回顾2021年，脑海中浮现的场景是“蹒跚学步”。我们可以看到，行业虽然在检测和披露0-day漏洞的exploit方面取得了明显的进步，但是同时也要看到，这方面还存在很大的改进空间。作为一个行业，我们没有让0-day漏洞的利用变得难如登天。攻击者仍然能够利用类似于我们之前看到的漏洞以及之前作为攻击面讨论过的组件中的漏洞获得了成功。我们的目标是迫使攻击者要想开发exploit必须全部从头开始：必须挖掘全新的漏洞，必须投入大量的时间来学习和分析全新的攻击面，必须开发全新的漏洞利用方法。虽然我们在检测和披露方面取得了显著进展，但是有待改善的领域仍然很多。

虽然这一切看起来令人生畏，但也要看到希望：我们在之前令人畏惧的目标上取得了明显的进展。在2019年，我们检测到的0-day exploit数量严重不足，而2年后，这方面的数量实现了翻番。因此，虽然还有很多工作要做，但并非遥不可及。科技和安全行业可以采取一些具体步骤来取得更大的进展，比如：

• 让所有供应商在有证据表明其产品中的漏洞遭到利用时公开披露成为一种行业标准行为。
• 供应商和安全研究人员共享漏洞exploit样本或漏洞利用技术的详细描述。
• 继续协同努力降低内存损坏型漏洞数量，或提高其利用难度。

2021年，我们在提高0-day漏洞利用难度方面已经步入正轨，并取得长足进步，但我们仍有许多方面亟待改善。

原文地址：https://googleprojectzero.blogspot.com/