鑽石舞台

聚焦源代碼安全，網羅國內外最新資訊！

編譯：代碼衛士

谷歌 Project Zero 團隊回顧了2021年已遭在野利用的58個0day，發布繼2019年和2020年以來的第三份年度報告，窺見未來趨勢、總結經驗教訓。本文是對該文章的編譯。

一、要點概覽：讓0day 難以遁形

我們分析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%）是內存損壞漏洞。內存損壞漏洞已成為過去幾十年以來的軟件攻擊標準，而且攻擊者仍然藉此獲得成功。在這些內存漏洞中，多數是非常熱門和為人熟知的漏洞類型：

Chromium (Chrome)

2021年，檢測和披露的Chromium 0day共14個：

這些組件都是以往常見的攻擊面，如果說有什麼不同的話，那就是 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個：

讓人有點驚奇的是，沒有檢測和披露的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 針對的是如下組件：

Windows

相比以往年份，Windows 組件0day是變化最多的。不過這一情況已存在數年時間，隨着Windows 7 在2020年的壽終正寢，這一情況也在預料之中。2021年，共有10個Windows 0day 針對7個不同組件：

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個攻擊面是：

這4個攻擊面並不新鮮。其中兩個FORCEDENTRY exploit（CVE-2021-30860和沙箱逃逸漏洞）是唯一讓我們「哇塞」的。對於CVE-2021-30860（位於CoreGraphics 中的整數溢出）是因為：

而沙箱逃逸漏洞（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 和相關組件是：

微軟 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，技術和安全行業可採取如下具體措施，取得更多進展：

2021年說明我們走在了正確的道路上並取得了進步，但要讓0day難以遁形，我們還需要做得更多。

推薦閱讀

谷歌緊急修復已遭利用的新 0day

NSO Group 被指利用零點擊 iPhone 0day

谷歌：早在這個0day 補丁發布前幾周，朝鮮國家黑客就已利用

谷歌宣布 Linux Kernel、Kubernetes 0day 漏洞獎勵加倍

谷歌Chrome 緊急修復已遭利用的0day

谷歌：修復0day漏洞的平均耗時比3年前減少28天

微軟4月補丁星期二修復119個漏洞，含2個0day

微軟3月補丁星期二修復71個漏洞，其中3個是0day

原文鏈接

https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html

題圖：Pixabay License

文內圖：谷歌

本文由奇安信編譯，不代表奇安信觀點。轉載請註明「轉自奇安信代碼衛士 https://codesafe.qianxin.com」。

奇安信代碼衛士 (codesafe)

國內首個專注於軟件開發安全的產品線。

覺得不錯，就點個「在看」 或 "贊」 吧~