作者：Maddie Stone@Google Project Zero
譯者：知道創宇404實驗室翻譯組
原文鏈接：https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html

這是我們回顧在野利用 0day 漏洞的第三個年度 [2020 年，2019 年]。每年我們都會回顧所有檢測到和披露的在野 0day，并綜合分析其趨勢和要點。本報告旨在整體分析年度漏洞利用，尋找趨勢、差距，總結經驗教訓等等。如果你對單個漏洞利用感興趣，可以查看我們的分析。

我們發布這篇分析報告是希望 0day 漏洞利用變得更有難度，希望攻擊者使用 0day 所花費的成本和資源更高。2021 年的趨勢也更強調了這一點如此重要。我們一遍又一遍地聽到各國政府如何將記者、少數群體、政客、人權捍衛者，甚至是世界各地的安全研究人員作為目標。我們切身體會到，在安全和技術社區做出的決定會對社會和人類的生活產生真正的影響。

本文正文中將會提供我們分析結論的證據和過程，總結下一步的想法和對 2022 年的希望。

摘要

2021 年共檢測和披露的在野 0day 漏洞有 58 個，這是自從 2014 年年中 Project Zero 團隊開始跟蹤以來記錄到最多的一年，是之前的最高值——2015 年檢測到 28 個的兩倍多，2020 年我們僅檢測到 25 個。自 2014 年年中以來，我們一直在此表格中跟蹤公開的在野利用 0day 漏洞。

雖然我們經常談論在野利用的 0day 漏洞數量， 但我們實際上討論的是在野檢測到和披露的 0day 漏洞利用數量。這也是我們的第一個結論：2021 年在野 0day 漏洞的大幅上升是由于檢測和披露的增加，而不是簡單的 0day 漏洞利用的增加。

通過對這些在野 0day 的分析，我們發現攻擊者的方法實際上與前幾年相比并沒有太大變化，他們成功地使用了相同的模式和技術，并針對相同的攻擊面。Project Zero 團隊的使命是“讓利用 0day 變得更難”。總的來說，當攻擊者無法使用公開的方法和技術來開發利用時，0day 的利用才將更加困難。而 2021 年這 58 個 0day，與以前公開已知的漏洞都很相似，只有兩個 0day 脫穎而出：一個是因為其漏洞利用的技術復雜性，另一個是因為它使用邏輯錯誤來逃離沙箱。

因此，雖然我們認識到業界在檢測和披露在野 0day 漏洞數量方面取得了進步，但我們也承認還有很多改進工作要做。 攻擊者利用 0day 的事實表明了，他們能夠使用先前已知的技術和方法取得成功，而不必投入開發新的技術，這對科技行業來說也是一個機會。

我們在 2021 年擁有比過去更多的數據點來了解攻擊者的行為，然而，這些數據也給我們留下了更多的問題。攻擊者不會分享他們正在使用的 0day，以及我們在調查中遺漏了多少 0day，因此我們永遠無法確切知道這些公開披露的 0day 所占比例是多少。

根據我們對 2021 年 0day 的分析，我們希望在 2022 年看到以下進展，以繼續采取措施使 0day利用變得更有難度：

  1. 所有廠商都同意在其安全公告中披露漏洞的在野利用狀態；
  2. 漏洞利用示例或漏洞利用的詳細技術描述可以更廣泛的共享；
  3. 繼續共同努力減少內存損壞漏洞，或者使其無法被利用。啟動一些緩解措施來影響內存損壞漏洞的利用。

在野 0day 漏洞破紀錄的一年

2021 年是在野 0day 漏洞數量創紀錄的一年。到底發生了什么呢？

是軟件安全性越來越差？還是攻擊者更多地使用了 0day 漏洞？還是我們發現和披露 0day 的能力有所提高？從 2020 年到 2021 年的顯著增長，我們認為這主要是由于后者。雖然我們認為過去幾年攻擊者對 0day 利用的興趣和投入一直在穩步增長，而且軟件安全性也仍需迫切提高，但似乎最主要的原因還是安全行業檢測和披露 0day 漏洞的能力提升了。

