2021年野外利用0-day漏洞回顾

作者：Maddie Stone，Google Project Zero

这是我们第三年对野外利用的0-day漏洞进行年度回顾[2020、2019]。每年我们都会回顾所有被检测和披露的野外0-day漏洞，综合分析我们认为的趋势和要点。本报告的目标不是详细说明每个单独的漏洞利用，而是将全年漏洞利用作为一个整体进行分析，寻找趋势、差距、经验教训、成功案例等。如果您对单个漏洞利用的分析感兴趣，请查看我们的根本原因分析仓库。

我们进行并分享这项分析是为了让0-day攻击变得困难。我们希望攻击者使用0-day能力的成本更高、资源更密集、总体上更困难。2021年凸显了在我们追求让攻击者更难利用0-day漏洞攻击用户的过程中保持不懈努力的重要性。我们反复听到政府如何针对全球的记者、少数群体、政治家、人权捍卫者甚至安全研究人员。我们在安全和技术社区做出的决定可能对社会和我们同胞的生活产生实际影响。

我们将在本文正文中为我们的结论提供证据和过程，然后在结论中总结我们对下一步行动的想法和对2022年的希望。如果您不喜欢深入研究技术细节，可以随时查看执行摘要和结论部分。

执行摘要

2021年检测并披露了58个野外0-day漏洞，这是自Project Zero于2014年中开始跟踪以来记录的最高数字。这比2015年检测到的先前最大值28个多出一倍多，尤其引人注目的是2020年只检测到25个。自2014年中以来，我们一直在此电子表格中跟踪公开已知的野外0-day漏洞利用。

虽然我们经常谈论野外使用的0-day漏洞利用数量，但我们实际讨论的是被检测和披露为野外的0-day漏洞利用数量。这引出了我们的第一个结论：我们认为2021年野外0-day漏洞的大幅增加是由于这些0-day漏洞的检测和披露增加，而不仅仅是0-day漏洞利用的使用增加。

有了这个创纪录数量的野外0-day漏洞进行分析，我们看到攻击者的方法实际上与往年相比变化不大。攻击者使用相同的漏洞模式和利用技术，针对相同的攻击面取得了成功。Project Zero的使命是“让0day攻击变得困难”。当攻击者总体上无法使用公共方法和技术来开发他们的0-day漏洞利用时，0-day攻击将变得更加困难。当我们查看2021年使用的这58个0-day漏洞时，我们看到的是与先前和公开已知漏洞相似的0-day漏洞。只有两个0-day漏洞脱颖而出：一个因其漏洞利用的技术复杂性，另一个因其使用逻辑漏洞来逃逸沙箱。

因此，虽然我们认识到行业在检测和披露野外0-day漏洞方面有所改进，但我们也承认还有更多改进工作要做。能够获取更多关于攻击者实际如何使用0-day漏洞的“真实情况”表明，他们能够通过使用先前已知的技术和方法取得成功，而不必投资开发新技术。这是科技行业一个明显的改进机会。

2021年我们有了比过去更多的数据点来了解攻击者行为。然而，拥有所有这些数据让我们比以往有了更多问题。不幸的是，积极使用0-day漏洞利用的攻击者不会分享他们正在使用的0-day漏洞，也不会告诉我们跟踪中遗漏了多少比例的0-day漏洞，因此我们永远无法确切知道目前有多少比例的0-day漏洞被发现和公开披露。

基于我们对2021年0-day漏洞的分析，我们希望看到2022年在以下方面取得进展，以继续朝着让0-day攻击变得困难的方向迈进：

1. 所有供应商同意在其安全公告中披露漏洞的野外利用状态。
2. 更广泛地共享漏洞利用样本或详细的技术描述。
3. 继续共同努力减少内存损坏漏洞或使其无法被利用。推出将显著影响内存损坏漏洞可利用性的缓解措施。

野外0-day漏洞创纪录的一年

2021年是野外0-day漏洞创纪录的一年。那么发生了什么？

