“Project Zero”是一项由谷歌成立的互联网安全项目，成立时间为2014年7月。该团队主要由谷歌内部顶尖安全工程师组成，旨在发现、追踪和修补全球性的软件安全漏洞。自2019起，团队每年会对过去一年内检测到的0-day漏洞在野利用进行回顾并发布报告。2021年内，“Project Zero”共检测并披露了58个在野外的0-day漏洞，这一数字创下了项目2014年成立以来的新纪录。本篇报告中，“Project Zero”团队详细向我们介绍了被检测到的58个0-day漏洞的类型和攻击模式，并分析了2021年0-day数据暴增的原因。另外，在报告中，我们也可以清晰地看到团队在2022年的工作方向。

以下是报告正文：

这是我们自2019年起连续第三年对0-day漏洞的在野利用进行回顾。

每一年，我们都会回顾这一年内在野外发现和披露的所有0-day漏洞，并对其进行综合考量。本报告的目的并不是对每个漏洞进行分析，而是将一年来的漏洞作为一个整体进行分析，寻找趋势、差距、经验教训和成功的防护案例。

我们撰写并分享这份报告是希望增加0-day漏洞利用的难度。我们希望0-day利用的成本不断增加，当披露和防护的资源更集中，攻击者自然更难对其加以利用。

我们将在正文中展示完整的论证过程，然后在结论中总结我们对未来的展望与操作方法。如果你并不喜欢深入挖掘细节，那就看看执行摘要和结论吧。

重点发现

2021年内共检测并披露了58个在野外的0-day漏洞，这是自2014年年中“Project Zero”项目开始追踪以来最多的。此前的最大值是2015年检测到的28个，这次有足足两倍之多，尤其是，2020年只检测到25个。自2014年年中以来，我们一直在这个电子表格中追踪已知的公开的0-day漏洞。

虽然我们经常讨论0-day漏洞的在野利用数量，但我们实际上讨论的是在野外检测到和被披露的0-day漏洞的数量。这就引出了我们的第一个结论:我们认为，2021年报告显示0-day漏洞的大幅增加是由于对它们检测和披露的渠道增多，而不是简单地只是0-day漏洞的在野利用增加。

从数据中我们可以看出，其实攻击者的方法与前几年相比并没有太大的变化。攻击者使用的是相同的漏洞模式和挖掘技术，并针对相同的攻击面加以打击。 “Project Zero”的使命是“增加0-day攻击的难度”。

总体而言，如果攻击者无法使用普遍已知方法和技术来挖掘 0-day漏洞， 0-day的利用势必将有所降低。 当我们回顾2021年内使用的58个0-day漏洞时，我们看到它们与以前公开的漏洞如此相似，只有两个脱颖而出：一个是因为其漏洞利用的技术复杂性，另一个是因为它使用逻辑错误来逃离沙盒。

因此，虽然我们看到业界在检测和披露0-day漏洞方面取得了进步，但也必须承认还有很多工作有待改进。

2021年，我们拥有比过去更多的数据点来了解攻击者的行为。 然而，这些数据也给我们带来了比以前更多的问题。 不幸的是，积极使用 0-day漏洞攻击的攻击者不会分享他们的“先进经验”，也不会分享我们在追踪中遗漏的0-day漏洞的百分比，因此我们永远无法确切知道目前有多少0-day漏洞被发现并被公开披露。

基于我们对2021年0-day的分析，我们希望在2022年看到以下进展，以便继续采取措施，努力实现目标:

1. 所有供应商都同意在其安全公告中披露漏洞的在野利用状况。

2. 漏洞利用样本或漏洞利用的详细技术描述被更广泛地共享。

3. 继续协同努力减少内存损坏漏洞或使其无法利用。启动将显著影响内存破坏漏洞可利用性的缓解措施。

野外0-day数量创纪录

2021是野外0-day数量创纪录的一年。

