編者按

“Project Zero”是一項由谷歌成立的互聯網安全項目，成立時間為2014年7月。該團隊主要由谷歌內部頂尖安全工程師組成，旨在發現、追蹤和修補全球性的軟件安全漏洞。自2019起，團隊每年會對過去一年內檢測到的0-day漏洞在野利用進行回顧并發布報告。2021年內，“Project Zero”共檢測并披露了58個在野外的0-day漏洞，這一數字創下了項目2014年成立以來的新紀錄。本篇報告中，“Project Zero”團隊詳細向我們介紹了被檢測到的58個0-day漏洞的類型和攻擊模式，并分析了2021年0-day數據暴增的原因。另外，在報告中，我們也可以清晰地看到團隊在2022年的工作方向。

以下是報告正文：

這是我們自2019年起連續第三年對0-day漏洞的在野利用進行回顧。

每一年，我們都會回顧這一年內在野外發現和披露的所有0-day漏洞，并對其進行綜合考量。本報告的目的并不是對每個漏洞進行分析，而是將一年來的漏洞作為一個整體進行分析，尋找趨勢、差距、經驗教訓和成功的防護案例。

我們撰寫并分享這份報告是希望增加0-day漏洞利用的難度。我們希望0-day利用的成本不斷增加，當披露和防護的資源更集中，攻擊者自然更難對其加以利用。

我們將在正文中展示完整的論證過程，然后在結論中總結我們對未來的展望與操作方法。如果你并不喜歡深入挖掘細節，那就看看執行摘要和結論吧。

重點發現

2021年內共檢測并披露了58個在野外的0-day漏洞，這是自2014年年中“Project Zero”項目開始追蹤以來最多的。此前的最大值是2015年檢測到的28個，這次有足足兩倍之多，尤其是，2020年只檢測到25個。自2014年年中以來，我們一直在這個電子表格中追蹤已知的公開的0-day漏洞。

雖然我們經常討論0-day漏洞的在野利用數量，但我們實際上討論的是在野外檢測到和被披露的0-day漏洞的數量。這就引出了我們的第一個結論:我們認為，2021年報告顯示0-day漏洞的大幅增加是由于對它們檢測和披露的渠道增多，而不是簡單地只是0-day漏洞的在野利用增加。

從數據中我們可以看出，其實攻擊者的方法與前幾年相比并沒有太大的變化。攻擊者使用的是相同的漏洞模式和挖掘技術，并針對相同的攻擊面加以打擊。 “Project Zero”的使命是“增加0-day攻擊的難度”。

總體而言，如果攻擊者無法使用普遍已知方法和技術來挖掘 0-day漏洞， 0-day的利用勢必將有所降低。 當我們回顧2021年內使用的58個0-day漏洞時，我們看到它們與以前公開的漏洞如此相似，只有兩個脫穎而出：一個是因為其漏洞利用的技術復雜性，另一個是因為它使用邏輯錯誤來逃離沙盒。

因此，雖然我們看到業界在檢測和披露0-day漏洞方面取得了進步，但也必須承認還有很多工作有待改進。

2021年，我們擁有比過去更多的數據點來了解攻擊者的行為。 然而，這些數據也給我們帶來了比以前更多的問題。 不幸的是，積極使用 0-day漏洞攻擊的攻擊者不會分享他們的“先進經驗”，也不會分享我們在追蹤中遺漏的0-day漏洞的百分比，因此我們永遠無法確切知道目前有多少0-day漏洞被發現并被公開披露。

基于我們對2021年0-day的分析，我們希望在2022年看到以下進展，以便繼續采取措施，努力實現目標:

• 所有供應商都同意在其安全公告中披露漏洞的在野利用狀況。
• 漏洞利用樣本或漏洞利用的詳細技術描述被更廣泛地共享。
• 繼續協同努力減少內存損壞漏洞或使其無法利用。啟動將顯著影響內存破壞漏洞可利用性的緩解措施。

野外0-day數量創紀錄

2021是野外0-day數量創紀錄的一年。