雖然我們經常談論“在野利用的 0day 漏洞”，但我們實際調查的是“檢測到并披露的在野利用 0day 漏洞”。除了利用之外，還有更多因素導致該數量的增加，最值得注意的是：檢測和披露。更好地檢測 0day 漏洞和更透明地披露被利用的 0day 漏洞是行業安全和進步的一項積極指標。

總而言之，我們可以將在野 0day 數量的提升分解為：

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

更多檢測

在 2019 年的回顧中，我們寫了關于“檢測赤字”——“作為一個社區，我們嚴重缺乏檢測在野利用 0day 的能力，以至于收集數據的缺乏和偏差，使我們無法得出有意義的結論。” 在過去的兩年里，我們相信這方面已經取得了進展。

我們聽說有更多人已經開始致力于檢測 0day 漏洞。從數量上看，雖然是一個非常粗略的衡量標準，但我們也看到報告的在野 0day 數量正在增加。所以有理由認為，如果努力尋找 0day 漏洞利用的人數增加，那么檢測到的在野 0day 漏洞數量可能會增加。

我們還看到在自己產品中檢測到在野 0day 漏洞的廠商數量也在增加，無論這些廠商之前是否檢測，在 2021 年他們似乎找到了更成功的方法。廠商對他們自身產品有擁有更多的遙測技術和全面的知識，因此他們投資檢測針對自己產品的 0day。如上圖所示，廠商在自家產品中發現的在野 0day 數量顯著增加。谷歌在他們自己的產品中發現了 7 個 0day，而微軟在他們的產品中發現了 10 個！

更多披露

在野 0day 漏洞數量增加的第二個原因就是由于有了更多地披露。 Apple 和 Google Android（這里把“Google”和“Google Android”區分開，是因為 Google Chrome 在過去幾年一直安全公告中有添加注釋） 首先分別在 2020 年 11 月和 2021 年 1 月開始在其安全公告中使用有關潛在野外利用的信息來標記漏洞。當廠商不在發布公告中添加注釋時，我們了解 0day 被瘋狂利用的唯一方法是發現該利用的研究人員站出來說明。如果 Apple 和 Google Android 之前沒有注釋他們的漏洞發布公告，公眾可能不會知道至少有 7 個 Apple 的在野 0day 漏洞和 5 個 Android 的在野 0day 漏洞。為什么？因為這些漏洞是由“匿名人士”報道的，如果他們不想因為發現漏洞而受到贊揚，他們就不太可能公開說這些漏洞有被利用的跡象。 如果 Apple 和 Google Android 沒有透明化地注釋它們的安全公告，那么就有 12 個 0day 就不會被列入今年的漏洞列表。

向 Microsoft、Google Chrome 和 Adobe 致敬并感謝他們多年來一直在為其安全公告添加注釋以提高漏洞狀態透明化。還要感謝 Apache 在 過去一年中還為CVE-2021-41773 的公告添加了注釋。

高通和 ARM 產品中的在野 0day 在 Android 安全公告中被注釋為在野，但在廠商自己的安全公告中卻沒有。

很有可能在 2021 年，還有其他 0day 在野利用并被檢測到，但廠商在其公告中并未提及這一點。在 2022 年，我們希望更多廠商在修補已被廣泛利用的漏洞時注意這一點。在我們確信所有廠商都在透明地披露在野利用狀態之前，還有一個大的問題：到底有多少個在野 0day 被發現了，但沒有被廠商公開標注。

新的一年，不變的技術

在 2021 年我們擁有破紀錄數量的數據點，以了解攻擊者如何實際利用 0day 漏洞。不過，讓人有點驚訝的是，在所有這些數據點中，這些數據中并沒有什么新東西。0day 漏洞被認為是攻擊者可以使用的最先進的攻擊方法之一，因此我們很容易從中總結出攻擊者使用的特殊技巧和攻擊面。但相反，我們在 2021 年發現的 0day 基本上遵循之前在公開研究中出現的相同模式、攻擊面和利用方法。一旦“利用 0day 很困難”，攻擊者要想成功就必須使用前所未有的利用方法，以及在新的攻擊面中找到新的漏洞。總體來說，這一年的數據并沒有展現出這一點。在 58 個 0day 中，除了兩個例外（在下面的 iOS 部分中描述），我們看到的一切都非常標準。