是软件安全性越来越差了，还是攻击者使用了更多的0-day漏洞？ 抑或是我们发现和披露 0 0-day漏洞的能力有所提高？ 对于2020 年到 2021年的显着增长，我们认为这主要应由后者解释。 尽管过去几年攻击者对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漏洞。通常，供应商对他们自身的产品了解最为全面、未来预期更符合实际更精准，所以他们投资于（并希望能成功）检测针对自身产品的 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漏洞，Android至少有存在5个。为什么？因为这些漏洞是由"匿名"记者报道的。如果记者不想因为这个漏洞而受到赞扬，他们就不太可能公开其被利用的具体情况。如果苹果和谷歌 Android还没有开始在他们的安全建议中透明地披露漏洞，那这12个0-day就不会被列入今年的名单。

感谢微软、谷歌Chrome和Adobe多年来一直在为他们的安全公告添加注释， 感谢Apache在过去的一年里为CVE-2021-41773注释了他们的发布说明。

高通和 ARM 产品的 in-the-wild 0day 在Android 安全公告中被注释为in-the-wild，但在供应商自己的安全公告中没有。

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

新一年，0-day漏洞仍然没有新意

2021年，0-day的数量有所增加，但它们的攻击方式却没有太多的新意。一直以来，0-day 漏洞被认为是攻击者可以使用有效的攻击手段之一，因此外界普遍相信，攻击者一定使用了特殊的技巧和方法。但相反的是，我们在2021年看到的0-day漏洞并没有跳脱出常规技术点，它们通常遵循之前在公共研究中看到的相同的漏洞模式、攻击手段和攻击形态。一旦我们“增加0-day攻击的难度”这个目标实现，攻击者将不得不使用之前从未用过的漏洞挖掘技术，在新的攻击角度挖掘漏洞，而不是犹如今年的数据向我们展示的那样。

今年检测到的58个漏洞中除了2个例外（我们将在在下面的 iOS 部分中描述），我们所看到的一切都是“无聊的”、标准化的。

2021年检测到的野外0-day漏洞中，有39个也就是67%的比例是内存损坏漏洞。过去的几十年里，内存损坏漏洞一直是攻击软件的标准，并且仍然是攻击者取得成功的方式。在这些内存损坏漏洞中，大多数还坚持使用非常流行和知名的bug：

• 17 use-after-free

• 6 out-of-bounds read

• 4 buffer overflow

• 4 integer overflow

在接下来的部分中，我们将深入研究每一个我们看到的野外0-day的主要平台。我们将分享这些趋势，并解释为什么他们如此普通。

Chromium (Chrome)

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

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

• 6 JavaScript Engine - v8 (CVE-2021-21148, CVE-2021-30551, CVE-2021-30563, CVE-2021-30632, CVE-2021-37975, CVE-2021-38003)

• 2 DOM Engine - 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个是内存损坏漏洞。与去年类似，这些内存损坏漏洞中的大多数都是use-after-free漏洞。

Chromium的一些漏洞甚至与之前的野外0-day相似。CVE-2021-21166是webaudio中的ScriptProcessorNode::Process()中的一个问题，其中没有足够的密钥，这样在主线程和音频渲染线程中都可以同时访问缓冲区。CVE-2019-13720是2019年发现的0-day，是webaudio中的ConvolverHandler::Process()中的一个漏洞，它也没有足够的密钥，以至于主线程和音频渲染线程都可以同时访问缓冲区。

WebKit (Safari)

2021年之前，苹果只承认过1个公开已知的针对WebKit/Safari的0-day，还是由于外部研究人员的分享。2021一年就有7个。这使得我们很难评估趋势或变化，因为我们没有历史样本可供参考。相反，我们将在别的未知的Safari漏洞和其他浏览器的0-day漏洞的背景下研究2021年的WebKit漏洞。

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

• 4 Javascript Engine - 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中没有检测到。