是軟件安全性越來越差了，還是攻擊者使用了更多的0-day漏洞? 抑或是我們發現和披露 0 0-day漏洞的能力有所提高? 對于2020 年到 2021年的顯著增長，我們認為這主要應由后者解釋。 盡管過去幾年攻擊者對0-day利用的興趣和投資一直在穩步增長，而各主體單位的安全性也需迫切提高，但似乎安全行業檢測和披露內部漏洞的能力才是解釋2021 年觀察到的 0-day 攻擊增加的主要原因。

雖然我們經常談論“在野外使用的0-day”，事實上更準確的說法應該是“在野外使用時被檢測和披露的0-day漏洞”。最顯著的導致這一數字增加的因素不僅僅是使用，而是檢測和披露。 更好地檢測與更透明地披露被利用的0-day漏洞是行業安全和進步的積極指標。

總的來說，我們可以將野外0-day數量的上升的原因分解為:

• 更多的野外0-day漏洞被檢測
• 更多0-day在野利用的被公開披露

0-day檢測持續增加

在 2019 年的回顧中，我們寫過關于“檢測赤字”的文章：“作為一個社區，我們嚴重缺乏檢測0-day在野利用的能力，以至于無法從我們收集的數據得出重要結論。” 在過去的兩年里，我們相信在這一點上已經取得了進展。

有趣的是，我們正從更多的人那里聽說，他們已經開始致力于0-day漏洞的檢測。 雖然這從數量上看是一個非常粗略的衡量標準，但我們的確看到了報告野外0-day的實體數量正在增加。 理所當然地，如果努力檢測0-day漏洞利用的人數增加，那么檢測到的0-day在野利數量也會隨之增加。

我們注意到，越來越多的供應商在自己的產品中提前發現了0-day漏洞。通常，供應商對他們自身的產品了解最為全面、未來預期更符合實際更精準，所以他們投資于(并希望能成功)檢測針對自身產品的 0-day漏洞。如上圖所示，供應商在他們自己的產品中發現的野外的0-day數量有了顯著增加。谷歌在他們自己的產品中發現了7個0-day，而微軟在他們的產品中發現了10個！

0-day的披露途徑有所增加

在野外檢測到的0-day漏洞數量增加的第二個原因是，這些漏洞正越來越多地被披露。蘋果和谷歌Android(我們需要區分“谷歌Android”而不僅僅是“谷歌”，因為谷歌Chrome在過去幾年擁有更詳細的安全公告)分別在2020年11月和2021年1月開始在他們的安全報告中標記漏洞，其中包含潛在的大規模開發的信息分別。當供應商不給他們的發布說明加注釋時，我們知道0-day被利用的唯一方法是發現利用的研究人員挺身而出。如果蘋果和谷歌Android沒有標注他們的發布說明，公眾可能就不會知道蘋果至少存在7個野外0-day漏洞，Android至少有存在5個。為什么?因為這些漏洞是由"匿名"記者報道的。如果記者不想因為這個漏洞而受到贊揚，他們就不太可能公開其被利用的具體情況。如果蘋果和谷歌 Android還沒有開始在他們的安全建議中透明地披露漏洞，那這12個0-day就不會被列入今年的名單。

感謝微軟、谷歌Chrome和Adobe多年來一直在為他們的安全公告添加注釋， 感謝Apache在過去的一年里為CVE-2021-41773注釋了他們的發布說明。

高通和 ARM 產品的 in-the-wild 0day 在Android 安全公告中被注釋為in-the-wild，但在供應商自己的安全公告中沒有。

很有可能，在2021年，還有其他的在野0-day利用并被發現，但供應商在他們的發布說明中沒有提到這一點。 因此，在2022年，我們希望更多供應商在修補已被廣泛利用的漏洞時開始注意。 在我們確信所有供應商都會公開透明地披露野外0-day狀態之前，還存在一個大問題:到底在野外發現了多少0-day，但沒有被供應商公開標注?

新一年，0-day漏洞仍然沒有新意?

