2022年野外0day漏洞利用…截至目前

发布者：Maddie Stone，Google Project Zero

这篇博文概述了我在2022年6月FIRST会议上发表的演讲《2022年野外0day漏洞利用现状……截至目前》。幻灯片可在此处获取。

过去三年，我们每年都会发布关于在野外发现并利用的0day漏洞的年度回顾报告。最近的一份报告是《2021年度回顾报告》，我们于几个月前的2022年4月刚刚发布。虽然我们计划保持这种年度报告的节奏，但今天我们发布一份额外的报告，审视2022年上半年检测到并披露的野外0day漏洞。

截至2022年6月15日，2022年已检测并披露了18个在野外被利用的0day漏洞。分析这些0day漏洞后，我们发现其中至少有9个是先前已修补漏洞的变种。在2022年前六个月看到的0day漏洞中，至少有一半本可以通过更全面的补丁和回归测试来预防。此外，2022年的0day漏洞中有四个是2021年野外0day漏洞的变种。在原版野外0day漏洞被修补仅仅12个月后，攻击者就带着原漏洞的变种卷土重来。

那么，这意味着什么？

当人们想到0day漏洞利用时，通常会认为这些利用技术非常先进，以至于无法捕获和预防。数据描绘了另一番景象。今年迄今为止我们看到的0day漏洞中，至少有一半与我们之前见过的漏洞密切相关。我们在《2020年度回顾报告》中的结论和发现也非常相似。

2022年许多野外0day漏洞的出现，是由于之前的漏洞没有得到完全修补。在Windows win32k和Chromium属性访问拦截器漏洞的案例中，概念验证利用所采用的执行流程被修补了，但根本原因问题并未解决：攻击者能够卷土重来，通过不同的路径触发原始漏洞。而在WebKit和Windows PetitPotam问题的案例中，原始漏洞先前已被修补，但在某个时间点出现了回归，使得攻击者能够再次利用相同的漏洞。在iOS IOMobileFrameBuffer漏洞中，通过检查某个大小是否小于特定数值来应对缓冲区溢出，但没有检查该大小的最小边界。关于其中三个0day漏洞及其与变种关系的更详细解释，请参阅演讲幻灯片。

当0day漏洞利用在野外被检测到时，这对攻击者来说是失败的情况。对我们安全防御者来说，这是一份礼物，让我们能够尽可能多地学习，并采取行动确保该攻击向量无法再次被使用。我们的目标是，每次检测到攻击者的一个利用时，迫使他们从头开始：他们被迫去发现一个全新的漏洞，必须投入时间学习和分析新的攻击面，必须开发全新的利用方法。为了有效地做到这一点，我们需要正确和全面的修复。

这并不是要低估负责响应漏洞报告的安全团队所面临的挑战。正如我们在2020年度回顾报告中所说：

能够正确和全面地打补丁不仅仅是拨动一个开关：它需要投入、优先级排序和规划。还需要开发一个平衡快速保护用户和确保全面性的补丁流程，这两者有时可能存在矛盾。虽然我们预计这对组织内的安全团队来说并不意外，但这项分析是一个很好的提醒，表明仍有更多工作要做。

具体需要哪些投入取决于每个独特的情况，但我们看到一些围绕人员/资源、激励结构、流程成熟度、自动化/测试、发布节奏和合作伙伴关系的共同主题。

实际上，以下一些努力可以帮助确保漏洞得到正确和全面的修复。Project Zero计划继续帮助开展以下工作，但我们希望并鼓励平台安全团队和其他独立安全研究人员也投资于这类分析：

• 根本原因分析
  理解正在被利用的底层漏洞。同时尝试理解该漏洞可能是如何被引入的。执行根本原因分析有助于确保修复措施针对的是底层漏洞，而不仅仅是破坏概念验证。根本原因分析通常是成功进行变种分析和补丁分析的前提。

• 变种分析
  寻找与已报告漏洞类似的其他漏洞。这可能涉及在其他地方寻找相同的错误模式、更彻底地审计包含漏洞的组件、修改模糊测试器以理解它们为何之前没有发现该漏洞等。大多数研究人员会同时发现多个漏洞。通过发现和修复相关的变种，攻击者就无法在原漏洞被修补后简单地“即插即用”新漏洞。

• 补丁分析
  分析提议（或已发布）的补丁相对于根本原因漏洞的完整性。我鼓励供应商尽早与漏洞报告者分享他们计划如何解决该漏洞，以便报告者能够分析补丁是否全面解决了漏洞的根本原因，同时供应商也应进行自己的内部分析。

• 利用技术分析
  理解从漏洞中获得的能力原语以及它是如何被使用的。虽然修补漏洞通常是行业标准，但缓解利用技术并不那么频繁。虽然并非每种利用技术都能被缓解，但希望这能成为默认做法而非例外。为了供应商和安全研究人员能够进行利用技术分析，需要更便捷地共享利用样本。

透明地分享这些分析也有助于整个行业。我们在此代码库发布我们的分析。我们也鼓励供应商和其他人发布他们的分析。这使开发人员和安全专业人员能够更好地了解攻击者已经对这些漏洞掌握了什么，希望这能带来更好的整体解决方案和安全性。