在這一年中的 58 個在野 0day 中，有 39 個也就是 67% 是內存損壞漏洞。在過去的幾十年里，內存損壞漏洞一直是攻擊軟件的標準，并且仍然是攻擊者取得成功的方式。在這些內存損壞漏洞中，大多數還停留在非常普遍和眾所周知的漏洞類型：

  • 17 個釋放后重用漏洞
  • 6 個越界讀寫漏洞
  • 4 個緩沖區溢出漏洞
  • 4 個整數溢出漏洞

接下來，我們將深入探討今年每個主流平臺的在野 0day漏洞。分享漏洞利用的趨勢，以及解釋為什么我們所看到的非常普通。

Chromium (Chrome)

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

14 個 0day 漏洞位于以下組件中：

當我們查看這些漏洞所針對的組件時，它們都是在以前公開的安全研究和漏洞利用中看到過的攻擊面。如果有不同的話，與以前相比，DOM 的漏洞少了一些，而針對瀏覽器的這些其他組件（如 IndexedDB 和 WebGL）則更多。14 個 Chromium 0day 中有 13 個是內存損壞漏洞。與去年類似，這些內存損壞漏洞中的大多數都是釋放后重用漏洞。

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

CVE-2021-30632 是 2021 年的另一個 Chromium 在野 0day。這是 Chromium 的 JavaScript 引擎 v8 中 TurboFan JIT 中的類型混淆，在修改屬性映射后，TurboFan不能對代碼進行反優化。CVE-2021-30632 特別處理存儲全局屬性的代碼。CVE-2020-16009 也是一個在野 0day，原因是在地圖棄用后，Turbofan未能對代碼進行反優化。

WebKit (Safari)

在 2021 年之前，Apple 只承認了 1 個針對 WebKit/Safari 的公開已知的在野 0day，是由外部研究人員的貢獻。在 2021 年這個數量達 7 個。因為沒有歷史樣本可供參考，我們很難評估這其中的趨勢或變化。所以，我們在其他未知的 Safari 漏洞和其他瀏覽器 0day 漏洞的背景下來看 2021 年的 WebKit 漏洞。

7 個在野 0day 分別針對以下組件：

有點驚喜是沒有發現和披露 DOM 錯誤。在前幾年，DOM 引擎中的漏洞通常占瀏覽器 0day 的 15-20%，但 2021 年 WebKit 沒有檢測到和披露這類。

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

Internet Explorer

自從我們開始調查在野 0day 以來，Internet Explorer 每年的 0day 數量一直非常穩定。盡管 Internet Explorer 在瀏覽器用戶中的市場份額持續下降，但 2021 年實際上與 2016 年我們所追溯的在野 0day 數量齊平。

盡管市場份額發生了變化，為什么我們看到的在野 0day 數量變化如此之小呢？即使用戶不使用 Internet Explorer 作為其瀏覽器，Internet Explorer 仍然是初始進入 Windows 機器的成熟攻擊面。雖然 0day 數量與我們在前幾年看到的基本一致，但攻擊的目標組件和發送方式發生了變化。2021 年出現的 4 個 0day 中有 3 個針對 MSHTML 瀏覽器引擎，并且是通過 Office 文檔或其他文件格式發送給目標的。

4個 0day 分別針對以下組件：

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

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

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

Windows

與往年相比，Windows 是我們看到目標組件變化最大的平臺。然而，這種轉變通常已經進行了幾年，并預測到 2020 年 Windows 7 的生命周期結束，因此它不是特別新穎。

2021 年有 10 個 Windows 在野 0day 針對 7 個不同的組件：