是软件安全性变差了吗？还是攻击者更多地使用了0-day漏洞利用？或者我们检测和披露0-day漏洞的能力提高了？在观察从2020年到2021年的显著增长时，我们认为主要是后者解释了这个现象。虽然我们相信过去几年攻击者对0-day漏洞利用的兴趣和投资稳步增长，并且安全性仍然迫切需要改进，但安全行业检测和披露野外0-day漏洞利用的能力似乎是2021年观察到的0-day漏洞利用增加的主要原因。

虽然我们经常谈论“野外使用的0-day漏洞利用”，但我们实际跟踪的是“被检测和披露为野外使用的0-day漏洞利用”。导致这个数字增加的因素不仅仅是使用，最显著的是：检测和披露。更好地检测0-day漏洞利用和更透明地披露被利用的0-day漏洞是行业安全和进展的积极指标。

总体而言，我们可以将野外0-day漏洞数量的增加分解为：

• 更多野外0-day漏洞利用的检测
• 更多野外0-day漏洞利用的公开披露

更多检测

在2019年回顾中，我们写了关于“检测赤字”的内容。我们指出：“作为一个社区，我们检测野外使用的0-day漏洞的能力严重不足，以至于由于我们收集的数据缺乏（和存在偏见），我们无法得出重要结论。”在过去的两年里，我们认为这个差距已经取得了一些进展。

从轶事来看，我们听到越来越多的人说他们已经开始更多地致力于检测0-day漏洞利用。从数量上看，虽然是一个非常粗略的衡量标准，但我们看到被归功于报告野外0-day漏洞的实体数量也在增加。有理由认为，如果致力于寻找0-day漏洞利用的人数增加，那么检测到的野外0-day漏洞利用数量可能会增加。

我们还看到检测自己产品中野外0-day漏洞的供应商数量在增加。无论这些供应商之前是否致力于检测，供应商似乎在2021年找到了更成功的方法。供应商可能拥有最多的遥测数据以及对其产品的整体知识和可见性，因此他们投资于（并希望成功）检测针对自己产品的0-day漏洞非常重要。如上图所示，供应商在自己产品中发现的野外0-day漏洞数量显著增加。Google在自己产品中发现了7个野外0-day漏洞，Microsoft在自己产品中发现了10个！

更多披露

检测到的野外0-day漏洞数量增加的第二个原因是这些漏洞的更多披露。Apple和Google Android（我们将“Google Android”与“Google”区分开来，因为Google Chrome在过去几年一直在注释其安全公告）分别于2020年11月和2021年1月开始在其安全公告中标注有关潜在野外利用的信息。当供应商不注释其发布说明时，我们知道0-day漏洞被野外利用的唯一方式是发现该利用的研究人员主动公开。如果Apple和Google Android没有开始注释其发布说明，公众可能至少不会知道7个Apple野外0-day漏洞和5个Android野外0-day漏洞。为什么？因为这些漏洞是由“匿名”报告者报告的。如果报告者不希望获得漏洞的功劳，他们不太可能公开表示有利用迹象。如果Apple和Google Android没有开始透明地注释其安全公告，这12个0-day漏洞就不会被列入今年的列表。

向多年来一直为透明度而注释其安全公告的Microsoft、Google Chrome和Adobe表示敬意和感谢！也感谢Apache在过去一年中为CVE-2021-41773注释了其发布说明。

Qualcomm和ARM产品中的野外0-day漏洞在Android安全公告中被标注为野外利用，但未在供应商自己的安全公告中标注。

很可能在2021年，还有其他0-day漏洞被野外利用和检测到，但供应商没有在其发布说明中提到这一点。在2022年，我们希望更多供应商开始注明他们何时修补了已被野外利用的漏洞。在我们确信所有供应商都透明地披露野外状态之前，存在一个大问题：有多少野外0-day漏洞被发现，但未被供应商公开标注。

新年，旧技术

