摘要

2022 年检测并披露了 41 个野外 0day，这是自2014 年中期开始跟踪以来记录的第二多，但低于 2021 年检测到的 69 个。尽管 40% 的下降似乎是一个明显的数字为提高安全性而切赢，现实情况更为复杂。2022 年我们的一些主要收获包括：

由于修补时间较长，N 天的功能类似于 Android 上的 0 天。在整个 Android 生态系统中，存在多种情况，用户在很长一段时间内无法获得补丁。攻击者不需要 0day 漏洞，而是能够使用充当 0day 的 n 天。

零点击漏洞利用和新的浏览器缓解措施可减少浏览器零日漏洞。许多攻击者已经转向零点击而不是一点击攻击。零点击通常针对浏览器以外的组件。此外，所有主要浏览器还实施了新的防御措施，使利用漏洞变得更加困难，并可能影响攻击者转向其他攻击面。

超过 40% 的 0day 漏洞是之前报告的漏洞的变体。2022 年起的 41 个野外 0day 中有 17 个是之前报告的漏洞的变体。这延续了我们之前在2020 年回顾报告和2022 年中期报告中讨论过的令人不快的趋势。超过 20% 是 2021 年和 2020 年之前的野外 0day 的变体。

Bug 冲突很高。2022 年，攻击者使用彼此相同漏洞的报告更加频繁，安全研究人员也报告了后来发现攻击者使用的漏洞。当发现并修复针对流行消费者平台的野外 0day 漏洞时，它也越来越有可能破坏其他攻击者的漏洞。

根据我们对 2022 年 0day 的分析，我们希望看到整个行业继续关注以下领域：

1. 更全面、更及时的修补，解决变种和 n 天被用作 0 天的问题。

2. 更多平台跟随浏览器的脚步，发布更广泛的缓解措施，以降低整类漏洞的可利用性。

3. 供应商和安全维护者之间的透明度和协作持续增长，以共享技术细节并共同检测跨多个产品的漏洞利用链。

从数字来看

在2022年检测和披露的41个漏洞中，没有一个发现占所有检测到的0day漏洞的很大比例。我们看到它们在全年中分布相对均匀：上半年 20 个，下半年 21 个。这两个数据点的结合表明检测更加频繁和定期。我们还发现，被认为在野外发现 0day 的组织数量仍然很高。自 2021 年以来，在检测到的 69 个 0day 漏洞中，有 20 个组织获得了认可。2022 年，在 41 个野外 0day 事件中，有 18 个组织受到表彰。致力于 0day 检测的组织数量保持较高水平是有希望的，因为我们需要尽可能多的人来解决这个问题。

2022 年检测和披露了 41 个野外 0day，低于 2021 年的 69 个。虽然较 2021 年大幅下降，但 2022 年仍稳居第二。我们用于分析的所有 0day 都在此电子表格中进行跟踪。

 

作为安全指标的 0day 数量限制

在野检测到和披露的 0day 数量并不能告诉我们太多有关安全状况的信息。相反，我们将其用作许多指标之一。到 2022 年，我们认为，安全改进和回归的结合导致 2021 年至 2022 年检测到和披露的 0-day 数量下降了约 40%，并且 2022 年我们看到的 0-day 数量持续高于平均水平。

积极和消极的变化都会影响在野 0day 数量的上升和下降。因此，我们不能单独使用这个数字来表明我们在保护用户安全的斗争中是否取得了进展。相反，我们使用该数字来分析哪些因素可能促成了这一结果，然后审查这些因素是否是成功的领域或需要解决的地方。

导致检测和披露的在野 0day 数量增加的示例因素：

 

导致检测和披露的在野 0day 数量下降的因素示例：

 

对可能导致该数字上升和下降的不同因素进行头脑风暴，使我们能够了解数字背后发生的情况并从中得出结论。导致 2022 年自然 0day 数量高于平均水平的两个关键因素是：供应商透明度和变种。供应商在检测和透明度方面的持续工作是一个明显的胜利，但能够在野外使用的 0day 变体的比例很高，这并不是很好。我们在“似曾相识的似曾相识”部分更深入地讨论这些变体。

同样，我们评估了一些关键因素可能导致 2021 年至 2022 年自然 0day 数量下降，积极因素包括可利用的错误减少，导致许多攻击者使用与彼此之间存在差异，并且负面影响不像复杂的攻击方法一样有效，与 0day 漏洞一样，但检测 0day 的速度较慢。仅靠野外 0day 的数量并不能告诉我们太多关于野外利用的状况，而是影响这个数字的各种因素才是真正的教训所在。我们将在以下几节中深入探讨这些内容。