2021年，0-day的數量有所增加，但它們的攻擊方式卻沒有太多的新意。一直以來，0-day 漏洞被認為是攻擊者可以使用有效的攻擊手段之一，因此外界普遍相信，攻擊者一定使用了特殊的技巧和方法。但相反的是，我們在2021年看到的0-day漏洞并沒有跳脫出常規技術點，它們通常遵循之前在公共研究中看到的相同的漏洞模式、攻擊手段和攻擊形態。一旦我們“增加0-day攻擊的難度”這個目標實現，攻擊者將不得不使用之前從未用過的漏洞挖掘技術，在新的攻擊角度挖掘漏洞，而不是猶如今年的數據向我們展示的那樣。

今年檢測到的58個漏洞中除了2個例外(我們將在在下面的 iOS 部分中描述)，我們所看到的一切都是“無聊的”、標準化的。

2021年檢測到的野外0-day漏洞中，有39個也就是67%的比例是內存損壞漏洞。過去的幾十年里，內存損壞漏洞一直是攻擊軟件的標準，并且仍然是攻擊者取得成功的方式。在這些內存損壞漏洞中，大多數還堅持使用非常流行和知名的bug：

• 17 use-after-free
• 6 out-of-bounds read
• 4 buffer overflow
• 4 integer overflow

在接下來的部分中，我們將深入研究每一個我們看到的野外0-day的主要平臺。我們將分享這些趨勢，并解釋為什么他們如此普通。

Chromium (Chrome)

Chromium 在2021年檢測和披露0-day漏洞有14個，創下了歷史新高。在這14個漏洞中，10 個是渲染器遠程代碼執行錯誤，2 個是沙盒逃逸漏，1個是信息泄漏，還有1個用于打開除谷歌Chrome之外的Android應用程序的網頁。

14個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)

我們一起來看一下這些漏洞的目標組件，它們都是在以前的公共安全研究和漏洞利用中看到的攻擊面。如果非要說有什么不同的話，那就是DOM漏洞比以前少了一些，更多地針對瀏覽器的其他組件(諸如IndexedDB和WebGL等)。在14個Chromium 0-day漏洞中，有13個是內存損壞漏洞。與去年類似，這些內存損壞漏洞中的大多數都是use-after-free漏洞。

Chromium的一些漏洞甚至與之前的野外0-day相似。CVE-2021-21166是webaudio中的ScriptProcessorNode::Process()中的一個問題，其中沒有足夠的密鑰，這樣在主線程和音頻渲染線程中都可以同時訪問緩沖區。CVE-2019-13720是2019年發現的0-day，是webaudio中的ConvolverHandler::Process()中的一個漏洞，它也沒有足夠的密鑰，以至于主線程和音頻渲染線程都可以同時訪問緩沖區。

WebKit (Safari)

2021年之前，蘋果只承認過1個公開已知的針對WebKit/Safari的0-day，還是由于外部研究人員的分享。2021一年就有7個。這使得我們很難評估趨勢或變化，因為我們沒有歷史樣本可供參考。相反，我們將在別的未知的Safari漏洞和其他瀏覽器的0-day漏洞的背景下研究2021年的WebKit漏洞。

這7個0-day漏洞針對以下組件：

• 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)

令人有點意外的是，沒有發現DOM漏洞。而在前幾年，DOM引擎漏洞通常占瀏覽器0-day漏洞的15-20%，但2021年WebKit中沒有檢測到。

如果攻擊者開始轉向其他模塊，比如第三方庫或IndexedDB，根本不足為奇。這些模塊可能對攻擊者更有幫助，因為漏洞可能存在于多個瀏覽器或平臺中。例如，Chromium中的webaudio漏洞CVE-2021-21166也存在于WebKit中，并被修復為CVE-2021-1844，盡管沒有證據表明它在WebKit中被廣泛利用。2021年針對Safari使用的 IndexedDB 野外0-day CVE-2021-30858與2020年1月在 Chromium 中修復的一個漏洞非常非常相似。

Internet Explorer

自從我們開始追蹤野外0-day以來，Internet Explorer每年檢測披露的0-day數字都非常穩定。 盡管Internet Explorer在網絡瀏覽器用戶中的市場份額逐年下降，但事實上，2021年我們追蹤到的Internet Explorer 0-day與2016年是持平的。