2021年我们有了创纪录数量的“数据点”来了解攻击者实际如何使用0-day漏洞利用。但让我们有点惊讶的是，在所有数据点中，这些数据中没有任何新内容。0-day漏洞利用被认为是攻击者可以使用的最先进的攻击方法之一，因此很容易得出结论认为攻击者必须使用特殊技巧和攻击面。但相反，我们在2021年看到的0-day漏洞通常遵循先前在公开研究中看到的相同漏洞模式、攻击面和利用“形态”。一旦“0-day攻击变得困难”，我们预计攻击者要取得成功，就必须在使用前所未见的利用方法的新攻击面中找到新的漏洞类别。总的来说，今年的数据并没有显示出这一点。除了两个例外（在下面的iOS部分描述）外，在58个漏洞中，我们看到的一切都相当“平淡”或标准。

在今年的58个野外0-day漏洞中，39个（占67%）是内存损坏漏洞。内存损坏漏洞在过去几十年一直是攻击软件的标准，攻击者仍然通过这种方式取得成功。在这些内存损坏漏洞中，大多数也坚持使用非常流行和众所周知的漏洞类别：

• 17个释放后使用（use-after-free）
• 6个越界读写（out-of-bounds read & write）
• 4个缓冲区溢出（buffer overflow）
• 4个整数溢出（integer overflow）

在接下来的部分中，我们将深入探讨今年看到野外0-day漏洞的每个主要平台。我们将分享趋势并解释为什么我们看到的情况相当普通。

Chromium（Chrome）

Chromium在2021年检测和披露的0-day漏洞数量创历史新高，达到14个。在这14个中，10个是渲染器远程代码执行漏洞，2个是沙箱逃逸，1个是信息泄露，1个用于在Android应用程序（非Google Chrome）中打开网页。

这14个0-day漏洞位于以下组件中：

• 6个JavaScript引擎 - v8（CVE-2021-21148、CVE-2021-30551、CVE-2021-30563、CVE-2021-30632、CVE-2021-37975、CVE-2021-38003）
• 2个DOM引擎 - Blink（CVE-2021-21193和CVE-2021-21206）
• 1个WebGL（CVE-2021-30554）
• 1个IndexedDB（CVE-2021-30633）
• 1个webaudio（CVE-2021-21166）
• 1个Portals（CVE-2021-37973）
• 1个Android Intents（CVE-2021-38000）
• 1个Core（CVE-2021-37976）

当我们查看这些漏洞针对的组件时，它们都是先前在公共安全研究和先前漏洞利用中见过的攻击面。如果说有什么不同的话，那就是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年之前，Apple只承认了1个公开已知的针对WebKit/Safari的野外0-day漏洞，这是由于外部研究人员的分享。2021年有7个。这使得我们很难评估趋势或变化，因为我们没有历史样本可供参考。相反，我们将在其他未被确认为野外的Safari漏洞以及其他浏览器野外0-day漏洞的背景下看待2021年的WebKit漏洞。

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

• 4个JavaScript引擎 - JavaScript Core（CVE-2021-1870、CVE-2021-1871、CVE-2021-30663、CVE-2021-30665）
• 1个IndexedDB（CVE-2021-30858）
• 1个Storage（CVE-2021-30661）
• 1个Plugins（CVE-2021-1879）

一个半意外是没有检测和披露DOM漏洞。在往年，DOM引擎中的漏洞通常占野外浏览器0-day漏洞的15-20%，但2021年没有为WebKit检测和披露任何DOM漏洞。

如果攻击者开始转向其他模块，如第三方库或IndexedDB等，这并不奇怪。这些模块可能对攻击者来说更有前景，因为漏洞可能存在于多个浏览器或平台中的机会更大。例如，Chromium中的webaudio漏洞CVE-2021-21166也存在于WebKit中，并作为CVE-2021-1844修复，尽管没有证据表明它在WebKit中被野外利用。2021年针对Safari使用的IndexedDB野外0-day漏洞CVE-2021-30858与2020年1月在Chromium中修复的一个漏洞非常非常相似。

Internet Explorer