不同的目標組件的數量與過去幾年相比有所不同。例如，2019 年 75% 的 Windows 0day 以 Win32k 為目標，而在 2021 年 Win32k 僅占 Windows 0day 的 20%。之所以能預料到這一點，是因為 2019 年針對 Win32k 的 8 個 0day 中有 6 個沒有針對當時最新版本的 Windows 10，而是舊版本。隨著 Windows 10 開始投入越來越多的資源來減少 Win32k 的攻擊面，因此隨著那些舊版本的生命周期結束，Win32k 越來越沒有吸引力。

與多年來看到的許多 Win32k 漏洞類似，兩個 2021 年的 Win32k 在野 0day 是由于用戶自定義回調造成的。用戶調用在回調期間更改對象狀態的函數，而 Win32k 無法正確處理這些更改。CVE-2021-1732 是一個類型混淆漏洞，由于xxxClientAllocWindowClassExtraBytes 中的用戶回調導致越界讀寫。如果在回調期間調用了NtUserConsoleControl，則會在窗口結構中設置一個標志，表明字段是內核堆中的偏移量。xxxClientAllocWindowClassExtraBytes不檢查這個，并在不清除標志的情況下將該字段作為用戶模式指針寫入。在2022年檢測和披露的第一個在野 0day，CVE-2022-21882，是由于 CVE-2021-1732 實際上沒有完全修復。攻擊者找到了繞過原始補丁觸發漏洞的方法。CVE-2021-40449 是NtGdiResetDC中的一個釋放后重用漏洞，因為在用戶回調期間對象被釋放。

iOS/macOS

正如上面“更多披露”部分所討論的，2021 年是 Apple 第一次在其漏洞公告中完整注釋其漏洞狀態。今年檢測并披露了 5 個 iOS 在野 0day。還發現了第一個公開的 macOS 在野 0day(CVE-2021-30869)。在本節中，我們將把 iOS 和 macOS一同討論，因為這兩個操作系統包含相似的組件，以及 macOS 的樣本量非常小。

對于總共 5 個 iOS 和 macOS 在野 0day ，他們針對 3 個不同的攻擊面：

這 4 個攻擊面并不新穎。IOMobileFrameBuffer 多年來一直是安全研究的目標。例如，2016 年盤古越獄使用了 CVE-2016-4654，這是 IOMobileFrameBuffer 中的堆緩沖區溢出漏洞。IOMobileFrameBuffer 管理屏幕的幀緩沖區，對于 iPhone 11 (A13) 及更低版本，IOMobileFrameBuffer 是內核驅動程序。從 A14 開始，它在協處理器 DCP 上運行。這是一個受歡迎的攻擊面，因為從歷史上看，它可以從沙盒應用訪問。2021 年，IOMobileFrameBuffer 中有兩個在野 0day。CVE-2021-30807 是越界讀取漏洞，CVE-2021-30883 是整數溢出漏洞，都是常見的內存損壞漏洞。2022 年，我們檢測到 IOMobileFrameBuffer 中另一個在野 0day，CVE-2022-22587。

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

Mach 消息也一直是安全研究的熱門目標。在 2020 年，mach 消息中也有兩個在野 0day：CVE-2020-27932 和CVE-2020-27950。今年的 CVE-2021-30869 與 2020 年的 CVE-2020-27932 非常接近。 Tielei Wang 和 Xinru Chi 實際上在 2021 年 4 月的 Zer0con 2021 上介紹了這個漏洞。他們說在對 CVE-2020-27932 進行變體分析時發現了這個漏洞。Tielei Wang 在推特解釋他們在 2020 年 12 月發現了該漏洞，并注意到它已在 iOS 14.4 和 macOS 11.2 的 beta 版本中得到修復，這就是他們在 Zer0Con 上展示它的原因。在野利用僅針對 macOS 10，但使用了與所介紹相同的利用技術。

兩個 FORCEDENTRY（CVE-2021-30860 和沙盒逃逸）漏洞是今年我們都眼前一亮的漏洞 。因為CVE-2021-30860，CoreGraphics 中的整數溢出漏洞：

  1. 多年來我們都聽說過攻擊者如何使用 0-click iMessage 漏洞，終于我們有了一個公開的例子；
  2. 該漏洞利用十分令人印象深刻。

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

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

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

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

