谷歌Project Zero報(bào)告披露2021年0-day漏洞利用全球趨勢(shì)
發(fā)布時(shí)間 2022-04-26“Project Zero”是一項(xiàng)由谷歌成立的互聯(lián)網(wǎng)安全項(xiàng)目，成立時(shí)間為2014年7月。該團(tuán)隊(duì)主要由谷歌內(nèi)部頂尖安全工程師組成，旨在發(fā)現(xiàn)、追蹤和修補(bǔ)全球性的軟件安全漏洞。自2019起，團(tuán)隊(duì)每年會(huì)對(duì)過(guò)去一年內(nèi)檢測(cè)到的0-day漏洞在野利用進(jìn)行回顧并發(fā)布報(bào)告。2021年內(nèi)，“Project Zero”共檢測(cè)并披露了58個(gè)在野外的0-day漏洞，這一數(shù)字創(chuàng)下了項(xiàng)目2014年成立以來(lái)的新紀(jì)錄。本篇報(bào)告中，“Project Zero”團(tuán)隊(duì)詳細(xì)向我們介紹了被檢測(cè)到的58個(gè)0-day漏洞的類型和攻擊模式，并分析了2021年0-day數(shù)據(jù)暴增的原因。另外，在報(bào)告中，我們也可以清晰地看到團(tuán)隊(duì)在2022年的工作方向。
以下是報(bào)告正文：
這是我們自2019年起連續(xù)第三年對(duì)0-day漏洞的在野利用進(jìn)行回顧。
每一年，我們都會(huì)回顧這一年內(nèi)在野外發(fā)現(xiàn)和披露的所有0-day漏洞，并對(duì)其進(jìn)行綜合考量。本報(bào)告的目的并不是對(duì)每個(gè)漏洞進(jìn)行分析，而是將一年來(lái)的漏洞作為一個(gè)整體進(jìn)行分析，尋找趨勢(shì)、差距、經(jīng)驗(yàn)教訓(xùn)和成功的防護(hù)案例。
我們撰寫(xiě)并分享這份報(bào)告是希望增加0-day漏洞利用的難度。我們希望0-day利用的成本不斷增加，當(dāng)披露和防護(hù)的資源更集中，攻擊者自然更難對(duì)其加以利用。
我們將在正文中展示完整的論證過(guò)程，然后在結(jié)論中總結(jié)我們對(duì)未來(lái)的展望與操作方法。如果你并不喜歡深入挖掘細(xì)節(jié)，那就看看執(zhí)行摘要和結(jié)論吧。
重點(diǎn)發(fā)現(xiàn)
2021年內(nèi)共檢測(cè)并披露了58個(gè)在野外的0-day漏洞，這是自2014年年中“Project Zero”項(xiàng)目開(kāi)始追蹤以來(lái)最多的。此前的最大值是2015年檢測(cè)到的28個(gè)，這次有足足兩倍之多，尤其是，2020年只檢測(cè)到25個(gè)。自2014年年中以來(lái)，我們一直在這個(gè)電子表格中追蹤已知的公開(kāi)的0-day漏洞。
雖然我們經(jīng)常討論0-day漏洞的在野利用數(shù)量，但我們實(shí)際上討論的是在野外檢測(cè)到和被披露的0-day漏洞的數(shù)量。這就引出了我們的第一個(gè)結(jié)論:我們認(rèn)為，2021年報(bào)告顯示0-day漏洞的大幅增加是由于對(duì)它們檢測(cè)和披露的渠道增多，而不是簡(jiǎn)單地只是0-day漏洞的在野利用增加。
從數(shù)據(jù)中我們可以看出，其實(shí)攻擊者的方法與前幾年相比并沒(méi)有太大的變化。攻擊者使用的是相同的漏洞模式和挖掘技術(shù)，并針對(duì)相同的攻擊面加以打擊。 “Project Zero”的使命是“增加0-day攻擊的難度”。
總體而言，如果攻擊者無(wú)法使用普遍已知方法和技術(shù)來(lái)挖掘 0-day漏洞， 0-day的利用勢(shì)必將有所降低。 當(dāng)我們回顧2021年內(nèi)使用的58個(gè)0-day漏洞時(shí)，我們看到它們與以前公開(kāi)的漏洞如此相似，只有兩個(gè)脫穎而出：一個(gè)是因?yàn)槠渎┒蠢玫募夹g(shù)復(fù)雜性，另一個(gè)是因?yàn)樗褂眠壿嬪e(cuò)誤來(lái)逃離沙盒。
因此，雖然我們看到業(yè)界在檢測(cè)和披露0-day漏洞方面取得了進(jìn)步，但也必須承認(rèn)還有很多工作有待改進(jìn)。
2021年，我們擁有比過(guò)去更多的數(shù)據(jù)點(diǎn)來(lái)了解攻擊者的行為。 然而，這些數(shù)據(jù)也給我們帶來(lái)了比以前更多的問(wèn)題。 不幸的是，積極使用 0-day漏洞攻擊的攻擊者不會(huì)分享他們的“先進(jìn)經(jīng)驗(yàn)”，也不會(huì)分享我們?cè)谧粉欀羞z漏的0-day漏洞的百分比，因此我們永遠(yuǎn)無(wú)法確切知道目前有多少0-day漏洞被發(fā)現(xiàn)并被公開(kāi)披露。
基于我們對(duì)2021年0-day的分析，我們希望在2022年看到以下進(jìn)展，以便繼續(xù)采取措施，努力實(shí)現(xiàn)目標(biāo):
1. 所有供應(yīng)商都同意在其安全公告中披露漏洞的在野利用狀況。
2. 漏洞利用樣本或漏洞利用的詳細(xì)技術(shù)描述被更廣泛地共享。
3. 繼續(xù)協(xié)同努力減少內(nèi)存損壞漏洞或使其無(wú)法利用。啟動(dòng)將顯著影響內(nèi)存破壞漏洞可利用性的緩解措施。
野外0-day數(shù)量創(chuàng)紀(jì)錄
2021是野外0-day數(shù)量創(chuàng)紀(jì)錄的一年。
是軟件安全性越來(lái)越差了，還是攻擊者使用了更多的0-day漏洞？ 抑或是我們發(fā)現(xiàn)和披露 0 0-day漏洞的能力有所提高？ 對(duì)于2020 年到 2021年的顯著增長(zhǎng)，我們認(rèn)為這主要應(yīng)由后者解釋。 盡管過(guò)去幾年攻擊者對(duì)0-day利用的興趣和投資一直在穩(wěn)步增長(zhǎng)，而各主體單位的安全性也需迫切提高，但似乎安全行業(yè)檢測(cè)和披露內(nèi)部漏洞的能力才是解釋2021 年觀察到的 0-day 攻擊增加的主要原因。
雖然我們經(jīng)常談?wù)摗霸谝巴馐褂玫?-day”，事實(shí)上更準(zhǔn)確的說(shuō)法應(yīng)該是“在野外使用時(shí)被檢測(cè)和披露的0-day漏洞”。最顯著的導(dǎo)致這一數(shù)字增加的因素不僅僅是使用，而是檢測(cè)和披露。 更好地檢測(cè)與更透明地披露被利用的0-day漏洞是行業(yè)安全和進(jìn)步的積極指標(biāo)。
總的來(lái)說(shuō)，我們可以將野外0-day數(shù)量的上升的原因分解為:
更多的野外0-day漏洞被檢測(cè)
更多0-day在野利用的被公開(kāi)披露
0-day檢測(cè)持續(xù)增加
在 2019 年的回顧中，我們寫(xiě)過(guò)關(guān)于“檢測(cè)赤字”的文章：“作為一個(gè)社區(qū)，我們嚴(yán)重缺乏檢測(cè)0-day在野利用的能力，以至于無(wú)法從我們收集的數(shù)據(jù)得出重要結(jié)論。” 在過(guò)去的兩年里，我們相信在這一點(diǎn)上已經(jīng)取得了進(jìn)展。
有趣的是，我們正從更多的人那里聽(tīng)說(shuō)，他們已經(jīng)開(kāi)始致力于0-day漏洞的檢測(cè)。 雖然這從數(shù)量上看是一個(gè)非常粗略的衡量標(biāo)準(zhǔn)，但我們的確看到了報(bào)告野外0-day的實(shí)體數(shù)量正在增加。 理所當(dāng)然地，如果努力檢測(cè)0-day漏洞利用的人數(shù)增加，那么檢測(cè)到的0-day在野利數(shù)量也會(huì)隨之增加。
我們注意到，越來(lái)越多的供應(yīng)商在自己的產(chǎn)品中提前發(fā)現(xiàn)了0-day漏洞。通常，供應(yīng)商對(duì)他們自身的產(chǎn)品了解最為全面、未來(lái)預(yù)期更符合實(shí)際更精準(zhǔn)，所以他們投資于（并希望能成功）檢測(cè)針對(duì)自身產(chǎn)品的 0-day漏洞。如上圖所示，供應(yīng)商在他們自己的產(chǎn)品中發(fā)現(xiàn)的野外的0-day數(shù)量有了顯著增加。谷歌在他們自己的產(chǎn)品中發(fā)現(xiàn)了7個(gè)0-day，而微軟在他們的產(chǎn)品中發(fā)現(xiàn)了10個(gè)！
0-day的披露途徑有所增加
在野外檢測(cè)到的0-day漏洞數(shù)量增加的第二個(gè)原因是，這些漏洞正越來(lái)越多地被披露。蘋(píng)果和谷歌Android（我們需要區(qū)分“谷歌Android”而不僅僅是“谷歌”，因?yàn)楣雀鐲hrome在過(guò)去幾年擁有更詳細(xì)的安全公告）分別在2020年11月和2021年1月開(kāi)始在他們的安全報(bào)告中標(biāo)記漏洞，其中包含潛在的大規(guī)模開(kāi)發(fā)的信息分別。當(dāng)供應(yīng)商不給他們的發(fā)布說(shuō)明加注釋時(shí)，我們知道0-day被利用的唯一方法是發(fā)現(xiàn)利用的研究人員挺身而出。如果蘋(píng)果和谷歌Android沒(méi)有標(biāo)注他們的發(fā)布說(shuō)明，公眾可能就不會(huì)知道蘋(píng)果至少存在7個(gè)野外0-day漏洞，Android至少有存在5個(gè)。為什么？因?yàn)檫@些漏洞是由"匿名"記者報(bào)道的。如果記者不想因?yàn)檫@個(gè)漏洞而受到贊揚(yáng)，他們就不太可能公開(kāi)其被利用的具體情況。如果蘋(píng)果和谷歌 Android還沒(méi)有開(kāi)始在他們的安全建議中透明地披露漏洞，那這12個(gè)0-day就不會(huì)被列入今年的名單。
感謝微軟、谷歌Chrome和Adobe多年來(lái)一直在為他們的安全公告添加注釋， 感謝Apache在過(guò)去的一年里為CVE-2021-41773注釋了他們的發(fā)布說(shuō)明。
高通和 ARM 產(chǎn)品的 in-the-wild 0day 在Android 安全公告中被注釋為in-the-wild，但在供應(yīng)商自己的安全公告中沒(méi)有。
很有可能，在2021年，還有其他的在野0-day利用并被發(fā)現(xiàn)，但供應(yīng)商在他們的發(fā)布說(shuō)明中沒(méi)有提到這一點(diǎn)。 因此，在2022年，我們希望更多供應(yīng)商在修補(bǔ)已被廣泛利用的漏洞時(shí)開(kāi)始注意。 在我們確信所有供應(yīng)商都會(huì)公開(kāi)透明地披露野外0-day狀態(tài)之前，還存在一個(gè)大問(wèn)題:到底在野外發(fā)現(xiàn)了多少0-day，但沒(méi)有被供應(yīng)商公開(kāi)標(biāo)注?
新一年，0-day漏洞仍然沒(méi)有新意?
2021年，0-day的數(shù)量有所增加，但它們的攻擊方式卻沒(méi)有太多的新意。一直以來(lái)，0-day 漏洞被認(rèn)為是攻擊者可以使用有效的攻擊手段之一，因此外界普遍相信，攻擊者一定使用了特殊的技巧和方法。但相反的是，我們?cè)?021年看到的0-day漏洞并沒(méi)有跳脫出常規(guī)技術(shù)點(diǎn)，它們通常遵循之前在公共研究中看到的相同的漏洞模式、攻擊手段和攻擊形態(tài)。一旦我們“增加0-day攻擊的難度”這個(gè)目標(biāo)實(shí)現(xiàn)，攻擊者將不得不使用之前從未用過(guò)的漏洞挖掘技術(shù)，在新的攻擊角度挖掘漏洞，而不是猶如今年的數(shù)據(jù)向我們展示的那樣。
今年檢測(cè)到的58個(gè)漏洞中除了2個(gè)例外（我們將在在下面的 iOS 部分中描述），我們所看到的一切都是“無(wú)聊的”、標(biāo)準(zhǔn)化的。
2021年檢測(cè)到的野外0-day漏洞中，有39個(gè)也就是67%的比例是內(nèi)存損壞漏洞。過(guò)去的幾十年里，內(nèi)存損壞漏洞一直是攻擊軟件的標(biāo)準(zhǔn)，并且仍然是攻擊者取得成功的方式。在這些內(nèi)存損壞漏洞中，大多數(shù)還堅(jiān)持使用非常流行和知名的bug：
17 use-after-free
6 out-of-bounds read
4 buffer overflow
4 integer overflow
在接下來(lái)的部分中，我們將深入研究每一個(gè)我們看到的野外0-day的主要平臺(tái)。我們將分享這些趨勢(shì)，并解釋為什么他們?nèi)绱似胀ā?/p>
Chromium (Chrome)
Chromium 在2021年檢測(cè)和披露0-day漏洞有14個(gè)，創(chuàng)下了歷史新高。在這14個(gè)漏洞中，10 個(gè)是渲染器遠(yuǎn)程代碼執(zhí)行錯(cuò)誤，2 個(gè)是沙盒逃逸漏，1個(gè)是信息泄漏，還有1個(gè)用于打開(kāi)除谷歌Chrome之外的Android應(yīng)用程序的網(wǎng)頁(yè)。
14個(gè)0-day漏洞存在于以下組件中：
6 JavaScript Engine - v8 (CVE-2021-21148, CVE-2021-30551, CVE-2021-30563, CVE-2021-30632, CVE-2021-37975, CVE-2021-38003)
2 DOM Engine - Blink (CVE-2021-21193 & CVE-2021-21206)
1 WebGL (CVE-2021-30554)
1 IndexedDB (CVE-2021-30633)
1 webaudio (CVE-2021-21166)
1 Portals (CVE-2021-37973)
1 Android Intents (CVE-2021-38000)
1 Core (CVE-2021-37976)
我們一起來(lái)看一下這些漏洞的目標(biāo)組件，它們都是在以前的公共安全研究和漏洞利用中看到的攻擊面。如果非要說(shuō)有什么不同的話，那就是DOM漏洞比以前少了一些，更多地針對(duì)瀏覽器的其他組件（諸如IndexedDB和WebGL等）。在14個(gè)Chromium 0-day漏洞中，有13個(gè)是內(nèi)存損壞漏洞。與去年類似，這些內(nèi)存損壞漏洞中的大多數(shù)都是use-after-free漏洞。
Chromium的一些漏洞甚至與之前的野外0-day相似。CVE-2021-21166是webaudio中的ScriptProcessorNode::Process()中的一個(gè)問(wèn)題，其中沒(méi)有足夠的密鑰，這樣在主線程和音頻渲染線程中都可以同時(shí)訪問(wèn)緩沖區(qū)。CVE-2019-13720是2019年發(fā)現(xiàn)的0-day，是webaudio中的ConvolverHandler::Process()中的一個(gè)漏洞，它也沒(méi)有足夠的密鑰，以至于主線程和音頻渲染線程都可以同時(shí)訪問(wèn)緩沖區(qū)。
WebKit (Safari)
2021年之前，蘋(píng)果只承認(rèn)過(guò)1個(gè)公開(kāi)已知的針對(duì)WebKit/Safari的0-day，還是由于外部研究人員的分享。2021一年就有7個(gè)。這使得我們很難評(píng)估趨勢(shì)或變化，因?yàn)槲覀儧](méi)有歷史樣本可供參考。相反，我們將在別的未知的Safari漏洞和其他瀏覽器的0-day漏洞的背景下研究2021年的WebKit漏洞。
這7個(gè)0-day漏洞針對(duì)以下組件：
4 Javascript Engine - JavaScript Core (CVE-2021-1870, CVE-2021-1871, CVE-2021-30663, CVE-2021-30665)
1 IndexedDB (CVE-2021-30858)
1 Storage (CVE-2021-30661)
1 Plugins (CVE-2021-1879)
令人有點(diǎn)意外的是，沒(méi)有發(fā)現(xiàn)DOM漏洞。而在前幾年，DOM引擎漏洞通常占瀏覽器0-day漏洞的15-20%，但2021年WebKit中沒(méi)有檢測(cè)到。
如果攻擊者開(kāi)始轉(zhuǎn)向其他模塊，比如第三方庫(kù)或IndexedDB，根本不足為奇。這些模塊可能對(duì)攻擊者更有幫助，因?yàn)槁┒纯赡艽嬖谟诙鄠€(gè)瀏覽器或平臺(tái)中。例如，Chromium中的webaudio漏洞CVE-2021-21166也存在于WebKit中，并被修復(fù)為CVE-2021-1844，盡管沒(méi)有證據(jù)表明它在WebKit中被廣泛利用。2021年針對(duì)Safari使用的 IndexedDB 野外0-day CVE-2021-30858與2020年1月在 Chromium 中修復(fù)的一個(gè)漏洞非常非常相似。
Internet Explorer
自從我們開(kāi)始追蹤野外0-day以來(lái)，Internet Explorer每年檢測(cè)披露的0-day數(shù)字都非常穩(wěn)定。 盡管Internet Explorer在網(wǎng)絡(luò)瀏覽器用戶中的市場(chǎng)份額逐年下降，但事實(shí)上，2021年我們追蹤到的Internet Explorer 0-day與2016年是持平的。
那么，為什么盡管市場(chǎng)份額發(fā)生了變化，但我們看到的野外0-day的數(shù)量變化如此之小呢?因?yàn)閷?duì)于Windows用戶而言，即使用戶不使用Internet Explorer作為其網(wǎng)絡(luò)瀏覽器，Internet Explorer仍然可以成為一個(gè)受攻擊點(diǎn)。雖然0-day漏洞的數(shù)量與我們前幾年看到的大致相當(dāng)，但攻擊的目標(biāo)組件和傳輸方法發(fā)生了變化。2021年出現(xiàn)的4個(gè)0-day中，有3個(gè)是針對(duì)MSHTML瀏覽器引擎的，并通過(guò)web以外的方法傳輸，它們是通過(guò)Office文檔或其他文件格式傳輸給目標(biāo)的。
這4個(gè)0-day漏洞針對(duì)以下組件：
MSHTML browser engine (CVE-2021-26411, CVE-2021-33742, CVE-2021-40444)
Javascript Engine - JScript9 (CVE-2021-34448)
CVE-2021-26411的目標(biāo)最初會(huì)收到一個(gè).mht文件，該文件提示用戶在Internet Explorer中打開(kāi)。一旦在打開(kāi)，該漏洞就被下載并運(yùn)行。CVE-2021-33742和CVE-2021-40444通過(guò)惡意Office文檔發(fā)送給目標(biāo)。CVE-2021-26411和CVE-2021-33742是兩種常見(jiàn)的內(nèi)存損壞漏洞模式:由于在使用對(duì)象的兩個(gè)操作之間存在用戶控制的回調(diào)而導(dǎo)致釋放后使用，以及在回調(diào)期間用戶釋放對(duì)象，以及緩沖區(qū)溢出。
針對(duì)CVE-2021-26411目標(biāo)的活動(dòng)最初收到了一個(gè).mht文件，該文件提示用戶在Internet Explorer中打開(kāi)。一旦在Internet Explorer中打開(kāi)，該漏洞就被下載并運(yùn)行。CVE-2021-33742和CVE-2021-40444通過(guò)惡意Office文檔發(fā)送給目標(biāo)。CVE-2021-26411和CVE-2021-33742是兩種常見(jiàn)的內(nèi)存損壞bug模式:由于在使用對(duì)象的兩個(gè)操作之間存在用戶控制的回調(diào)而導(dǎo)致釋放后使用，以及在回調(diào)期間用戶釋放對(duì)象，以及緩沖區(qū)溢出。
對(duì)于 CVE-2021-26411，該活動(dòng)的目標(biāo)最初收到一個(gè) .mht 文件，該文件提示用戶在 Internet Explorer 中打開(kāi)。 一旦在 Internet Explorer 中打開(kāi)它，就會(huì)下載并運(yùn)行該漏洞利用程序。 CVE-2021-33742和CVE-2021-40444通過(guò)惡意Office文檔傳輸給目標(biāo)。
CVE-2021-26411和CVE-2021-33742是兩種常見(jiàn)的內(nèi)存損漏洞模式：由于使用對(duì)象的兩個(gè)操作之間的用戶控制回調(diào)存在use-after-free漏洞，用戶在回調(diào)和緩沖區(qū)溢出期間釋放該對(duì)象。
在CVE-2021-40444 的利用鏈中使用了幾個(gè)不同的漏洞，隱匿在MSHTML中的那個(gè)一旦打開(kāi) Office文檔，就會(huì)運(yùn)行有效負(fù)載：下載CAB文件，解壓縮，然后執(zhí)行該CAB中的DLL函數(shù)。 與前兩個(gè)MSHTML漏洞不同，這是URL解析中的邏輯錯(cuò)誤，而不是內(nèi)存損壞錯(cuò)誤
Windows
與前幾年相比，Windows是我們看到組件目標(biāo)變化最大的平臺(tái)。然而，這種轉(zhuǎn)變已經(jīng)進(jìn)行了幾年，并預(yù)計(jì)持續(xù)到2020年Windows 7系統(tǒng)壽命到期時(shí)，因此我們?nèi)匀徊徽J(rèn)為這是什么新鮮事。
在2021年，有10個(gè)Window野外0-day針對(duì)7個(gè)不同的組件:
2 Enhanced crypto provider (CVE-2021-31199, CVE-2021-31201)
2 NTOS kernel (CVE-2021-33771, CVE-2021-31979)
2 Win32k (CVE-2021-1732, CVE-2021-40449)
1 Windows update medic (CVE-2021-36948)
1 SuperFetch (CVE-2021-31955)
1 dwmcore.dll (CVE-2021-28310)
1 ntfs.sys (CVE-2021-31956)
針對(duì)不同組件的數(shù)量與過(guò)去幾年相比有所不同。 例如，2019 年75%的Windows 0-day漏洞 以Win32k為目標(biāo)，而在 2021年，這個(gè)比例下降至20%。之所以我們能預(yù)料到這一點(diǎn)，是因?yàn)?019年針對(duì)Win32k的8個(gè)0-day漏洞中有6個(gè)沒(méi)有針對(duì)當(dāng)時(shí)最新版本的 Windows 10，而是以舊版本為目標(biāo)。 隨著 Windows 10投入越來(lái)越多的資源鎖定Win32k的攻擊面，舊版本的生命周期就慢慢走向衰亡，Win32k也就成為一個(gè)越來(lái)越?jīng)]有吸引力的攻擊面了。
與多年來(lái)我們看到的許多Win32k漏洞類似，這兩個(gè)2021 Win32k野外0-day漏洞是由于自定義用戶回調(diào)造成的。用戶調(diào)用在回調(diào)期間更改對(duì)象狀態(tài)的函數(shù)，Win32k無(wú)法正確處理這些更改。CVE-2021-1732 是一個(gè)類型混淆漏洞，由于 xxxClientAllocWindowClassExtraBytes中的用戶回調(diào)導(dǎo)致越界讀取和寫(xiě)入。如果在回調(diào)期間調(diào)用 NtUserConsoleControl，則會(huì)在窗口結(jié)構(gòu)中設(shè)置一個(gè)標(biāo)志，以指示該字段是內(nèi)核堆的偏移量。
xxxClientAllocWindowClassExtraBytes不對(duì)此進(jìn)行檢查，并在不清除標(biāo)志的情況下將該字段作為用戶模式指針寫(xiě)入。2022年發(fā)現(xiàn)并披露的第一個(gè)野外0-day，CVE-2022-21882，是由于CVE-2021-1732實(shí)際上沒(méi)有完全修復(fù)，攻擊者找到了繞過(guò)原始補(bǔ)丁的方法，再次觸發(fā)了漏洞。
CVE-2021-40449是NtGdiResetDC中的use-after-free漏洞，那是因?yàn)閷?duì)象在用戶回調(diào)期間被釋放。
iOS/macOS
正如上文“更多的披露”部分所討論的，2021年，蘋(píng)果首次在其發(fā)布說(shuō)明中標(biāo)注野外漏洞信息, 檢測(cè)并披露了5個(gè)iOS野外0-day和一個(gè)macOS野外0-day(CVE-2021-30869)。在本節(jié)中，我們將合并討論iOS和macOS，原因有二：1) 這兩個(gè)操作系統(tǒng)包含相似的組件，2) macOS 的樣本容量非常小，僅披露一個(gè)漏洞。
5個(gè)iOS和macOS野外0-day漏洞瞄準(zhǔn)了4種不同的攻擊面:
IOMobileFrameBuffer (CVE-2021-30807, CVE-2021-30883)
XNU Kernel (CVE-2021-1782 & CVE-2021-30869)
CoreGraphics (CVE-2021-30860)
CommCenter (FORCEDENTRY sandbox escape - CVE requested, not yet assigned)
這4個(gè)攻擊面并不新穎。 IOMobileFrameBuffer 多年來(lái)一直是公共安全研究的對(duì)象。 例如，2016年的盤古越獄使用了CVE-2016-4654，這是IOMobileFrameBuffer中的堆緩沖區(qū)溢出。 IOMobileFrameBuffer 管理屏幕的幀緩沖區(qū)。對(duì)于iPhone 11（A13）及更低版本，IOMobileFrameBuffer 是內(nèi)核驅(qū)動(dòng)程序。從 A14 開(kāi)始，它在協(xié)處理器 DCP 上運(yùn)行。這是一個(gè)流行的攻擊面，因?yàn)閺臍v史上看，它可以從沙盒應(yīng)用程序中訪問(wèn)。2021年，IOMobileFrameBuffer 中檢測(cè)出2個(gè)0-day。 CVE-2021-30807 是越界讀取，CVE-2021-30883 是整數(shù)溢出，這兩個(gè)都是常見(jiàn)的內(nèi)存破壞漏洞。2022年，我們?cè)贗OMobileFrameBuffe檢測(cè)出另一個(gè)0-day，CVE-2022-22587。
一個(gè)iOS 0-day漏洞和macOS 0-day漏洞都利用了XNU內(nèi)核中的漏洞，并且這兩個(gè)漏洞都存在于與 XNU的進(jìn)程間通信（IPC）功能有關(guān)的代碼中。 CVE-2021-1782 利用了mach vouchers中的漏洞，而 CVE-2021-30869 利用了mach messages中的漏洞。這不是我們第一次看到0-day漏洞，更不用說(shuō)針對(duì)mach vouchers和mach messages的公共安全研究了。 CVE-2019-6625 作為針對(duì) iOS 11.4.1-12.1.2 的利用鏈的一部分被利用，也是mach vouchers中的一個(gè)漏洞。
mach messages也一直是公共安全研究的熱門。2020年，mach messages中檢測(cè)出2個(gè)0-day漏洞：CVE-2020-27932和CVE-2020-2795。今年的CVE-2021-30869與2020年的 CVE-2020-27932 非常相近。事實(shí)上，研究人員Tielei Wang和Xinru Chi在2021年4月的zer0Con 2021上已經(jīng)介紹過(guò)這個(gè)漏洞，他們解釋說(shuō)，該漏洞是在對(duì)CVE-2020-27932進(jìn)行變異分析時(shí)發(fā)現(xiàn)的。TieLei Wang 在Twitter上說(shuō)，他們?cè)?020年12月發(fā)現(xiàn)了這個(gè)漏洞，并注意到它已在iOS 14.4和macOS 11.2 的beta版本中得到修復(fù)，這也是為什么他們?cè)赯er0Con上展示這個(gè)漏洞的原因。這個(gè)0-day在野利用僅針對(duì)macOS 10，但其利用的技術(shù)與本文上述的相同。
兩個(gè)FORCEDENTRY 漏洞（CVE-2021-30860 和沙盒逃逸）是今年唯一讓我們驚呼“哇！”的時(shí)候。今年，CVE-2021-30860，在CoreGraphics中出現(xiàn)整數(shù)溢出，這是因?yàn)椋?/p>
多年來(lái)，我們都聽(tīng)說(shuō)過(guò)攻擊者如何使用“零點(diǎn)擊”iMessage 漏洞，現(xiàn)在我們終于有了一個(gè)廣為人知的案列，
這個(gè)漏洞的確令人印象深刻。
這個(gè)沙盒逃逸（CVE 已請(qǐng)求，尚未分配）令人印象深刻，因?yàn)檫@是我們見(jiàn)過(guò)的為數(shù)不多的只使用邏輯錯(cuò)誤而不是標(biāo)準(zhǔn)內(nèi)存損壞漏洞的沙盒箱逃逸之一。
對(duì)于CVE-2021-30860，漏洞本身并不特別引人注目：CoreGraphics PDF解碼器的JBIG2解析器中出現(xiàn)了一個(gè)典型的整數(shù)溢出。然而，Samuel Gro?和Ian Beer卻將該漏洞描述為“他們見(jiàn)過(guò)的技術(shù)最復(fù)雜的漏洞之一”。 他們的博客分享了所有細(xì)節(jié)，但重點(diǎn)是該漏洞使用了JBIG2中可用的邏輯運(yùn)算符來(lái)構(gòu)建自己的計(jì)算機(jī)體系結(jié)構(gòu)的NAND門。然后，該漏洞利用這個(gè)新的自定義架構(gòu)編寫(xiě)其剩余的漏洞。他們的博文中，我們可以看到：
“他們使用超過(guò)70,000個(gè)定義邏輯位操作的段命令，定義了一個(gè)具有寄存器、完整64位加法器和比較器等功能的小型計(jì)算機(jī)架構(gòu)，用于搜索內(nèi)存和執(zhí)行算術(shù)運(yùn)算。雖然它沒(méi)有Javascript快，但在計(jì)算上基本上是等效的。
沙盒逃逸漏洞的引導(dǎo)操作被編寫(xiě)為在這個(gè)邏輯電路上運(yùn)行，整個(gè)程序運(yùn)行在這個(gè)怪異的模擬環(huán)境中，這個(gè)模擬環(huán)境是通過(guò)JBIG2的單個(gè)解壓縮通道創(chuàng)建的。這非常不可思議，同時(shí)也非?？膳??！?/p>
這是一個(gè)“讓0-day攻擊變得艱難”的例子，攻擊者必須開(kāi)發(fā)一種新的、獨(dú)特的方法來(lái)利用漏洞，而這種方法需要大量的專業(yè)知識(shí)和/或時(shí)間來(lái)開(kāi)發(fā)。今年，這兩個(gè)FORCEDENTRY漏洞是58個(gè)0-day漏洞中唯一給我們留下深刻印象的。如今，門檻已經(jīng)提高，希望在未來(lái)任何成功的漏洞都應(yīng)該這樣做。
Android
今年共檢測(cè)并披露了7個(gè) Android野外0-day漏洞。 2021年之前只有1個(gè)，是2019年的CVE-2019-2215。 和WebKit一樣，這種缺乏數(shù)據(jù)的情況讓我們很難評(píng)估趨勢(shì)和變化。相反取而代之的是，我們會(huì)將其與公共安全研究進(jìn)行比較。
這7個(gè)Android 0-day瞄準(zhǔn)了以下組件:
Qualcomm Adreno GPU driver (CVE-2020-11261, CVE-2021-1905, CVE-2021-1906)
ARM Mali GPU driver (CVE-2021-28663, CVE-2021-28664)
Upstream Linux kernel (CVE-2021-1048, CVE-2021-0920)
2021的7個(gè)0-day漏洞中，有5個(gè)是以GPU驅(qū)動(dòng)程序?yàn)槟繕?biāo)的。當(dāng)我們想到Android生態(tài)系統(tǒng)的演變以及最近對(duì)Android的公共安全研究時(shí)，這一點(diǎn)也不令人驚訝。Android的生態(tài)系統(tǒng)是相當(dāng)分散的：許多不同的內(nèi)核版本、不同的制造商定制，等等。如果攻擊者想要攻擊Android設(shè)備，他們通常需要維護(hù)許多不同的漏洞才能覆蓋比例相當(dāng)?shù)腁ndroid生態(tài)系統(tǒng)。然而，如果攻擊者選擇攻擊GPU內(nèi)核驅(qū)動(dòng)程序而不是其他組件，他們只需要兩個(gè)漏洞，因?yàn)榇蠖鄶?shù)Android設(shè)備使用2個(gè)GPU中的1個(gè)：高通Adreno GPU或ARM Mali GPU。
過(guò)去幾年的公共安全研究也反映了這一選擇。在針對(duì) Android 設(shè)備開(kāi)發(fā)完整的漏洞利用鏈（用于防御目的）時(shí)，Guang Gong，Man Yue Mo，和Ben Hawkes都選擇攻擊GPU內(nèi)核驅(qū)動(dòng)，以實(shí)現(xiàn)本地權(quán)限升級(jí)?？吹揭巴獾?-day也針對(duì)GPU，這更像是一種確認(rèn)，而不是一種啟示。在針對(duì) GPU 驅(qū)動(dòng)程序的5個(gè)0-day漏洞中，3個(gè)針對(duì)高通Adreno，2個(gè)針對(duì)ARM Mali。
兩個(gè)非GPU驅(qū)動(dòng)程序0-day漏洞（CVE-2021-0920 和 CVE-2021-1048）針對(duì)上游Linux內(nèi)核。不幸的是，這兩個(gè)漏洞與2019年檢測(cè)到的Android野外0-day漏洞有一個(gè)共同特征：3個(gè)漏洞在被Android利用之前都是已知的。雖然樣本量很小，但我們還是很驚訝地發(fā)現(xiàn)，所有已知的針對(duì)內(nèi)核的Android 0-day漏洞在被利用之前都是已知的。
現(xiàn)在被稱為CVE-2021-0920的漏洞實(shí)際上是在2016年9月發(fā)現(xiàn)的，并在Linux內(nèi)核郵件列表中進(jìn)行了討論。甚至早在2016年就開(kāi)發(fā)過(guò)一個(gè)補(bǔ)丁，雖然最終沒(méi)有提交。在檢測(cè)到針對(duì) Android的野外漏洞利用后，該漏洞最終于2021年7月在Linux內(nèi)核中得到修復(fù)。該補(bǔ)丁隨后于2021年11月進(jìn)入Android安全公告。
Linux內(nèi)核打過(guò)補(bǔ)丁之后的14個(gè)月中，CVE-2021-1048都未及時(shí)在Android中打補(bǔ)丁。inux 內(nèi)核實(shí)際上只在幾周內(nèi)易受這個(gè)問(wèn)題的影響，但由于Android補(bǔ)丁的做法，這幾個(gè)星期對(duì)一些Android設(shè)備來(lái)說(shuō)簡(jiǎn)直如同長(zhǎng)達(dá)一年。如果Android OEM同步到上游內(nèi)核，那么他們很可能在某個(gè)時(shí)候針對(duì)該漏洞進(jìn)行了修補(bǔ)。但許多設(shè)備，比如最近的三星設(shè)備，并沒(méi)有這樣做，因此很容易受到攻擊。
Microsoft Exchange Server
2021年，共檢測(cè)到5個(gè)針對(duì)Microsoft Exchange Server的0-day漏洞，這是自我們開(kāi)始追蹤野外0-day以來(lái)，第一次檢測(cè)到并披露Exchange Server的野外0-day。前四個(gè)（CVE-2021-26855, CVE-2021-26857, CVE-2021-26858和CVE-2021-27065）都在同一次操作中發(fā)現(xiàn)的，在公開(kāi)的第一時(shí)間就完成了修補(bǔ)。第五個(gè)（CVE-2021-42321）于2021年11月自行修補(bǔ)，隨后CVE-2021-42321在天府杯上展示，然后被微軟在野外發(fā)現(xiàn)。盡管CVE-2021-42321的鏈中沒(méi)有其他的野外0-day被披露，但由于 CVE-2021-42321是個(gè)身份驗(yàn)證后漏洞，攻擊者至少需要另一個(gè)0-day漏洞天才能成功利用它。
上述提到的第一波發(fā)現(xiàn)的Exchange野外0-day漏洞中的一個(gè)，CVE-2021-26855，也被稱為“ProxyLogon”，是唯一一個(gè)預(yù)授權(quán)的。CVE-2021-26855 是一個(gè)服務(wù)器端請(qǐng)求偽造（SSRF）漏洞，允許未經(jīng)身份驗(yàn)證的攻擊者向Exchange服務(wù)器發(fā)送任意HTTP請(qǐng)求。其他三個(gè)漏洞都是身份驗(yàn)證后漏洞。例如，CVE-2021-26858和CVE-2021-27065 允許攻擊者將任意文件寫(xiě)入系統(tǒng)。 CVE-2021-26857 是由于統(tǒng)一消息服務(wù)中的反序列化錯(cuò)誤導(dǎo)致的遠(yuǎn)程代碼執(zhí)行漏洞，它允許攻擊者以特權(quán)系統(tǒng)用戶的身份運(yùn)行代碼。
對(duì)于第二波發(fā)現(xiàn)的漏洞，CVE-2021-42321，與 CVE-2021-26858 一樣，是由于不安全地反序列化而導(dǎo)致的身份驗(yàn)證后遠(yuǎn)程執(zhí)行漏洞。 微軟似乎在嘗試強(qiáng)化Exchange時(shí)無(wú)意中引入了另一個(gè)反序列化漏洞。
盡管2021年在Exchange中檢測(cè)并披露了大量的0-day漏洞，但我們要記得，它們僅在兩個(gè)不同的活動(dòng)中都被用作0-day攻擊。 從這個(gè)列子中，可以看出為什么我們不建議使用產(chǎn)品中的0-day作為評(píng)估產(chǎn)品安全性的指標(biāo)。 要求攻擊者使用四個(gè)0-day來(lái)獲得成功比攻擊者只需要一個(gè)0-day來(lái)成功獲得訪問(wèn)權(quán)限更可取。
雖然這是Project Zero項(xiàng)目開(kāi)始追蹤行動(dòng)以來(lái)首次檢測(cè)并披露Exchange野外0-day漏洞，但這并不令人意外，在2020年，Exchange Server 就有被n-day漏洞利用的歷史。無(wú)論這是攻擊者開(kāi)始0-day攻擊的第一年，還是防御者開(kāi)始檢測(cè) 0-day攻擊的第一年，不要對(duì)這樣的演變感到意外，而且它很可能持續(xù)到2022年。
懸而未決的問(wèn)題
雖然我們?cè)跈z測(cè)和披露方面取得了一些進(jìn)展，但這一進(jìn)展表明還有多少工作要做。我們獲得的數(shù)據(jù)越多，關(guān)于檢測(cè)偏差的問(wèn)題就越多。
除非攻擊者決定與我們分享他們所有的漏洞利用，我們才能完全知道0-day漏洞公開(kāi)的比例究竟是多少。因此，進(jìn)入2022年后，我們給自己整理了一些關(guān)鍵問(wèn)題：
未知的0-day漏洞在哪兒？
盡管2021年內(nèi)發(fā)現(xiàn)了許多0-day漏洞，但尚未探明0-day漏洞的關(guān)鍵目標(biāo)是什么。 例如，我們知道 WhatsApp、Signal、Telegram信息傳遞應(yīng)用程序是攻擊者感興趣的目標(biāo)，但過(guò)去一年發(fā)現(xiàn)的眾多0-day漏洞中，僅有1個(gè)iMessage 0-day是針對(duì)信息傳遞應(yīng)用程序的。即使是2014年開(kāi)始追蹤行動(dòng)以來(lái)也不過(guò)兩個(gè)：2019 年的WhatsApp 0-day和2021年的 iMessage 0-day。
除了信息傳遞應(yīng)用程序之外，我們也希望看看其他平臺(tái)是否會(huì)成為0-day漏洞的目標(biāo)，但公開(kāi)示例卻根本沒(méi)有或者少得可憐。例如，自2014年年中以來(lái)，macOS 和 Linux各檢測(cè)出一個(gè)野外0-day漏洞。 目前還沒(méi)有已知的針對(duì)云端、CPU漏洞或其他手機(jī)組件（如WiFi芯片或基帶）的野外0-day漏洞。
這就引發(fā)我們的思考：這些0-day漏洞案列的缺失是由于缺乏檢測(cè)還是缺乏披露造成的？還是兩者兼而有之？
有些供應(yīng)商未公開(kāi)過(guò)0-day漏洞，是因?yàn)樗麄儚奈窗l(fā)現(xiàn)，還是因?yàn)樗麄儾还_(kāi)披露?
除非供應(yīng)商公開(kāi)披露其平臺(tái)中所有漏洞的利用狀態(tài)，否則我們公眾將不會(huì)知道，沒(méi)有注釋是否就是意味著沒(méi)有已知的漏洞利用，或者漏洞存在，只是供應(yīng)商沒(méi)有公開(kāi)分享這些信息。 值得慶幸的是，這個(gè)問(wèn)題有了一個(gè)非常明確的解決方案：所有設(shè)備和軟件供應(yīng)商都已同意在有證據(jù)表明他們的產(chǎn)品中的漏洞被在野利用時(shí)公開(kāi)披露。
我們看到相同的錯(cuò)誤模式是因?yàn)槲覀冎廊绾螜z測(cè)？
正如我們?cè)诒緢?bào)告前面部分所述，我們?cè)?021年檢測(cè)到的所有0-day漏洞都與先前的漏洞有相似之處。這讓我們想知道這是否真的代表了攻擊者正在使用的東西。攻擊者是否真的只是使用先前公開(kāi)的漏洞和組件中的漏洞就取得成功？ 還是說(shuō)我們檢測(cè)所有這些帶有已知錯(cuò)誤模式的0-day漏洞是因?yàn)槲覀冎廊绾螜z測(cè)？ 公共安全研究給出了答案，是的，攻擊者在大多數(shù)情況下仍然能夠成功利用已知組件與漏洞類型中的漏洞。但我們?nèi)匀幌Ｍ吹揭恍┬缕娴摹⒁庀氩坏降穆┒?。我們?cè)缭?019年的年度回顧中就提出了這個(gè)問(wèn)題，現(xiàn)在這個(gè)問(wèn)題仍然存在。
dspl0itz 在哪里？
要成功利用漏洞，有兩個(gè)關(guān)鍵組成部分：利用什么漏洞和漏洞的利用方法（如何將該漏洞轉(zhuǎn)化為有用的東西）。
不幸的是，這份報(bào)告只能真正分析其中一個(gè)組成部分：什么漏洞。58個(gè)0-day漏洞中，只有 5個(gè)公開(kāi)了漏洞的利用示例。在野外發(fā)現(xiàn)的0-day漏洞是攻擊者的失敗案例，也是防御者了解攻擊者正在做什么并使其攻擊更難、更耗時(shí)、更昂貴的關(guān)鍵機(jī)會(huì)。然而，如果沒(méi)有利用樣本或基于樣本的詳細(xì)技術(shù)文章，我們只能專注于修復(fù)漏洞而不是削弱利用的方法。這就意味著攻擊者能夠繼續(xù)使用他們現(xiàn)有的利用方法，而不必回到設(shè)計(jì)和開(kāi)發(fā)階段來(lái)構(gòu)建新的利用方法。雖然不得不承認(rèn)共享漏洞利用樣本非常具有挑戰(zhàn)性（我們也正面臨這樣的挑戰(zhàn)?。?，但我們?nèi)匀幌Ｍ?2022 年能夠更多地共享漏洞利用樣本或詳細(xì)的技術(shù)文章，以便我們能夠團(tuán)結(jié)起來(lái)，利用每一條可能的信息，防止讓攻擊者更難毒害更多用戶。
順便說(shuō)一句，如果您有意愿與我們分享漏洞利用示例，請(qǐng)與我們聯(lián)系。無(wú)論是僅與我們分享，讓我們撰寫(xiě)詳細(xì)的技術(shù)描述和分析，還是讓我們?nèi)ス_(kāi)地分享，我們都很樂(lè)意與您合作。
總結(jié)
回顧2021年， 我們可以看到，在 0-day 漏洞的檢測(cè)和披露方面，行業(yè)取得了明顯的行業(yè)進(jìn)步，但顯然針對(duì)0-day漏洞，行業(yè)還有很大的進(jìn)步空間。作為一個(gè)產(chǎn)業(yè)，我們還并沒(méi)有實(shí)現(xiàn)“增加0-day攻擊的難度”的目標(biāo)。攻擊者僅利用普遍技術(shù)就成功實(shí)施了攻擊。我們的目標(biāo)是每當(dāng)我們檢測(cè)到攻擊者的一個(gè)漏洞利用時(shí)，就能迫使他們從頭開(kāi)始：他們必須發(fā)現(xiàn)一個(gè)全新的漏洞，必須投入時(shí)間學(xué)習(xí)和分析新的攻擊面，必須開(kāi)發(fā)一個(gè)全新的利用方法。
雖然這一切看起來(lái)頗有難度，但我們?nèi)员в袠?lè)觀態(tài)度。2019年，我們討論了0-day漏洞利用的巨大檢測(cè)缺陷，2年后的今天檢測(cè)和披露都增長(zhǎng)了一倍多。因此，雖然還有很多工作要做，但這并不難解決。技術(shù)和安全行業(yè)可以采取一些具體步驟來(lái)使其取得更大的進(jìn)步：
1. 將0-day漏洞的披露當(dāng)做行業(yè)的公開(kāi)標(biāo)準(zhǔn)之一。
2. 供應(yīng)商和安全研究人員共享漏洞利用樣本或漏洞利用技術(shù)的詳細(xì)描述。
3. 繼續(xù)共同努力減少內(nèi)存損壞漏洞或使其無(wú)法利用。
到2021年，我們不斷看到對(duì)用戶和實(shí)體使用的0-day漏洞對(duì)現(xiàn)實(shí)世界造成的影響。 雖然地球上的大多數(shù)人不需要擔(dān)心自己被0-day攻擊的個(gè)人風(fēng)險(xiǎn)，但0-day攻擊仍然影響著我們每一個(gè)人。 這些0-day漏洞往往會(huì)對(duì)社會(huì)產(chǎn)生巨大的影響，因此我們需要繼續(xù)盡我們所能，讓攻擊者更難在這些攻擊中取得成功。
2021年向我們展示了我們正走在正確的軌道上并取得進(jìn)展，但要實(shí)現(xiàn)“增加0-day攻擊的難度”這個(gè)目標(biāo)，還有很多工作要做。