自从我们开始跟踪野外0-day漏洞以来，Internet Explorer每年都有相当一致数量的0-day漏洞。2021年实际上与2016年并列，成为我们跟踪以来Internet Explorer野外0-day漏洞最多的一年，尽管Internet Explorer在网络浏览器用户中的市场份额持续下降。

那么，为什么尽管市场份额发生变化，我们看到的野外0-day漏洞数量变化却如此之小？Internet Explorer仍然是初始进入Windows计算机的成熟攻击面，即使用户不使用Internet Explorer作为其互联网浏览器。虽然0-day漏洞数量与我们先前几年看到的情况相当一致，但针对的组件和漏洞利用的交付方式发生了变化。2021年看到的4个0-day漏洞中有3个针对MSHTML浏览器引擎，并通过非Web方式交付。相反，它们通过Office文档或其他文件格式交付给目标。

这四个0-day漏洞针对以下组件：

• MSHTML浏览器引擎（CVE-2021-26411、CVE-2021-33742、CVE-2021-40444）
• JavaScript引擎 - JScript9（CVE-2021-34448）

对于CVE-2021-26411，活动的目标最初收到一个.mht文件，提示用户在Internet Explorer中打开。一旦在Internet Explorer中打开，漏洞利用就会被下载并运行。CVE-2021-33742和CVE-2021-40444通过恶意Office文档交付给目标。

CVE-2021-26411和CVE-2021-33742是两种常见的内存损坏漏洞模式：由于在两个使用对象的操作之间存在用户控制的回调，用户在该回调期间释放对象导致的释放后使用，以及缓冲区溢出。

在使用CVE-2021-40444的漏洞利用链中使用了几个不同的漏洞，但MSHTML中的那个是：一旦Office文档打开，有效载荷就会运行：下载CAB文件，解压缩，然后执行该CAB中DLL内的函数。与前两个MSHTML漏洞不同，这是URL解析中的逻辑错误，而不是内存损坏漏洞。

Windows

Windows是我们看到的针对组件变化最大的平台。然而，这种转变已经进行了几年，并且随着Windows 7在2020年终止支持而预测到，因此这仍然不是特别新颖。

2021年有10个Windows野外0-day漏洞，针对7个不同的组件：

• 2个增强加密提供程序（CVE-2021-31199、CVE-2021-31201）
• 2个NTOS内核（CVE-2021-33771、CVE-2021-31979）
• 2个Win32k（CVE-2021-1732、CVE-2021-40449）
• 1个Windows更新修复程序（CVE-2021-36948）
• 1个SuperFetch（CVE-2021-31955）
• 1个dwmcore.dll（CVE-2021-28310）
• 1个ntfs.sys（CVE-2021-31956）

针对的不同组件数量是相对于过去几年的转变。例如，2019年75%的Windows 0-day漏洞针对Win32k，而2021年Win32k仅占Windows 0-day漏洞的20%。之所以这是预期和预测的，是因为2019年针对Win32k的8个0-day漏洞中有6个没有针对当时最新版本的Windows 10；它们针对的是旧版本。随着Windows 10的推出，Microsoft开始投入越来越多的资源来锁定Win32k的攻击面，因此随着这些旧版本终止支持，Win32k的吸引力越来越小。

与多年来看到的许多Win32k漏洞类似，2021年的两个Win32k野外0-day漏洞是由于自定义用户回调。用户在回调期间调用改变对象状态的函数，而Win32k没有正确处理这些变化。CVE-2021-1732是由于xxxClientAllocWindowClassExtraBytes中的用户回调导致的类型混淆漏洞，从而导致越界读写。如果在回调期间调用NtUserConsoleControl，窗口结构中会设置一个标志，表示某个字段是内核堆中的偏移量。xxxClientAllocWindowClassExtraBytes不检查这一点，并将该字段作为用户模式指针写入而不清除标志。2022年检测和披露的第一个野外0-day漏洞CVE-2022-21882是由于CVE-2021-1732实际上没有完全修复。攻击者找到了一种绕过原始补丁并仍然触发漏洞的方法。CVE-2021-40449是NtGdiResetDC中的释放后使用漏洞，由于对象在用户回调期间被释放。

