谷歌发布2022年在野利用0day年度回顾报告
编译：代码卫士
2022年遭在野利用的0day漏洞共计 41个，是自2014年年中统计以来数量最多的第二个年份，虽然不敌2021年检测出的数量69个。虽然说数量比2021年减少了40%，似乎安全性得到明显提升，但实际情况要复杂得多。报告结论主要如下。
由于打补丁用时长，nday 漏洞被当做0day漏洞利用。安卓生态系统中存在很多长时间内补丁未推送给用户的案例。攻击者无需 0day 利用就能够用 nday 发挥出0day 的作用。
零点击利用和新的浏览器缓解措施促使浏览器 0day 漏洞数量下降。很多攻击者追求零点击而非一次点击利用。零点击通常针对的是组件而非浏览器。另外，所有主流浏览器还执行了新的防御措施，加大了漏洞的利用难度并可能促使攻击者转向其它攻击面。
超过40%的0day漏洞是之前所报告漏洞的变体。在这41个已遭利用 0day 中，17个事此前所报告漏洞的变体。这个趋势与2020年的年度回顾报告以及2022年年中回顾报告结论一致。超过20%的0day 是2020年和2021年在野利用0day的变体。
撞洞率仍然很高。2022年，不同攻击者使用同样漏洞的情况以及安全研究员报告同样漏洞的情况更加频繁。发现和修复攻击某热门消费者平台的在野 0day时，很有可能同时破坏了其它攻击者的利用。
报告提到，希望行业继续关注如下几方面：
1、更全面及时地修复0day变体和将nday用作0day的情况。
2、更多平台跟随浏览器的步伐，发布更多缓解措施，降低漏洞遭利用的数量。
3、 厂商和安全防御人员之间更加透明并加强协作，共享漏洞详情并共同检测漏洞利用情况。
报告提到，2022年在野利用0day的检测情况比较均匀，上半年发现20个，下半年发现21个。另外发现这些漏洞的组织机构共计18家，而在2021年，这一数字是20个。
报告指出，在野0day漏洞的数量无法衡量安全状况，只是多种安全指标之一，因此无法只通过这一数字来说明所取得的进步情况，只能借这些数据分析贡献因素并找到可能的成功或失败点。
图1：按年份检测到的在野0day数量
图2：按平台划分的在野利用0day数量
分析认为，2022年所发现已遭利用 0day 数量高于平均值的两个关键因素是厂商的透明度和漏洞变体。2022年较2021年所检测已遭利用 0day 数量有所下降的因素可能包括可利用漏洞情况减少，因此攻击者使用的漏洞趋于相同；也有可能是因为复杂的攻击方法所起到的效果和 0day 利用一样而导致0day检测速度放缓等。
安卓 Nday 发挥0day作用
2022年，安卓生态系统中出现一系列上游厂商发布补丁但下游制造商未应用补丁且未为用户发布修复方案的案例。
上游厂商和下游制造商之间的这种差距导致 nday 漏洞发挥 0day 漏洞的作用，没有可用补丁，导致用户的唯一防护措施就是停用设备。虽然多数上下游关系中存在这种差距，但在安卓生态系统中更为常见和持久。而这种情况给攻击者带来巨大的机会。0day 漏洞作用的 nday 漏洞是0day漏洞界定的灰色地带。之前有时也会将这种 nday 漏洞算作 0day，因为在在野发现之前，这些漏洞并未被列为需要修复的安全问题。目前对这类型漏洞的界定尚无定论。
和总体数据类似，所检测到的在野浏览器0day的数量也下降了42%，从26个下降到15个。报告认为这反映了浏览器部署防御措施，使漏洞更难以利用，也反映了攻击者从浏览器转向零点击，攻击设备其它组件的情况。
图3：按年份划分的浏览器在野利用0day
报告提到，在2022年的41个已遭在野利用 0day 中，17个是此前漏洞的变体，占比超过40%。2020年报告回顾中，这一比例是25%。这一比例持续提升的原因可能是防御人员发现漏洞变体的能力有所提升、攻击者利用更多的变体以及漏洞未得到全面彻底修复因此产生更多变体。虽然答案可能是这几种因素的结合，但可被用于0day的变体数量并未减少。因此，减少可利用变体的数量是技术和安全行业对抗攻击者的最大机会之一。
不止如此，超过20%的已遭利用0day是此前在野0day的变体：7个来自2021年，1个来自2020年。在野捕捉到的0day是一个礼物。攻击者不想让防御人员了解他们所拥有的漏洞以及所使用的利用技术，而防御人员也应将此视作机会，为此，应当：
分析漏洞找到根因，而非仅仅分析攻击者在案例中的利用方式；
查找其它位置是否可能存在同样的漏洞；
评估可被用作利用漏洞的其它路径；
比对补丁和根因，判断是否存在其它绕过方法。
报告提到，只有当补丁是正确全面时，才会被视作是完整的。正确的补丁应当是以完整的准确性修复漏洞，意味着补丁不允许漏洞以任何方式利用。全面的补丁意味着需要应用补丁的地方全部都应用，覆盖了所有的辩题。当利用单个漏洞时，通常会有多种触发该漏洞的方式或者有多种访问该漏洞的路径。而厂商通常只是拦截了PoC 或利用样本中的路径，并没有整体修复该漏洞。同样，安全研究人员通常也并未跟踪补丁的运作方式和探索相关攻击。
如下是2022年之前漏洞变体的在野0day。
产品 | 2022 在野利用(ITW) CVE | 变体 |
Windows win32k | CVE-2022-21882 | CVE-2021-1732 (2021 itw) |
iOS IOMobileFrameBuffer | CVE-2022-22587 | CVE-2021-30983 (2021 itw) |
WebKit “Zombie” | CVE-2022-22620 | 最初在2013年修复，补丁在2016年补丁回归。 |
Firefox WebGPU IPC | CVE-2022-26485 | 2021年修复fuzzing崩溃问题。 |
Android in ARM Mali GPU | CVE-2021-39793 CVE-2022-22706 | CVE-2021-28664 (2021 itw) |
Sophos Firewall | CVE-2022-1040 | CVE-2020-12271 (2020 itw) |
Chromium v8 | CVE-2022-1096 | CVE-2021-30551 (2021 itw) |
Chromium | CVE-2022-1364 | CVE-2021-21195 |
Windows “PetitPotam” | CVE-2022-26925 | CVE-2021-36942 – 补丁被回归 |
Windows “Follina” | CVE-2022-30190 | CVE-2021-40444 (2021 itw) |
Atlassian Confluence | CVE-2022-26134 | CVE-2021-26084 (2021 itw) |
Chromium Intents | CVE-2022-2856 | CVE-2021-38000 (2021 itw) |
Exchange SSRF “ProxyNotShell” | CVE-2022-41040 | CVE-2021-34473 “ProxyShell” |
Exchange RCE “ProxyNotShell” | CVE-2022-41082 | CVE-2023-21529 “ProxyShell” |
Internet Explorer JScript9 | CVE-2022-41128 | CVE-2021-34480 |
Windows “Print Spooler” | CVE-2022-41073 | CVE-2022-37987 |
WebKit JSC | CVE-2022-42856 | 因测试失败发现2016年的漏洞 |
报告认为，虽然行业整体的前进方向是正确的，但还有很多机会点，而最大的机会点就是行业对所报告漏洞的响应。
我们必须快速将修复方案和缓解措施发给用户，使他们保护自身安全。
我们必须详细分析漏洞，确保漏洞根因得到解决。
我们必须分享尽可能多的技术详情。
我们必须通过已报告漏洞尽可能多地从中学习和修复它们。
文章提到，做到上述任何一条建议都不容易，且任何一条建议对于安全团队而言都并不稀奇。这些建议要求投资、优先级排序以及开发出能够快速保护用户安全且确保全面的打补丁流程，有时候这样做会处于非常紧张的状态。投资取决于具体的情况，不过共同之处在于人员/资源、激励结构、流程成熟度、自动化/测试、发布节奏和伙伴关系。报告中详细的正确且全面的打补丁方向的努力包括根因、补丁、变体和利用技术分析。
https://security.googleblog.com/2023/07/the-ups-and-downs-of-0-days-year-in.html
题图：Pixabay License
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。