如果攻击者开始转向其他模块，比如第三方库或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数字都非常稳定。 尽管Internet Explorer在网络浏览器用户中的市场份额逐年下降，但事实上，2021年我们追踪到的Internet Explorer 0-day与2016年是持平的。

那么，为什么尽管市场份额发生了变化，但我们看到的野外0-day的数量变化如此之小呢?因为对于Windows用户而言，即使用户不使用Internet Explorer作为其网络浏览器，Internet Explorer仍然可以成为一个受攻击点。虽然0-day漏洞的数量与我们前几年看到的大致相当，但攻击的目标组件和传输方法发生了变化。2021年出现的4个0-day中，有3个是针对MSHTML浏览器引擎的，并通过web以外的方法传输，它们是通过Office文档或其他文件格式传输给目标的。

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

• MSHTML browser engine (CVE-2021-26411, CVE-2021-33742, CVE-2021-40444)

• Javascript Engine - JScript9 (CVE-2021-34448)

CVE-2021-26411的目标最初会收到一个.mht文件，该文件提示用户在Internet Explorer中打开。一旦在打开，该漏洞就被下载并运行。CVE-2021-33742和CVE-2021-40444通过恶意Office文档发送给目标。CVE-2021-26411和CVE-2021-33742是两种常见的内存损坏漏洞模式:由于在使用对象的两个操作之间存在用户控制的回调而导致释放后使用，以及在回调期间用户释放对象，以及缓冲区溢出。

针对CVE-2021-26411目标的活动最初收到了一个.mht文件，该文件提示用户在Internet Explorer中打开。一旦在Internet Explorer中打开，该漏洞就被下载并运行。CVE-2021-33742和CVE-2021-40444通过恶意Office文档发送给目标。CVE-2021-26411和CVE-2021-33742是两种常见的内存损坏bug模式:由于在使用对象的两个操作之间存在用户控制的回调而导致释放后使用，以及在回调期间用户释放对象，以及缓冲区溢出。

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

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

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

Windows

与前几年相比，Windows是我们看到组件目标变化最大的平台。然而，这种转变已经进行了几年，并预计持续到2020年Windows 7系统寿命到期时，因此我们仍然不认为这是什么新鲜事。

在2021年，有10个Window野外0-day针对7个不同的组件:

• 2 Enhanced crypto provider (CVE-2021-31199, CVE-2021-31201)

• 2 NTOS kernel (CVE-2021-33771, CVE-2021-31979)

• 2 Win32k (CVE-2021-1732, CVE-2021-40449)

• 1 Windows update medic (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年，这个比例下降至20%。之所以我们能预料到这一点，是因为2019年针对Win32k的8个0-day漏洞中有6个没有针对当时最新版本的 Windows 10，而是以旧版本为目标。 随着 Windows 10投入越来越多的资源锁定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中的use-after-free漏洞，那是因为对象在用户回调期间被释放。

iOS/macOS

正如上文“更多的披露”部分所讨论的，2021年，苹果首次在其发布说明中标注野外漏洞信息, 检测并披露了5个iOS野外0-day和一个macOS野外0-day(CVE-2021-30869)。在本节中，我们将合并讨论iOS和macOS，原因有二：1) 这两个操作系统包含相似的组件，2) macOS 的样本容量非常小，仅披露一个漏洞。

5个iOS和macOS野外0-day漏洞瞄准了4种不同的攻击面:

• IOMobileFrameBuffer (CVE-2021-30807, CVE-2021-30883)

• XNU Kernel (CVE-2021-1782 & CVE-2021-30869)

• CoreGraphics (CVE-2021-30860)

• CommCenter (FORCEDENTRY sandbox escape - CVE requested, not yet assigned)

这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年，我们在IOMobileFrameBuffe检测出另一个0-day，CVE-2022-22587。

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