iOS/macOS

正如上面“更多披露”部分所讨论的，2021年是Apple在其发布说明中标注漏洞野外状态的第一整年。今年检测并披露了5个iOS野外0-day漏洞。还发现了第一个公开已知的macOS野外0-day漏洞（CVE-2021-30869）。在本节中，我们将一起讨论iOS和macOS，因为：1）这两个操作系统包含相似的组件；2）macOS的样本量非常小（只有这一个漏洞）。

对于总共5个iOS和macOS野外0-day漏洞，它们针对3个不同的攻击面：

• IOMobileFrameBuffer（CVE-2021-30807、CVE-2021-30883）
• XNU内核（CVE-2021-1782和CVE-2021-30869）
• CoreGraphics（CVE-2021-30860）
• CommCenter（FORCEDENTRY沙箱逃逸 - 已申请CVE，尚未分配）

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

一个iOS 0-day漏洞和macOS 0-day漏洞都利用了XNU内核中的漏洞，并且这两个漏洞都在与XNU的进程间通信（IPC）功能相关的代码中。CVE-2021-1782利用了mach凭证中的漏洞，而CVE-2021-30869利用了mach消息中的漏洞。这不是我们第一次看到针对mach凭证和mach消息的iOS野外0-day漏洞，更不用说公共安全研究了。CVE-2019-6625作为针对iOS 11.4.1-12.1.2的漏洞利用链的一部分被利用，也是mach凭证中的一个漏洞。

Mach消息也一直是公共安全研究的热门目标。2020年也有两个mach消息中的野外0-day漏洞：CVE-2020-27932和CVE-2020-27950。今年的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上介绍它的原因。野外利用只针对macOS 10，但使用了与介绍中相同的利用技术。

两个FORCEDENTRY漏洞利用（CVE-2021-30860和沙箱逃逸）是今年唯一让我们所有人都“惊叹！”的时刻。对于CVE-2021-30860，CoreGraphics中的整数溢出，这是因为：

1. 多年来，我们都听说过攻击者如何使用0点击iMessage漏洞，现在我们终于有了一个公开的例子，以及
2. 漏洞利用是一件令人印象深刻的艺术品。

沙箱逃逸（已申请CVE，尚未分配）令人印象深刻，因为这是我们很少看到的在野外仅使用逻辑漏洞而不是标准内存损坏漏洞的沙箱逃逸之一。

对于CVE-2021-30860，漏洞本身并不特别引人注目：CoreGraphics PDF解码器的JBIG2解析器中的一个经典整数溢出。然而，Samuel Groß和Ian Beer将漏洞利用描述为“他们见过的最技术复杂的漏洞利用之一”。他们的博客文章分享了所有细节，但亮点是漏洞利用使用JBIG2中可用的逻辑运算符构建NAND门，用于构建自己的计算机体系结构。然后，漏洞利用使用这个新的自定义体系结构编写其余部分。从他们的博客文章中：

使用超过70,000个定义逻辑位操作的段命令，他们定义了一个小型计算机体系结构，具有诸如寄存器和完整的64位加法器和比较器等功能，他们使用这些功能来搜索内存和执行算术运算。它没有Javascript快，但它在计算上是等价的。

沙箱逃逸漏洞利用的引导操作被编写为在这个逻辑电路上运行，整个事情运行在这个奇怪的、模拟的环境中，该环境是通过JBIG2流的单次解压缩创建的。这非常不可思议，同时也非常可怕。

这是一个让0-day漏洞利用变得困难可能是什么样子的例子：攻击者必须开发一种新的、新颖的方式来利用漏洞，而这种方法需要大量的专业知识和/或时间来开发。今年，两个FORCEDENTRY漏洞利用是58个0-day漏洞中唯一真正让我们印象深刻的。希望在将来，门槛已经提高，任何成功的利用都需要达到这个水平。

Android