Android 上需要 0day 吗？

2022年，在整个Android生态系统中，我们看到了一系列上游厂商针对该问题发布了补丁，但下游厂商没有接受补丁并发布修复程序供用户应用的案例。零号项目于 2022 年 11 月在其“注意差距”博客文章中介绍了其中一个案例。

上游供应商和下游制造商之间的这些差距使得 n 天（众所周知的漏洞）充当 0 天，因为用户没有现成的补丁，他们唯一的防御措施就是停止使用该设备。虽然这些差距存在于大多数上下游关系中，但它们在 Android 中更为普遍且持续时间更长。

对于攻击者来说，这是一个很好的案例。攻击者可以利用已知的 n 天漏洞，但将其作为 0 天漏洞运行，因为它适用于所有受影响的设备。CVE-2022-38181 是 2022 年 Android 上发生这种情况的一个例子，它是 ARM Mali GPU 中的一个漏洞。该漏洞最初由 Github 安全实验室的安全研究员 Man Yue Mo 于 2022 年 7 月向 Android 安全团队报告。Android 安全团队随后决定，他们认为该问题“无法修复”，因为它是“特定于设备的”。不过，Android 安全部门将此问题提交给 ARM。2022年10月，ARM发布了修复该漏洞的新驱动程序版本。2022 年 11 月，TAG 发现了该漏洞正在野外使用。虽然 ARM 已于 2022 年 10 月发布了修复的驱动程序版本，但该漏洞直到 2023 年4 月才被 Android 修复，即 ARM 首次发布后 6 个月、Man Yue Mo 首次报告后 9 个月、首次报告后 5 个月发现在野外被积极利用。

• 2022 年 7 月：向 Android 安全团队报告

• 2022 年 8 月：Android 安全标记为“无法修复”并发送给 ARM

• 2022 年 10 月：ARM 修复了错误

• 2022 年 11 月：发现野外漏洞

• 2023 年 4 月：包含在 Android 安全公告中

2022年12月，TAG发现了另一个漏洞利用链针对最新版本的三星互联网浏览器。当时，最新版本的三星互联网浏览器运行在 Chromium 102 上，该版本是在 7 个月前的 2022 年 5 月发布的。作为该链的一部分，攻击者能够利用两个 n-day 漏洞，这些漏洞能够作为 0day 运行：CVE-2022-3038（已于 2022 年 6 月在 Chrome 105 中修补）和 ARM Mali GPU 内核驱动程序中的 CVE-2022-22706。ARM 于 2022 年 1 月发布了 CVE-2022-22706 补丁，尽管它已被标记为野外利用，但攻击者仍然能够在 11 个月后将其用作 0day。尽管该漏洞在 2022 年 1 月就已被广泛利用，但直到 2023 年 6 月才包含在 Android 安全公告中，

这些充当 0 天的 n 天属于是否作为 0 天进行跟踪的灰色区域。过去，我们有时将它们算作 0day：CVE-2019-2215和CVE-2021-1048。在这两个漏洞的情况下，错误已在上游 Linux 内核中修复，但没有按照 Linux 标准分配 CVE。我们将它们包括在内，是因为在它们被广泛发现之前，它们尚未被确定为需要在Android 中修补的安全问题。而在 CVE-2022-38181 的情况下，该错误最初报告给 Android，ARM 发布了针对该问题的安全公告，表明下游用户需要应用这些补丁。我们将继续尝试破译这个错误的“灰色区域”，但欢迎就如何跟踪它们提供意见。

2021 年浏览器如此

与总体数字类似，从 2021 年到 2022 年，检测到的针对浏览器的野外 0day 数量下降了 42%，从 26 个下降到 15 个。我们评估这反映了浏览器为加大攻击难度而做出的努力总体而言，攻击者行为从浏览器转向针对设备上其他组件的零点击攻击。

 

 

顶级浏览器防御的进步可能会影响将其他组件作为漏洞利用链中的初始向量的推送。整个 2022 年，我们看到更多的浏览器启动并改进了针对漏洞利用的额外防御措施。对于 Chrome 来说，这是MiraclePtr、v8 Sandbox和libc++ 强化。Safari 推出了锁定模式，Firefox 推出了更细粒度的沙箱。攻击性安全供应商 Dataflow Security 的漏洞研究员和漏洞开发人员 Ki Chan Ahn 在 2023 年 4 月的 Zer0Con 主题演讲中评论了这些类型的缓解措施如何使浏览器漏洞利用变得更加困难，并促使人们转向其他攻击面。

 