那么，為什么盡管市場份額發生了變化，但我們看到的野外0-day的數量變化如此之小呢?因為對于Windows用戶而言，即使用戶不使用Internet Explorer作為其網絡瀏覽器，Internet Explorer仍然可以成為一個受攻擊點。雖然0-day漏洞的數量與我們前幾年看到的大致相當，但攻擊的目標組件和傳輸方法發生了變化。2021年出現的4個0-day中，有3個是針對MSHTML瀏覽器引擎的，并通過web以外的方法傳輸，它們是通過Office文檔或其他文件格式傳輸給目標的。

這4個0-day漏洞針對以下組件：

• MSHTML browser engine (CVE-2021-26411, CVE-2021-33742, CVE-2021-40444)
• Javascript Engine - JScript9 (CVE-2021-34448)

CVE-2021-26411的目標最初會收到一個.mht文件，該文件提示用戶在Internet Explorer中打開。一旦在打開，該漏洞就被下載并運行。CVE-2021-33742和CVE-2021-40444通過惡意Office文檔發送給目標。CVE-2021-26411和CVE-2021-33742是兩種常見的內存損壞漏洞模式:由于在使用對象的兩個操作之間存在用戶控制的回調而導致釋放后使用，以及在回調期間用戶釋放對象，以及緩沖區溢出。

針對CVE-2021-26411目標的活動最初收到了一個.mht文件，該文件提示用戶在Internet Explorer中打開。一旦在Internet Explorer中打開，該漏洞就被下載并運行。CVE-2021-33742和CVE-2021-40444通過惡意Office文檔發送給目標。CVE-2021-26411和CVE-2021-33742是兩種常見的內存損壞bug模式:由于在使用對象的兩個操作之間存在用戶控制的回調而導致釋放后使用，以及在回調期間用戶釋放對象，以及緩沖區溢出。

對于 CVE-2021-26411，該活動的目標最初收到一個 .mht 文件，該文件提示用戶在 Internet Explorer 中打開。 一旦在 Internet Explorer 中打開它，就會下載并運行該漏洞利用程序。 CVE-2021-33742和CVE-2021-40444通過惡意Office文檔傳輸給目標。

CVE-2021-26411和CVE-2021-33742是兩種常見的內存損漏洞模式：由于使用對象的兩個操作之間的用戶控制回調存在use-after-free漏洞，用戶在回調和緩沖區溢出期間釋放該對象。

在CVE-2021-40444 的利用鏈中使用了幾個不同的漏洞，隱匿在MSHTML中的那個一旦打開 Office文檔，就會運行有效負載：下載CAB文件，解壓縮，然后執行該CAB中的DLL函數。 與前兩個MSHTML漏洞不同，這是URL解析中的邏輯錯誤，而不是內存損壞錯誤

Windows

與前幾年相比，Windows是我們看到組件目標變化最大的平臺。然而，這種轉變已經進行了幾年，并預計持續到2020年Windows 7系統壽命到期時，因此我們仍然不認為這是什么新鮮事。

在2021年，有10個Window野外0-day針對7個不同的組件:

• 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)

針對不同組件的數量與過去幾年相比有所不同。 例如，2019 年75%的Windows 0-day漏洞 以Win32k為目標，而在 2021年，這個比例下降至20%。之所以我們能預料到這一點，是因為2019年針對Win32k的8個0-day漏洞中有6個沒有針對當時最新版本的 Windows 10，而是以舊版本為目標。 隨著 Windows 10投入越來越多的資源鎖定Win32k的攻擊面，舊版本的生命周期就慢慢走向衰亡，Win32k也就成為一個越來越沒有吸引力的攻擊面了。

與多年來我們看到的許多Win32k漏洞類似，這兩個2021 Win32k野外0-day漏洞是由于自定義用戶回調造成的。用戶調用在回調期間更改對象狀態的函數，Win32k無法正確處理這些更改。CVE-2021-1732 是一個類型混淆漏洞，由于 xxxClientAllocWindowClassExtraBytes中的用戶回調導致越界讀取和寫入。如果在回調期間調用 NtUserConsoleControl，則會在窗口結構中設置一個標志，以指示該字段是內核堆的偏移量。