這是使 0day 漏洞利用變得困難的一個例子 ： 攻擊者必須開發一種新穎的方法來利用漏洞，而這種方法需要大量的專業知識或者時間來開發。 今年，兩個 FORCEDENTRY 漏洞是 58 個 0day 中唯一給我們留下深刻印象的。希望在未來，任何成功的漏洞利用都需要像這樣。

Android

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

對于 7 個 Android 0day，他們針對以下組件：

2021 年的 7 個 0day 中有 5 個針對 GPU 驅動程序。 考慮到 Android 生態系統的演變以及最近對 Android 的公共安全研究，這實際上并不令人驚訝。Android 生態系統相當分散：許多不同的內核版本、不同的制造商定制等等。如果攻擊者想要針對“Android 設備”，他們通常需要維護許多不同的漏洞，才能覆蓋相當大比例的 Android 生態系統。但是，如果攻擊者選擇針對 GPU 內核驅動程序，他們將只需要兩個漏洞，因為大多數 Android 設備使用 2 個 GPU 中的一個：Qualcomm Adreno GPU 或 ARM Mali GPU。

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

兩個非 GPU 驅動程序 0day（CVE-2021-0920 和CVE-2021-1048）針對 Linux 內核。不幸的是，這 2 個漏洞與 2019 年出現的 Android 在野 0day 具有一個共同特征：3 個漏洞在 Android 被利用之前之前是已知的。盡管樣本量很小，我們還是驚訝地發現所有已知針對內核的 Android 0day 都是在被利用之前實際上就已知的。

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

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

Microsoft Exchange Server

2021 年，有 5 個針對 Microsoft Exchange Server 的在野 0day。這是我們開始跟蹤在野 0day 以來第一次檢測和披露 Exchange Server 的漏洞。前4個（CVE-2021-26855、CVE-2021-26857、CVE-2021-26858和CVE-2021-27065）都同時披露和修補，并且在一次操作中一起使用。第5個 ( CVE-2021-42321 ) 于 2021 年 11 月自行修補，這個漏洞在天府杯上展示，然后被微軟在野發現。攻擊者至少需要另一個 0day 才能成功利用這個漏洞，因為它是一個身份驗證后漏洞。目前沒有發現其它 0day 和 CVE-2021-42321 作為一個利用鏈所使用。

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

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

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

雖然這是 Project Zero 團隊首次檢測和披露 Exchange 在野 0day，但這并不意外。2020 年Exchange Server 被利用了 nday。無論這是攻擊者開始 0day 漏洞利用的第一年，還是防御者開始檢測 0day 漏洞利用的第一年，這都不是一個意外的變化，很可能會持續到 2022 年。

突出的問題

盡管在檢測和披露方面取得了進展，但這也表明還有很多工作要做。我們獲得的數據越多，關于檢測偏差的問題就越多，我們遺漏了什么以及為什么，以及廠商和研究人員都需要提高透明度。

除非攻擊者決定與我們分享他們所有的漏洞利用，否則我們不能完全知道有多少 0day 是公開的。然而，當我們把作為安全研究人員的專業知識和業內其他人的見聞結合起來時，它描繪出了一些我們很可能缺失的數據。因此，進入2022年，我們會問自己一些關鍵問題：

未知的 0day 在哪里？

盡管 2021 年發現了許多 0day，但發現的 0day 中仍然缺少關鍵目標。例如，我們知道 WhatsApp、Signal、Telegram 等即時通訊應用是攻擊者感興趣的目標，但只有 1 個即時通訊應用 iMessage，在過去一年中發現了 0day。自從我們在 2014 年年中開始跟蹤以來，總共有2個：2019 年的 WhatsApp 0day 和 2021 年發現的 iMessage 0day。

除了即時通訊應用之外，還有其他平臺/目標我們希望看到 0day，但沒有或很少有公開示例。例如，自 2014 年年中以來，macOS 和 Linux 各只有一個在野 0day。目前沒有已知的針對云、CPU 漏洞或其他手機組件（如 WiFi 芯片或基帶）的在野 0day。

