听，58个在野0day，在说什么？
编译：代码卫士
谷歌 Project Zero 团队回顾了2021年已遭在野利用的58个0day，发布继2019年和2020年以来的第三份年度报告，窥见未来趋势、总结经验教训。本文是对该文章的编译。
我们分析58个已遭利用0day并分享结果是为了让0day难以遁形，让0day的成本更高昂、对资源要求更高，从而使攻击者更难以利用0day能力。
2021年检测并披露了58个在野0day，这是自Project Zero 团队从2014年年中追踪以来，数量最多的一次：2015年为28个，2020年仅为25个。虽然本文讨论的是已遭在野使用的0day exploit，但实际讨论的是所检测和披露的在野 0day exploit。
因此分析得出的第一个结论是，2021年在野0day 达到高峰的原因是对这些0day的检测和披露活动增多，而非仅仅是因为对0day exploit 的使用增加。另外分析发现，相比以往，攻击者的方法论在本质上并无区别。攻击者使用同样的漏洞模式和利用技术，并查找同样的攻击面。让0day更难以遁形的方法是让攻击者无法使用公开的方法和技术开发0day exploit。然而，在这58个在野0day 中，仅有2个0day 是新型0day：一个因exploit 的复杂度，一个因使用逻辑bug 逃逸沙箱脱颖而出。
遗憾的是，由于攻击者不会公开或分享自己所使用的的0day 信息，因此我们无法获悉当前找到并公开披露的 0day 比例。
基于所获得的数据，我们希望2022年可采取如下措施，让0day难以遁形：
1、所有厂商同意在安全通告中披露漏洞的在野利用状态；
2、更广泛地分享 exploit 样本或exploit的技术说明；
3、继续集中力量减少内存损坏漏洞或使其不可被利用。推出缓解措施，大大降低内存损坏漏洞的可利用性。
后面将从两方面说明2021年创纪录的58个0day分析：一是对在野0day exploit 的检测增多；二是对在野0day利用的公开披露增多。
Project Zero 团队指出，粗略统计，被致谢发现在野0day 的实体数量在增加。如果尝试寻找 0day exploit 的人数在增多，那么所检测到的在野 0day exploit 的数量就可能增长。
另外在自家产品中检测在野 0day 的厂商数量也在增多。厂商似乎在2021年找到了更加成功的检测方法。比如谷歌在自家产品中发现了7个在野0day，而谷歌发现了10个。
检测到的在野0day 漏洞数量增多的另外一个原因是漏洞获得更多披露。自苹果和谷歌安卓率先分别在2020年11月和2021年1月披露潜在的在野exploit 后，更多厂加入如微软、谷歌 Chrome、Adobe等。由于有些漏洞是“匿名”研究员发现并报告的，因此如厂商不披露，则有些漏洞可能永远不会被公众知道。
不过，一些厂商很有可能在2021年未在发布说明中提到已遭在野利用0day。2022年希望更多厂商可以说明遭在野利用的漏洞情况。
0day exploit 是攻击者可使用的最高阶攻击方法，因此人们很容易认为攻击者肯定使用了特殊的技术和攻击面。然而分析后发现，2021年的0day 一般遵循和以往同样的漏洞模式、攻击面和 exploit “形状”。只有上述提到的两个0day是例外。
在所分析的58个在野0day 中，39个（67%）是内存损坏漏洞。内存损坏漏洞已成为过去几十年以来的软件攻击标准，而且攻击者仍然借此获得成功。在这些内存漏洞中，多数是非常热门和为人熟知的漏洞类型：
17个释放后使用
6个界外读和写
6个缓冲区溢出
4个整数溢出
Chromium (Chrome)
2021年，检测和披露的Chromium 0day共14个：
6 个JavaScript 引擎0day - v8 （CVE-2021-21148、CVE-2021-30551、CVE-2021-30563、CVE-2021-30632、CVE-2021-37975、CVE-2021-38003）
2个 DOM 引擎0day - Blink （CVE-2021-21193 和 CVE-2021-21206）
1 个WebGL 0day (CVE-2021-30554)
1 个IndexedDB 0day (CVE-2021-30633)
1 个webaudio 0day (CVE-2021-21166)
1 个Portals 0day (CVE-2021-37973)
1 个Android Intents 0day (CVE-2021-38000)
1 个Core 0day (CVE-2021-37976)
这些组件都是以往常见的攻击面，如果说有什么不同的话，那就是 DOM 漏洞更少，其它浏览器组件漏洞更多。在这14个0day 中，13个是内存损坏漏洞，且大部分是释放后使用漏洞。其中，CVE-2021-21166和CVE-2019-13720类似，CVE-2021-30632和CVE-22020-16009类似。
WebKit (Safari)
2021年以前，苹果仅承认了1个公开的针对 WebKit/Safari 的已知在野0day，而且是由外部研究员分享的；2021年这一数字为7个：
4 个Javascript 引擎0day - JavaScript Core（CVE-2021-1870、CVE-2021-1871、CVE-2021-30663、CVE-2021-30665）
1 个IndexedDB 0day (CVE-2021-30858)
1 个Storage 0day (CVE-2021-30661)
1 个Plugins 0day (CVE-2021-1879)
让人有点惊奇的是，没有检测和披露的DOM漏洞，此前DOM引擎中的漏洞占据在野浏览器0day 的15%到20%，但2021年 WebKit 中并未检测和披露此类漏洞。可能攻击者开始转向其它模块如第三方库或 IndexedDB，这些模块可能对于攻击者来说前景更好，因为这类漏洞可能存在于多个浏览器或平台中。
IE
IE 浏览器中的在野0day数量稳定。虽然IE浏览器的市场份额在下降，但2021年检测和披露的0day数量和2016年持平。
为什么会出现这种情况？尽管用户减少，但IE 仍然是攻击者初次进入Windows 设备的成熟攻击面。虽然数量持平，但攻击的组件和exploit 的交付方法有所变化。2021年，4个0day中的3个攻击的是MSHTML浏览器引擎并通过web以外的方法交付，而是通过Office 文档或其它文件格式交付。这4个0day 针对的是如下组件：
MSHTML 浏览器引擎 (CVE-2021-26411、CVE-2021-33742、CVE-2021-40444)
Javascript Engine - JScript9 (CVE-2021-34448)
Windows
相比以往年份，Windows 组件0day是变化最多的。不过这一情况已存在数年时间，随着Windows 7 在2020年的寿终正寝，这一情况也在预料之中。2021年，共有10个Windows 0day 针对7个不同组件：
2 个Enhanced 加密提供商0day (CVE-2021-31199, CVE-2021-31201)
2 个NTOS 内核0day (CVE-2021-33771, CVE-2021-31979)
2 个Win32k 0day (CVE-2021-1732, CVE-2021-40449)
1 个Windows update medic 0day (CVE-2021-36948)
1 个SuperFetch 0day (CVE-2021-31955)
1个dwmcore.dll 0day (CVE-2021-28310)
1 ntfs.sys (CVE-2021-31956)
0day 位于不同组件中的原因是，在2019年8个Win32k 0day中的6个当时并未针对最新Windows 10版本，而是针对更老旧版本。随着微软投入更多资源锁定 Win32k 的攻击面，Win32k 成为越来越没有吸引力的攻击面。
iOS/macOS和让人“哇塞”的两个0day
如“更多披露”一节提到的，2021年，苹果公司首次在发布说明中提到在野0day 情况。2021年共有5个iOS 在野0day，其中包含首个公开已知的 macOS 在野0day (CVE-2021-30869)。将二者放在一起讨论的原因有二，一是二者包含相似组件，二是macOS 的样本量较少，只有一个。
这5个在野0day和针对的3个攻击面是：
IOMobileFrameBuffer （CVE-2021-30807、CVE-2021-30883）
XNU Kernel (CVE-2021-1782 & CVE-2021-30869)
CoreGraphics (CVE-2021-30860)
CommCenter (FORCEDENTRY 沙箱逃逸 – CVE编号尚未分配)
这4个攻击面并不新鲜。其中两个FORCEDENTRY exploit（CVE-2021-30860和沙箱逃逸漏洞）是唯一让我们“哇塞”的。对于CVE-2021-30860（位于CoreGraphics 中的整数溢出）是因为：
多年来，我们都听说过攻击者如何利用零点击 iMessage 漏洞，我们终于见到了公开案例，以及
该exploit 是一个令人印象深刻的创造艺术。
而沙箱逃逸漏洞（CVE编号仍在申请中）惹人注意的原因在于，这是我们见过的为数不多的仅使用逻辑漏洞而非标准内存损坏漏洞的在野沙箱逃逸案例。
对于CVE-2021-30860而言，该漏洞本身并不是特别引人注目，它是位于 CoreGraphics PDF 解码器 JBIG2 解析器中的一个常见整数溢出漏洞。然而，它的exploit 被Samuel Groß 和 Ian Beer 描述为“所见过的技术最复杂的exploit 之一”。值得注意的是，该exploit 使用了 JBIG2 中的逻辑运算符来构建 NAND gates，而后者用于构建自己计算机架构的。该exploit之后使用新的自定义架构写exploit 其余的部分。
这就是让0day利用难以实施的样子：攻击者必须开发出一种新方法来利用漏洞，而这种方法要求大量专业只是和/或时间来开发。今年，这两个FORCEDENTRY exploit 是唯一让我们眼前一亮的0day。希望未来会出现更多提高成功利用门槛的情况。
安卓
2021年检测和披露的在野0day有7个。此前仅在2019年出现过1个，即CVE-2021-2215。这7个0day 和相关组件是：
高通 Adreno GPU 驱动（CVE-2020-11261、CVE-2021-1905、CVE-2021-1906）
ARM Mali GPU 驱动（CVE-2021-28663、CVE-2021-28664）
上游Linux 内核（CVE-2021-1048、CVE-2021-0920）
微软 Exchange 服务器
2021年，有5个微软 Exchange 在野0day。第一组有4个0day（CVE-2021-26855、CVE-2021-26857、CVE-2021-26858和 CVE-2021-27065），第二组有两个（CVE-2021-42321和CVE-2021-26858）。这两组0day用于不同攻击活动中。
虽然在2021年Exchange 服务器中出现5个之多的0day，但值得注意的是它们仅被一起用于两个不同攻击活动中。这就是为何我们不建议以产品中的0day数量作为衡量产品成功与否的条件。要求使用4个0day才能成功利用比只使用1个就获得访问权限更好。
虽然这是自追踪以来，首次检测和披露的Exchange 在野0day，但丝毫不令人惊讶。因为在2020年就出现nday 利用。不管2021年是否为攻击者开始使用0day 利用的第一年还是防御人员开始检测0day利用的第一年，这一变化并不奇怪，2022年大概率继续如此。
1、 0day 到哪里去了？
虽然在2021年找到了创纪录的58个在野0day，在关键目标缺失。例如，通讯类应用如 WhatsApp、Signal、Telegram 等是攻击者感兴趣的目标，但2021年仅有1个0day 和通讯类应用有关（iMessage）。自2014年年中开始追踪以来，共两个通讯应用0day：一个是2019年的 WhatsApp 0day，另外一个是2021年发现的 iMessage 0day。另外一个是平台类几乎没有或者很少检测披露出 0day。自追踪以来，macOS 和 Linux 平台上仅各自出现1个0day。不存在针对云、CPU或其它手机组件如 WiFi 芯片或基带的0day。为何会出现这种情况？是检测不够还是披露不够还是二者兼有？
2、 某些厂商是否知情不报？
除非厂商主动告知将公开披露平台中所有漏洞的利用状态，我们公众不得而知，不过好在目前有了一种清晰的解决方案：所有设备和软件厂商同意，在产品漏洞遭在野利用时，公开披露这些漏洞。
3、漏洞模式一样是受已知漏洞检测方法的限制吗？
公开的安全研究成果指出，大多数情况下，攻击者仍然可以利用已知组件和漏洞类型中的漏洞获得成功。不过我们仍然看到了一些新的不同寻常的漏洞。这一问题早在2019年就提出，目前仍然未解决。
4、Spl0itz 在哪里？
要成功利用漏洞，exploit的两个部分至关重要：被利用的漏洞以及利用方法（漏洞如何转变为武器）。
遗憾的是，本报告仅能分析其中的漏洞组件。在58个在野0day中，仅有5个0day 的exploit 样本是公开的。已发现的在野0day 是攻击者的失败案例，也是防御者了解攻击者如何利用并使其难以利用的重大机会。在不了解exploit 样本或缺少详细的技术write-up的情况下，我们只能关注如何修复漏洞而非缓解利用方法。这意味着攻击者能够继续使用现有的利用方法，而不必从头涉及和开发。虽然共享exploit 样本的挑战非常大（我们也面临这一挑战），但希望2022年大家能够分享更多的exploit样本或详细的write-up，以便将各种可能的信息利用价值最大化，让攻击者更难以利用0day。
回顾2021年，浮现在脑海的是“蹒跚学步”。我们看到在检测和披露0day exploit 方面，行业取得了清晰可见的进步，但仍然存在更大的进步空间。作为行业，我们并没有让0day难以遁形，攻击者正在利用我们之前所见过的漏洞和此前所讨论过的攻击面获得成功。我们的目标是，在我们每次检测到他们的exploit 后，让他们从头开始：强迫他们发现全新的漏洞，必须投入时间学习和分析新的攻击面，必须开发出全新的利用方法。虽然我们在检测和披露方面取得重大进步，但仍然存在可以提升的方面。
虽然看似暗淡，但光明的一面是我们曾有过类似经验。相比以往，我们检测和披露了更多的在野0day exploit，技术和安全行业可采取如下具体措施，取得更多进展：
让所有厂商在发现产品漏洞遭利用的证据时予以公开披露成为行业标准。
厂商和安全研究员共享 exploit 样本或exploit技术详情。
继续协同减少内存损坏漏洞或使其不可利用。
2021年说明我们走在了正确的道路上并取得了进步，但要让0day难以遁形，我们还需要做得更多。
谷歌：早在这个0day 补丁发布前几周，朝鲜国家黑客就已利用
https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html
题图：Pixabay License
文内图：谷歌
本文由奇安信编译，不代表奇安信观点。转载请注明“转自奇安信代码卫士 https://codesafe.qianxin.com”。
奇安信代码卫士 (codesafe)
国内首个专注于软件开发安全的产品线。