mach messages也一直是公共安全研究的热门。2020年，mach messages中检测出2个0-day漏洞：CVE-2020-27932和CVE-2020-2795。今年的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 的beta版本中得到修复，这也是为什么他们在Zer0Con上展示这个漏洞的原因。这个0-day在野利用仅针对macOS 10，但其利用的技术与本文上述的相同。

两个FORCEDENTRY 漏洞（CVE-2021-30860 和沙盒逃逸）是今年唯一让我们惊呼“哇！”的时候。今年，CVE-2021-30860，在CoreGraphics中出现整数溢出，这是因为：

1. 多年来，我们都听说过攻击者如何使用“零点击”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 driver (CVE-2020-11261, CVE-2021-1905, CVE-2021-1906)

• ARM Mali GPU driver (CVE-2021-28663, CVE-2021-28664)

• Upstream Linux kernel (CVE-2021-1048, CVE-2021-0920)

2021的7个0-day漏洞中，有5个是以GPU驱动程序为目标的。当我们想到Android生态系统的演变以及最近对Android的公共安全研究时，这一点也不令人惊讶。Android的生态系统是相当分散的：许多不同的内核版本、不同的制造商定制，等等。如果攻击者想要攻击Android设备，他们通常需要维护许多不同的漏洞才能覆盖比例相当的Android生态系统。然而，如果攻击者选择攻击GPU内核驱动程序而不是其他组件，他们只需要两个漏洞，因为大多数Android设备使用2个GPU中的1个：高通Adreno GPU或ARM Mali GPU。

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

两个非GPU驱动程序0-day漏洞（CVE-2021-0920 和 CVE-2021-1048）针对上游Linux内核。不幸的是，这两个漏洞与2019年检测到的Android野外0-day漏洞有一个共同特征：3个漏洞在被Android利用之前都是已知的。虽然样本量很小，但我们还是很惊讶地发现，所有已知的针对内核的Android 0-day漏洞在被利用之前都是已知的。

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

Linux内核打过补丁之后的14个月中，CVE-2021-1048都未及时在Android中打补丁。inux 内核实际上只在几周内易受这个问题的影响，但由于Android补丁的做法，这几个星期对一些Android设备来说简直如同长达一年。如果Android OEM同步到上游内核，那么他们很可能在某个时候针对该漏洞进行了修补。但许多设备，比如最近的三星设备，并没有这样做，因此很容易受到攻击。

Microsoft Exchange Server

2021年，共检测到5个针对Microsoft Exchange Server的0-day漏洞，这是自我们开始追踪野外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在天府杯上展示，然后被微软在野外发现。尽管CVE-2021-42321的链中没有其他的野外0-day被披露，但由于 CVE-2021-42321是个身份验证后漏洞，攻击者至少需要另一个0-day漏洞天才能成功利用它。

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

对于第二波发现的漏洞，CVE-2021-42321，与 CVE-2021-26858 一样，是由于不安全地反序列化而导致的身份验证后远程执行漏洞。 微软似乎在尝试强化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漏洞公开的比例究竟是多少。因此，进入2022年后，我们给自己整理了一些关键问题：

未知的0-day漏洞在哪儿？

尽管2021年内发现了许多0-day漏洞，但尚未探明0-day漏洞的关键目标是什么。 例如，我们知道 WhatsApp、Signal、Telegram信息传递应用程序是攻击者感兴趣的目标，但过去一年发现的众多0-day漏洞中，仅有1个iMessage 0-day是针对信息传递应用程序的。即使是2014年开始追踪行动以来也不过两个：2019 年的WhatsApp 0-day和2021年的 iMessage 0-day。

除了信息传递应用程序之外，我们也希望看看其他平台是否会成为0-day漏洞的目标，但公开示例却根本没有或者少得可怜。例如，自2014年年中以来，macOS 和 Linux各检测出一个野外0-day漏洞。 目前还没有已知的针对云端、CPU漏洞或其他手机组件（如WiFi芯片或基带）的野外0-day漏洞。