xxxClientAllocWindowClassExtraBytes不對此進行檢查，并在不清除標志的情況下將該字段作為用戶模式指針寫入。2022年發現并披露的第一個野外0-day，CVE-2022-21882，是由于CVE-2021-1732實際上沒有完全修復，攻擊者找到了繞過原始補丁的方法，再次觸發了漏洞。

CVE-2021-40449是NtGdiResetDC中的use-after-free漏洞，那是因為對象在用戶回調期間被釋放。

iOS/macOS

正如上文“更多的披露”部分所討論的，2021年，蘋果首次在其發布說明中標注野外漏洞信息, 檢測并披露了5個iOS野外0-day和一個macOS野外0-day(CVE-2021-30869)。在本節中，我們將合并討論iOS和macOS，原因有二：1) 這兩個操作系統包含相似的組件，2) macOS 的樣本容量非常小，僅披露一個漏洞。

5個iOS和macOS野外0-day漏洞瞄準了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個攻擊面并不新穎。 IOMobileFrameBuffer 多年來一直是公共安全研究的對象。 例如，2016年的盤古越獄使用了CVE-2016-4654，這是IOMobileFrameBuffer中的堆緩沖區溢出。 IOMobileFrameBuffer 管理屏幕的幀緩沖區。對于iPhone 11(A13)及更低版本，IOMobileFrameBuffer 是內核驅動程序。從 A14 開始，它在協處理器 DCP 上運行。這是一個流行的攻擊面，因為從歷史上看，它可以從沙盒應用程序中訪問。2021年，IOMobileFrameBuffer 中檢測出2個0-day。 CVE-2021-30807 是越界讀取，CVE-2021-30883 是整數溢出，這兩個都是常見的內存破壞漏洞。2022年，我們在IOMobileFrameBuffe檢測出另一個0-day，CVE-2022-22587。

一個iOS 0-day漏洞和macOS 0-day漏洞都利用了XNU內核中的漏洞，并且這兩個漏洞都存在于與 XNU的進程間通信(IPC)功能有關的代碼中。 CVE-2021-1782 利用了mach vouchers中的漏洞，而 CVE-2021-30869 利用了mach messages中的漏洞。這不是我們第一次看到0-day漏洞，更不用說針對mach vouchers和mach messages的公共安全研究了。 CVE-2019-6625 作為針對 iOS 11.4.1-12.1.2 的利用鏈的一部分被利用，也是mach vouchers中的一個漏洞。

mach messages也一直是公共安全研究的熱門。2020年，mach messages中檢測出2個0-day漏洞：CVE-2020-27932和CVE-2020-2795。今年的CVE-2021-30869與2020年的 CVE-2020-27932 非常相近。事實上，研究人員Tielei Wang和Xinru Chi在2021年4月的zer0Con 2021上已經介紹過這個漏洞，他們解釋說，該漏洞是在對CVE-2020-27932進行變異分析時發現的。TieLei Wang 在Twitter上說，他們在2020年12月發現了這個漏洞，并注意到它已在iOS 14.4和macOS 11.2 的beta版本中得到修復，這也是為什么他們在Zer0Con上展示這個漏洞的原因。這個0-day在野利用僅針對macOS 10，但其利用的技術與本文上述的相同。

兩個FORCEDENTRY 漏洞(CVE-2021-30860 和沙盒逃逸)是今年唯一讓我們驚呼“哇!”的時候。今年，CVE-2021-30860，在CoreGraphics中出現整數溢出，這是因為：

多年來，我們都聽說過攻擊者如何使用“零點擊”iMessage 漏洞，現在我們終于有了一個廣為人知的案列，

這個漏洞的確令人印象深刻。

這個沙盒逃逸(CVE 已請求，尚未分配)令人印象深刻，因為這是我們見過的為數不多的只使用邏輯錯誤而不是標準內存損壞漏洞的沙盒箱逃逸之一。