浏览器变得越来越难以利用，并且过去几年中漏洞利用交付的不断发展，这解释了 2022 年浏览器错误数量的下降。在 2019 年和 2020 年，检测到的野外 0day 中有相当一部分是通过水坑攻击。水坑攻击是指攻击者以他们认为会访问某个网站的群体为目标。任何访问该站点的人都会被利用并传递最终的有效负载（通常是间谍软件）。2021 年，我们普遍看到一键链接成为初始攻击向量。水坑攻击和一键链接都使用浏览器作为设备上的初始向量。2022 年，更多攻击者开始转而使用 0 点击漏洞利用，即无需用户交互即可触发的漏洞利用。零点击往往针对浏览器以外的设备组件。

 

2021 年底，Citizen Lab 捕获了一个针对 iMessage 的 0 点击漏洞（CVE-2023-30860），NSO 在其 Pegasus 间谍软件中使用了该漏洞。零号项目在这个由两部分组成的博客文章系列中详细介绍了该漏洞。虽然 2022 年没有公开检测和披露任何野外 0 点击，但这并不意味着缺乏使用。我们知道多个攻击者已经并且正在使用 0-click 漏洞利用链。

零点击很难检测，因为：

• 他们的寿命很短

• 通常没有明显的迹象表明他们的存在

• 可以针对许多不同的组件，供应商甚至并不总是意识到所有可远程访问的组件

• 直接传递到目标，而不是像水坑攻击那样广泛可用

• 通常不托管在可导航的网站或服务器上

 

对于一键式漏洞利用，目标必须单击一个可见的链接才能提供漏洞利用。这意味着目标或安全工具可能会检测到该链接。然后，利用该链接将漏洞托管在可导航服务器上。

另一方面，零点击通常针对处理传入呼叫或消息的代码，这意味着它们通常可以在显示传入消息或呼叫的指示器之前运行。这也极大地缩短了它们的寿命以及可以“活”地检测到它们的窗口。攻击者很可能会继续转向零点击漏洞利用，因此我们作为防御者需要关注如何检测和保护用户免受这些漏洞利用。

似曾相识：完整修补仍然是最大的机会之一

2022 年在野外发现的 41 个 0day 中有 17 个是之前公开的漏洞的变体。我们首次在2020 年回顾报告“Deja vu-lnerability”中发表了相关内容，指出 2020 年以来的野外 0day 中有 25% 是之前公开的错误的变体。该数字持续上升，可能是由于：

• 防御者越来越擅长识别变体，

• 防御者在检测野外 0day 变体方面有所改进，

• 攻击者正在利用更多变体，或者

• 漏洞修复不够全面，因此存在更多变体。

答案可能是上述所有内容的组合，但我们知道，能够被用户利用的 0day 变体数量并没有减少。减少可利用变体的数量是技术和安全行业最大的机会领域之一，迫使攻击者必须更加努力地利用 0day 漏洞。

不仅超过 40% 的 2020 年野外 0day 变体，而且超过 20% 的错误都是之前野外 0day 的变体：2021 年有 7 个，2020 年有 1 个。 0day 是在野外捕获的，这是一份礼物。攻击者不希望我们知道他们有哪些漏洞以及他们正在使用的漏洞利用技术。防御者需要尽可能多地利用这一礼物，并尽可能让攻击者难以再次利用 0day 漏洞。这涉及：

• 分析错误以找到真正的根本原因，而不仅仅是攻击者在这种情况下选择利用它的方式

• 寻找可能存在相同错误的其他位置

• 评估可用于利用该错误的任何其他路径

• 将补丁与真正的根本原因进行比较并确定是否有任何解决方法

只有当补丁既正确又全面时，我们才认为它是完整的。正确的补丁是指能够完全准确地修复错误的补丁，这意味着该补丁不再允许利用该漏洞。一个全面的补丁适用于修复需要应用的所有地方，涵盖所有变体。当利用单个漏洞或错误时，通常有多种方式触发该漏洞，或者访问该漏洞的多种路径。很多时候，我们看到供应商只阻止概念验证或漏洞利用示例中显示的路径，而不是从整体上修复漏洞。同样，安全研究人员经常报告错误，但没有跟进补丁的工作原理并探索相关攻击。