今年检测并披露了7个Android野外0-day漏洞。在2021年之前，只有1个，那是在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设备”的能力，他们通常需要维护许多不同的漏洞利用，以覆盖相当大比例的Android生态系统。然而，如果攻击者选择针对GPU内核驱动程序而不是其他组件，他们只需要有两个漏洞利用，因为大多数Android设备使用两种GPU之一：要么是Qualcomm Adreno GPU，要么是ARM Mali GPU。

公共安全研究在过去几年也反映了这种选择。在开发针对Android设备的完整漏洞利用链（出于防御目的）时，Guang Gong、Man Yue Mo和Ben Hawkes都选择攻击GPU内核驱动程序以进行本地权限提升。看到野外0-day漏洞也针对GPU，更多的是证实而不是启示。在针对GPU驱动程序的5个0-day漏洞中，3个在Qualcomm Adreno驱动程序中，2个在ARM Mali驱动程序中。

两个非GPU驱动程序0-day漏洞（CVE-2021-0920和CVE-2021-1048）针对上游Linux内核。不幸的是，这两个漏洞与2019年看到的Android野外0-day漏洞共享一个单一特征：所有3个在Android中被利用之前都是先前已知的上游漏洞。虽然样本量很小，但看到100%已知的针对内核的Android野外0-day漏洞实际上是在被利用之前就已经知道的漏洞，这仍然相当引人注目。

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

CVE-2021-1048在Linux内核中修复后，在Android中未修补长达14个月。Linux内核实际上只易受此问题影响几周，但由于Android的修补实践，对于某些Android设备来说，这几周变成了几乎一年。如果Android OEM同步到上游内核，那么他们可能在某个时候修补了该漏洞。但许多设备，如最近的三星设备，没有同步，因此仍然易受攻击。

Microsoft Exchange Server

2021年，有5个野外0-day漏洞针对Microsoft Exchange Server。这是自我们开始跟踪野外0-day漏洞以来，首次检测和披露任何Exchange Server野外0-day漏洞。前四个（CVE-2021-26855、CVE-2021-26857、CVE-2021-26858和CVE-2021-27065）都在同一时间披露和修补，并在一次行动中一起使用。第五个（CVE-2021-42321）于2021年11月单独修补。CVE-2021-42321在天府杯上演示，然后被Microsoft在野外发现。虽然没有其他野外0-day漏洞作为与CVE-2021-42321相关的链的一部分被披露，但攻击者至少需要另一个0-day漏洞才能成功利用，因为CVE-2021-42321是一个身份验证后漏洞。

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

对于第二次活动，CVE-2021-42321与CVE-2021-26858一样，是由于不安全反序列化导致的身份验证后RCE漏洞。似乎Microsoft在试图强化Exchange时，无意中引入了另一个反序列化漏洞。

虽然2021年检测和披露了大量Exchange中的0-day漏洞，但重要的是要记住，它们仅在两个不同的活动中被用作0-day漏洞。这是一个例子，说明为什么我们不建议使用产品中的0-day漏洞数量作为评估产品安全性的指标。要求攻击者使用四个0-day漏洞才能成功，比攻击者只需要一个0-day漏洞就能成功获得访问权限更可取。

虽然这是自Project Zero开始跟踪以来首次检测和披露Exchange野外0-day漏洞，但这并非意外。2020年有Exchange Server的n-day利用。无论这是攻击者开始0-day利用的第一年，还是防御者开始检测0-day利用的第一年，这都不是意外的演变，我们可能会看到它持续到2022年。

悬而未决的问题

虽然在检测和披露方面取得了进展，但这种进展表明还有多少工作要做。我们获得的数据越多，关于检测中的偏见、我们遗漏了什么以及为什么遗漏，以及供应商和研究人员需要更多透明度的问题就越多。

直到攻击者决定愉快地与我们分享他们所有漏洞利用的那一天，我们无法完全知道有多少百分比的0-day漏洞是公开已知的。然而，当我们汇集我们作为安全研究人员的专业知识以及行业其他人的轶事时，它描绘了一幅我们很可能