對于CVE-2021-30860，漏洞本身并不特別引人注目：CoreGraphics PDF解碼器的JBIG2解析器中出現了一個典型的整數溢出。然而，Samuel Gro?和Ian Beer卻將該漏洞描述為“他們見過的技術最復雜的漏洞之一”。 他們的博客分享了所有細節，但重點是該漏洞使用了JBIG2中可用的邏輯運算符來構建自己的計算機體系結構的NAND門。然后，該漏洞利用這個新的自定義架構編寫其剩余的漏洞。他們的博文中，我們可以看到：

“他們使用超過70,000個定義邏輯位操作的段命令，定義了一個具有寄存器、完整64位加法器和比較器等功能的小型計算機架構，用于搜索內存和執行算術運算。雖然它沒有Javascript快，但在計算上基本上是等效的。

沙盒逃逸漏洞的引導操作被編寫為在這個邏輯電路上運行，整個程序運行在這個怪異的模擬環境中，這個模擬環境是通過JBIG2的單個解壓縮通道創建的。這非常不可思議，同時也非常可怕。”

這是一個“讓0-day攻擊變得艱難”的例子，攻擊者必須開發一種新的、獨特的方法來利用漏洞，而這種方法需要大量的專業知識和/或時間來開發。今年，這兩個FORCEDENTRY漏洞是58個0-day漏洞中唯一給我們留下深刻印象的。如今，門檻已經提高，希望在未來任何成功的漏洞都應該這樣做。

Android

今年共檢測并披露了7個 Android野外0-day漏洞。 2021年之前只有1個，是2019年的CVE-2019-2215。 和WebKit一樣，這種缺乏數據的情況讓我們很難評估趨勢和變化。相反取而代之的是，我們會將其與公共安全研究進行比較。

這7個Android 0-day瞄準了以下組件:

• 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個0-day漏洞中，有5個是以GPU驅動程序為目標的。當我們想到Android生態系統的演變以及最近對Android的公共安全研究時，這一點也不令人驚訝。Android的生態系統是相當分散的：許多不同的內核版本、不同的制造商定制，等等。如果攻擊者想要攻擊Android設備，他們通常需要維護許多不同的漏洞才能覆蓋比例相當的Android生態系統。然而，如果攻擊者選擇攻擊GPU內核驅動程序而不是其他組件，他們只需要兩個漏洞，因為大多數Android設備使用2個GPU中的1個：高通Adreno GPU或ARM Mali GPU。

過去幾年的公共安全研究也反映了這一選擇。在針對 Android 設備開發完整的漏洞利用鏈(用于防御目的)時，Guang Gong，Man Yue Mo，和Ben Hawkes都選擇攻擊GPU內核驅動，以實現本地權限升級。看到野外的0-day也針對GPU，這更像是一種確認，而不是一種啟示。在針對 GPU 驅動程序的5個0-day漏洞中，3個針對高通Adreno，2個針對ARM Mali。

兩個非GPU驅動程序0-day漏洞(CVE-2021-0920 和 CVE-2021-1048)針對上游Linux內核。不幸的是，這兩個漏洞與2019年檢測到的Android野外0-day漏洞有一個共同特征：3個漏洞在被Android利用之前都是已知的。雖然樣本量很小，但我們還是很驚訝地發現，所有已知的針對內核的Android 0-day漏洞在被利用之前都是已知的。

現在被稱為CVE-2021-0920的漏洞實際上是在2016年9月發現的，并在Linux內核郵件列表中進行了討論。甚至早在2016年就開發過一個補丁，雖然最終沒有提交。在檢測到針對 Android的野外漏洞利用后，該漏洞最終于2021年7月在Linux內核中得到修復。該補丁隨后于2021年11月進入Android安全公告。

Linux內核打過補丁之后的14個月中，CVE-2021-1048都未及時在Android中打補丁。inux 內核實際上只在幾周內易受這個問題的影響，但由于Android補丁的做法，這幾個星期對一些Android設備來說簡直如同長達一年。如果Android OEM同步到上游內核，那么他們很可能在某個時候針對該漏洞進行了修補。但許多設備，比如最近的三星設備，并沒有這樣做，因此很容易受到攻擊。