这就引发我们的思考：这些0-day漏洞案列的缺失是由于缺乏检测还是缺乏披露造成的？还是两者兼而有之？

有些供应商未公开过0-day漏洞，是因为他们从未发现，还是因为他们不公开披露? 

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

我们看到相同的错误模式是因为我们知道如何检测？

正如我们在本报告前面部分所述，我们在2021年检测到的所有0-day漏洞都与先前的漏洞有相似之处。这让我们想知道这是否真的代表了攻击者正在使用的东西。攻击者是否真的只是使用先前公开的漏洞和组件中的漏洞就取得成功？ 还是说我们检测所有这些带有已知错误模式的0-day漏洞是因为我们知道如何检测？ 公共安全研究给出了答案，是的，攻击者在大多数情况下仍然能够成功利用已知组件与漏洞类型中的漏洞。但我们仍然希望看到一些新奇的、意想不到的漏洞。我们早在2019年的年度回顾中就提出了这个问题，现在这个问题仍然存在。

dspl0itz 在哪里？

要成功利用漏洞，有两个关键组成部分：利用什么漏洞和漏洞的利用方法（如何将该漏洞转化为有用的东西）。

不幸的是，这份报告只能真正分析其中一个组成部分：什么漏洞。58个0-day漏洞中，只有 5个公开了漏洞的利用示例。在野外发现的0-day漏洞是攻击者的失败案例，也是防御者了解攻击者正在做什么并使其攻击更难、更耗时、更昂贵的关键机会。然而，如果没有利用样本或基于样本的详细技术文章，我们只能专注于修复漏洞而不是削弱利用的方法。这就意味着攻击者能够继续使用他们现有的利用方法，而不必回到设计和开发阶段来构建新的利用方法。虽然不得不承认共享漏洞利用样本非常具有挑战性（我们也正面临这样的挑战！），但我们仍然希望在 2022 年能够更多地共享漏洞利用样本或详细的技术文章，以便我们能够团结起来，利用每一条可能的信息，防止让攻击者更难毒害更多用户。

顺便说一句，如果您有意愿与我们分享漏洞利用示例，请与我们联系。无论是仅与我们分享，让我们撰写详细的技术描述和分析，还是让我们去公开地分享，我们都很乐意与您合作。

总结

回顾2021年， 我们可以看到，在 0-day 漏洞的检测和披露方面，行业取得了明显的行业进步，但显然针对0-day漏洞，行业还有很大的进步空间。作为一个产业，我们还并没有实现“增加0-day攻击的难度”的目标。攻击者仅利用普遍技术就成功实施了攻击。我们的目标是每当我们检测到攻击者的一个漏洞利用时，就能迫使他们从头开始：他们必须发现一个全新的漏洞，必须投入时间学习和分析新的攻击面，必须开发一个全新的利用方法。

虽然这一切看起来颇有难度，但我们仍抱有乐观态度。2019年，我们讨论了0-day漏洞利用的巨大检测缺陷，2年后的今天检测和披露都增长了一倍多。因此，虽然还有很多工作要做，但这并不难解决。技术和安全行业可以采取一些具体步骤来使其取得更大的进步：

1. 将0-day漏洞的披露当做行业的公开标准之一。

2. 供应商和安全研究人员共享漏洞利用样本或漏洞利用技术的详细描述。

3. 继续共同努力减少内存损坏漏洞或使其无法利用。

到2021年，我们不断看到对用户和实体使用的0-day漏洞对现实世界造成的影响。 虽然地球上的大多数人不需要担心自己被0-day攻击的个人风险，但0-day攻击仍然影响着我们每一个人。 这些0-day漏洞往往会对社会产生巨大的影响，因此我们需要继续尽我们所能，让攻击者更难在这些攻击中取得成功。

2021年向我们展示了我们正走在正确的轨道上并取得进展，但要实现“增加0-day攻击的难度”这个目标，还有很多工作要做。