這就引出了這樣一個問題：這些 0day 的缺乏是由于沒有檢測到、沒有披露，還是兩者兼而有之？

一些廠商沒有公開的 0day，是因為從未發現，還是因為不公開披露？

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

我們看到相同的漏洞模式是否是因為這是我們知道如何檢測的？

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

spl0itz 在哪里？

要成功利用漏洞，有兩個關鍵部分：被利用的漏洞和利用方法（如何將該漏洞轉化為有用的東西）。

但是這份報告只能真正分析其中一個組成部分：漏洞。在 58 個 0day 中，只有 5 個公開了漏洞利用示例。在野發現的 0day 是攻擊者的失敗案例，也是防御者了解攻擊者正在做什么的關鍵機會，并以此使其更難、更耗時、更昂貴。然而，如果沒有利用樣本或基于樣本的詳細技術文章，我們只能專注于修復漏洞而不是減輕利用方法的影響。這意味著攻擊者能夠繼續使用他們現有的利用方法，而不必構建新的利用方法。雖然我們承認共享漏洞利用樣本可能具有挑戰性（我們也面臨這樣的挑戰！），但我們仍希望在2022年將會有更多共享漏洞利用示例或詳細的技術文章，以便我們可以使用一切可能的信息，使攻擊者更難利用更多用戶。

順便說一句，如果您愿意與我們分享漏洞利用示例，請與我們聯系。無論是與我們分享，讓我們撰寫詳細的技術描述和分析，還是讓我們公開分享，我們都很樂意合作。

結論

回首 2021 年，我腦海里浮現的是“嬰兒階段”。我們可以看到在 0day 漏洞的檢測和披露方面，行業有明顯的進步。但更好的檢測和披露也突出了其他進步的機會。作為一個行業，我們并沒有讓 0day 利用變得更加困難。攻擊者利用與我們之前看到的類似的漏洞，以及之前被討論為攻擊面的組件中的漏洞取得了成功。我們的目標是每次我們檢測到攻擊者的一個漏洞時都迫使攻擊者從頭開始：他們被迫發現一個全新的漏洞，他們必須投入時間學習和分析新的攻擊面，他們必須開發一種全新的利用方法。雖然我們在檢測和披露方面取得了顯著進展，但它向我們展示了可以繼續改進的領域。

雖然這一切令人望而生畏，但有希望的是我們以前就這樣做過：我們在以前令人生畏的目標上取得了明顯的進展。2019 年，我們討論了 0day 漏洞的巨大檢測缺陷，2 年后發現并披露了超過兩倍的漏洞。因此，雖然還有很多工作要做，但這是一個容易解決的問題。科技和安全行業可以采取一些具體措施來取得更大進展：

  1. 當有證據表明產品中的漏洞正在被利用時，讓所有廠商公開披露成為行業標準行為；
  2. 廠商和安全研究人員共享漏洞利用樣本或漏洞利用技術的詳細描述；
  3. 繼續共同努力減少內存損壞漏洞或使其無法利用。

到 2021 年，我們不斷看到對用戶和實體使用 0day 漏洞對現實世界的影響。國際特赦組織、公民實驗室和其他機構一再強調，政府如何使用商業監控產品來對付記者、人權捍衛者和政府官員。我們看到許多企業都在爭先恐后地修復和保護自己免受 Exchange Server 0day 的影響。我們甚至了解到同行安全研究人員已成為朝鮮政府黑客的目標，雖然地球上的大多數人不需要擔心自己被 0day 攻擊的風險，但 0day 攻擊仍然影響著我們所有人。這些 0day 往往會對社會產生巨大的影響，因此我們需要繼續盡我們所能，讓攻擊者更難在這些攻擊中取得成功。

2021 年表明我們正走在正確的軌道上并取得了進展，但要讓 0day 利用變得艱難，我們還有很多工作要做。

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.jmbmsq.com/1886/