Microsoft Exchange Server

2021年，共檢測到5個針對Microsoft Exchange Server的0-day漏洞，這是自我們開始追蹤野外0-day以來，第一次檢測到并披露Exchange Server的野外0-day。前四個(CVE-2021-26855, CVE-2021-26857, CVE-2021-26858和CVE-2021-27065)都在同一次操作中發現的，在公開的第一時間就完成了修補。第五個(CVE-2021-42321)于2021年11月自行修補，隨后CVE-2021-42321在天府杯上展示，然后被微軟在野外發現。盡管CVE-2021-42321的鏈中沒有其他的野外0-day被披露，但由于 CVE-2021-42321是個身份驗證后漏洞，攻擊者至少需要另一個0-day漏洞天才能成功利用它。

上述提到的第一波發現的Exchange野外0-day漏洞中的一個，CVE-2021-26855，也被稱為“ProxyLogon”，是唯一一個預授權的。CVE-2021-26855 是一個服務器端請求偽造(SSRF)漏洞，允許未經身份驗證的攻擊者向Exchange服務器發送任意HTTP請求。其他三個漏洞都是身份驗證后漏洞。例如，CVE-2021-26858和CVE-2021-27065 允許攻擊者將任意文件寫入系統。 CVE-2021-26857 是由于統一消息服務中的反序列化錯誤導致的遠程代碼執行漏洞，它允許攻擊者以特權系統用戶的身份運行代碼。

對于第二波發現的漏洞，CVE-2021-42321，與 CVE-2021-26858 一樣，是由于不安全地反序列化而導致的身份驗證后遠程執行漏洞。 微軟似乎在嘗試強化Exchange時無意中引入了另一個反序列化漏洞。

盡管2021年在Exchange中檢測并披露了大量的0-day漏洞，但我們要記得，它們僅在兩個不同的活動中都被用作0-day攻擊。 從這個列子中，可以看出為什么我們不建議使用產品中的0-day作為評估產品安全性的指標。 要求攻擊者使用四個0-day來獲得成功比攻擊者只需要一個0-day來成功獲得訪問權限更可取。

雖然這是Project Zero項目開始追蹤行動以來首次檢測并披露Exchange野外0-day漏洞，但這并不令人意外，在2020年，Exchange Server 就有被n-day漏洞利用的歷史。無論這是攻擊者開始0-day攻擊的第一年，還是防御者開始檢測 0-day攻擊的第一年，不要對這樣的演變感到意外，而且它很可能持續到2022年。

懸而未決的問題

雖然我們在檢測和披露方面取得了一些進展，但這一進展表明還有多少工作要做。我們獲得的數據越多，關于檢測偏差的問題就越多。

除非攻擊者決定與我們分享他們所有的漏洞利用，我們才能完全知道0-day漏洞公開的比例究竟是多少。因此，進入2022年后，我們給自己整理了一些關鍵問題：

(1) 未知的0-day漏洞在哪兒？

盡管2021年內發現了許多0-day漏洞，但尚未探明0-day漏洞的關鍵目標是什么。 例如，我們知道 WhatsApp、Signal、Telegram信息傳遞應用程序是攻擊者感興趣的目標，但過去一年發現的眾多0-day漏洞中，僅有1個iMessage 0-day是針對信息傳遞應用程序的。即使是2014年開始追蹤行動以來也不過兩個：2019 年的WhatsApp 0-day和2021年的 iMessage 0-day。

除了信息傳遞應用程序之外，我們也希望看看其他平臺是否會成為0-day漏洞的目標，但公開示例卻根本沒有或者少得可憐。例如，自2014年年中以來，macOS 和 Linux各檢測出一個野外0-day漏洞。 目前還沒有已知的針對云端、CPU漏洞或其他手機組件(如WiFi芯片或基帶)的野外0-day漏洞。

這就引發我們的思考：這些0-day漏洞案列的缺失是由于缺乏檢測還是缺乏披露造成的？還是兩者兼而有之？