虽然不完整的补丁让攻击者更容易利用 0day 的想法可能会让人感到不舒服，但这个结论的反面却可以给我们带来希望。我们有一条明确的道路来让 0day 变得更加困难。如果更多的漏洞得到正确、全面的修补，攻击者将更难利用 0day。

我们已在下表中列出了所有已识别的漏洞变体。要更全面地了解 in-the-wild 0-day 是如何变体的，请查看 FIRST 会议的演示文稿 [视频、幻灯片]、 Zer0Con 的幻灯片、OffectiveCon 的演示文稿 [视频、幻灯片] CVE-2022-41073，以及有关 CVE-2022-22620 的这篇博客文章。

漏洞利用没有版权

与世界上许多商品不同，0day 本身并不是有限的。仅仅因为一个人发现了 0day 漏洞的存在并将其开发为一种漏洞利用程序，并不能阻止其他人也独立地发现它并在他们的漏洞利用程序中使用它。大多数自己进行漏洞研究和利用开发的攻击者不希望其他人做同样的事情，因为这会降低其价值并使其更有可能被快速检测和修复。

在过去的几年中，我们已经意识到存在大量错误冲突的趋势，其中不止一名研究人员发现了相同的漏洞。这种情况发生在向供应商报告错误的攻击者和安全研究人员之间。虽然错误冲突总是发生，而且我们无法测量它们发生的确切速率，但在安全通报中独立认定为同一漏洞的不同实体的数量，在两个不同的漏洞中发现相同的 0day，以及即使是与两边的研究人员进行的交谈也表明这种情况正在更频繁地发生。

错误冲突次数增多对于防御来说是一种胜利，因为这意味着攻击者总体上使用的 0day 更少。限制攻击面并减少可利用的错误类别肯定有助于研究人员发现相同的错误，但更多的安全研究人员发布他们的研究也可能有所贡献。人们阅读相同的研究，它激发了他们下一个项目的想法，但它在许多人中激发了类似的想法。平台和攻击面也变得越来越复杂，因此需要投入大量时间来建立新组件或目标的专业知识。

安全研究人员及其漏洞报告正在帮助修复攻击者正在使用的相同 0day，即使这些特定的 0day 尚未在野外检测到，从而破坏攻击者的漏洞。我们希望供应商继续支持研究人员并投资于他们的错误赏金计划，因为它有助于修复可能针对用户的相同漏洞。它还强调了为什么安全研究人员彻底修补已知的自然错误和漏洞都很重要。

现在怎么办？

回顾 2022 年，我们的总体结论是，作为一个行业，我们走在正确的道路上，但也存在很多机会领域，其中最大的领域是行业对报告的漏洞的响应。

• 我们必须快速为用户提供修复和缓解措施，以便他们能够保护自己。
• 我们必须进行详细分析，以确保解决漏洞的根本原因。
• 我们必须分享尽可能多的技术细节。
• 我们必须利用报告的漏洞来尽可能多地学习和修复。

这一切都不容易，对于在这个领域工作的安全团队来说，这也不足为奇。它需要投资、确定优先级并开发一个修补流程，以在快速保护用户和确保其全面性之间取得平衡，而这有时会很紧张。所需的投资取决于每种独特的情况，但我们看到了一些围绕人员/资源、激励结构、流程成熟度、自动化/测试、发布节奏和合作伙伴关系的共同主题。

我们在这篇文章中详细介绍了一些有助于确保错误得到正确、全面修复的努力：包括根本原因、补丁、变体和漏洞利用技术分析。我们将继续帮助进行这些分析，但我们希望并鼓励平台安全团队和其他独立安全研究人员也投资于这些工作。

最后的想法：TAG 的新漏洞利用团队

展望 2023 年下半年，我们对即将发生的事情感到兴奋。您可能会注意到，我们之前的报告已发布在“零计划”博客上。我们的 0day 野外计划已从零计划转向 TAG，以便将漏洞分析、检测和威胁行为者跟踪专业知识整合到一个团队中，受益于更多资源并最终实现：TAG 漏洞！未来还会有更多内容，但我们对这对于保护用户免受 0day 攻击并让 0day 变得困难意味着什么感到非常兴奋。

来源: https://security.googleblog.com/2023/07/the-ups-and-downs-of-0-days-year-in.html