谷歌分析2022在野0day利用后，得出令人意外的结论
编译：代码卫士
截止到2022年6月15日，我们已经检测并披露了18个在野利用0day。分析这些0day 时，我们发现至少有9个是之前已修复的漏洞。在2022年上半年已遭利用的0day中，至少有一半本可通过更全面的打补丁和回归测试得以阻止。另外4个0day 是2021年在野0day的变体。距离原始在野0day被修复12个月之后，攻击者又带着原始0day的变体卷土重来。
产品 | 2022 在野0-day | 变体 |
Windows win32k | CVE-2022-21882 | CVE-2021-1732 （2021 在野） |
iOS IOMobileFrameBuffer | CVE-2022-22587 | CVE-2021-30983（2021 在野） |
Windows | CVE-2022-30190 (“Follina”) | CVE-2021-40444 （2021 在野） |
Chromium 属性访问拦截器 | CVE-2022-1096 | CVE-2016-5128 CVE-2021-30551 （2021 在野) CVE-2022-1232 (解决不完整的CVE-2022-1096修复方案） |
Chromium v8 | CVE-2022-1364 | CVE-2021-21195 |
WebKit | CVE-2022-22620 (“Zombie”) | 最初在2013年修复，后来在2016年退回 |
Google Pixel | CVE-2021-39793* * 虽然编号中提到是2021，但该漏洞是在2022年修复并披露的。 | 不同LInux子系统中的同样漏洞 |
Atlassian Confluence | CVE-2022-26134 | CVE-2021-26084 |
Windows | CVE-2022-26925 (“PetitPotam”) | CVE-2021-36942 （补丁回归） |
那么这意味着什么？
提到0day利用，人们通常认为这些利用在技术上非常高阶，根本没有希望捕获并阻止。但数据展示给我们的确实另一番景象。截至目前，今年至少有一半0day 和此前了解的漏洞密切相关。和在我们发布的2020年漏洞回顾报告中的结论和发现结果非常相似。
2022年很多的在野0day 是因为此前的漏洞未完全修复而造成的。比如 Windows win32k 和 Chromium 属性访问拦截漏洞，这些PoC 利用采取的执行流虽然打补丁了，但根因问题并未解决：攻击者还能通过不同的路径触发原始漏洞，卷土重来。再比如 WebKit 和 Windows PetitPotam 问题，虽然原始漏洞已被修复，但在某个点退回了，因此攻击者可再次利用同样的漏洞。在 iOS IOMobileFrameBuffer 漏洞案例中，虽然通过检查大小是否小于某个特定值的方式解决了一个缓冲区溢出漏洞，但并未检查该大小的最低界限。
检测到在野0day后，这是攻击者的失败案例，但却是我们防御人员的礼物，我们可以尽可能多地学习经验教训并采取措施，确保该向量无法再被使用。我们的目标是，每当我们检测到他们的exploit之时就是迫使攻击者从零开始之时：他们不得不发现全新漏洞，投入时间学习并分析新的攻击面，必须开发全新的利用方法。要实现这一效果，我们需要正确全面的修复方案。
这样做并非为了将负责响应漏洞报告的安全团队所面临的挑战最小化。正如我们在2020年的年度回顾报告中提到的那样，“正确并全面地打补丁并非仅仅是开关开关那样简单：它要求投资、优先排序和规划，还要求开发出的打补丁流程既能快速保护用户，又能确保补丁是完整全面的，有时候二者是无法平衡的。虽然我们知道组织机构中的安全团队对此并不惊讶，但本分析提醒我们仍然需要做更多的工作。虽然确切的投资可能取决于每个独特情境，但我们发现了人员/资源、激励结构、流程成熟度、自动化/测试、发布节奏和合作伙伴关系之间的共同主题。”
在实践方面，可采取如下措施确保所有漏洞得到正确、全面的修复。零日项目团队计划继续采取如下措施，但希望并提倡平台安全团队和其它独立安全研究员也能够投入此类分析工作中：
根因分析
了解正被利用的底层漏洞。同时尝试了解该漏洞是如何被引入的。执行根因分析有助于确保修复方案正在修复该底层漏洞而不仅仅是破解PoC。根因分析通常是变体和补丁分析取得成功的一个前提条件。
变体分析
查找和所报告漏洞类似的其它漏洞。这项工作涉及查看别处同样的漏洞模式、更加全面地审计包含该漏洞的组件、修改模糊测试工具以了解这些工具之前为何未发现该漏洞等。多数研究人员一次会发现一个以上的漏洞。通过查找并修复相关变体，攻击者就无法在修复原始漏洞的情况下，仅凭“即插即用”的方式利用新漏洞。
补丁分析
分析与根因漏洞相比，所提出的（或发布的）补丁的完整性。厂商应该提早和漏洞发现者分享修复漏洞的计划，以便在厂商自身的内部分析的同时，发现人员能够分析补丁能否解决漏洞根因。
利用技术分析
了解从漏洞中获取的原语以及遭利用的方式。虽然目前的行业标准是修复漏洞，但缓解利用技术并不常常发生。虽然并非每种利用技术都可得到缓解，但希望它将成为默认行为而非例外行为。应当及时分享利用样本，以便厂商和安全研究员能够执行利用技术分析。
以透明的方式共享这些分析也有助于提升整个行业水平。我们提倡厂商和其他人也公开自己的分析结果。这有助于开发人员和安全专业人员更好地了解攻击者已经知晓的漏洞情况，希望以此推动更好的解决方案和安全性。
谷歌的分析研究报告可见：https://googleprojectzero.github.io/0days-in-the-wild/rca.html。
谷歌研究员详述已存在5年、已遭利用、已修复的 Safari 0day
思科不打算修复VPN路由器 RCE 0day
热门工业访问控制系统中存在8个严重0day
DogWalk：Windows 新0day 获得非官方补丁
https://googleprojectzero.blogspot.com/2022/06/2022-0-day-in-wild-exploitationso-far.html
题图：Pixabay License
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。