(2) 有些供應商未公開過0-day漏洞，是因為他們從未發現，還是因為他們不公開披露？

除非供應商公開披露其平臺中所有漏洞的利用狀態，否則我們公眾將不會知道，沒有注釋是否就是意味著沒有已知的漏洞利用，或者漏洞存在，只是供應商沒有公開分享這些信息。 值得慶幸的是，這個問題有了一個非常明確的解決方案：所有設備和軟件供應商都已同意在有證據表明他們的產品中的漏洞被在野利用時公開披露。

(3) 我們看到相同的錯誤模式是因為我們知道如何檢測？

正如我們在本報告前面部分所述，我們在2021年檢測到的所有0-day漏洞都與先前的漏洞有相似之處。這讓我們想知道這是否真的代表了攻擊者正在使用的東西。攻擊者是否真的只是使用先前公開的漏洞和組件中的漏洞就取得成功? 還是說我們檢測所有這些帶有已知錯誤模式的0-day漏洞是因為我們知道如何檢測? 公共安全研究給出了答案，是的，攻擊者在大多數情況下仍然能夠成功利用已知組件與漏洞類型中的漏洞。但我們仍然希望看到一些新奇的、意想不到的漏洞。我們早在2019年的年度回顧中就提出了這個問題，現在這個問題仍然存在。

(4) dspl0itz 在哪里？

要成功利用漏洞，有兩個關鍵組成部分：利用什么漏洞和漏洞的利用方法(如何將該漏洞轉化為有用的東西)。

不幸的是，這份報告只能真正分析其中一個組成部分：什么漏洞。58個0-day漏洞中，只有 5個公開了漏洞的利用示例。在野外發現的0-day漏洞是攻擊者的失敗案例，也是防御者了解攻擊者正在做什么并使其攻擊更難、更耗時、更昂貴的關鍵機會。然而，如果沒有利用樣本或基于樣本的詳細技術文章，我們只能專注于修復漏洞而不是削弱利用的方法。這就意味著攻擊者能夠繼續使用他們現有的利用方法，而不必回到設計和開發階段來構建新的利用方法。雖然不得不承認共享漏洞利用樣本非常具有挑戰性(我們也正面臨這樣的挑戰！)，但我們仍然希望在 2022 年能夠更多地共享漏洞利用樣本或詳細的技術文章，以便我們能夠團結起來，利用每一條可能的信息，防止讓攻擊者更難毒害更多用戶。

總結

回顧2021年， 我們可以看到，在 0-day 漏洞的檢測和披露方面，行業取得了明顯的行業進步，但顯然針對0-day漏洞，行業還有很大的進步空間。作為一個產業，我們還并沒有實現“增加0-day攻擊的難度”的目標。攻擊者僅利用普遍技術就成功實施了攻擊。我們的目標是每當我們檢測到攻擊者的一個漏洞利用時，就能迫使他們從頭開始：他們必須發現一個全新的漏洞，必須投入時間學習和分析新的攻擊面，必須開發一個全新的利用方法。

雖然這一切看起來頗有難度，但我們仍抱有樂觀態度。2019年，我們討論了0-day漏洞利用的巨大檢測缺陷，2年后的今天檢測和披露都增長了一倍多。因此，雖然還有很多工作要做，但這并不難解決。技術和安全行業可以采取一些具體步驟來使其取得更大的進步：

• 將0-day漏洞的披露當做行業的公開標準之一。
• 供應商和安全研究人員共享漏洞利用樣本或漏洞利用技術的詳細描述。
• 繼續共同努力減少內存損壞漏洞或使其無法利用。

到2021年，我們不斷看到對用戶和實體使用的0-day漏洞對現實世界造成的影響。 雖然地球上的大多數人不需要擔心自己被0-day攻擊的個人風險，但0-day攻擊仍然影響著我們每一個人。 這些0-day漏洞往往會對社會產生巨大的影響，因此我們需要繼續盡我們所能，讓攻擊者更難在這些攻擊中取得成功。

2021年向我們展示了我們正走在正確的軌道上并取得進展，但要實現“增加0-day攻擊的難度”這個目標，還有很多工作要做。