鑽石舞台

2022年6月，谷歌零日項目團隊 (Project Zero) 研究員 Maddle Stone在近期舉辦的 FIRST 會議上發表了報告《目前為止的2022年在野0day利用》分享了該團隊的對2022年上半年0day利用情況的研究成果。如下是相關內容編譯。

截止到2022年6月15日，我們已經檢測並披露了18個在野利用0day。分析這些0day 時，我們發現至少有9個是之前已修復的漏洞。在2022年上半年已遭利用的0day中，至少有一半本可通過更全面的打補丁和回歸測試得以阻止。另外4個0day 是2021年在野0day的變體。距離原始在野0day被修復12個月之後，攻擊者又帶着原始0day的變體捲土重來。

產品

2022 在野0-day

變體

Windows win32k

CVE-2022-21882

CVE-2021-1732（2021 在野）

iOS IOMobileFrameBuffer

CVE-2022-22587

CVE-2021-30983（2021 在野）

Windows

CVE-2022-30190(「Follina」)

CVE-2021-40444（2021 在野）

Chromium 屬性訪問攔截器

CVE-2022-1096

CVE-2016-5128CVE-2021-30551（2021 在野)CVE-2022-1232(解決不完整的CVE-2022-1096修複方案）

Chromium v8

CVE-2022-1364

CVE-2021-21195

WebKit

CVE-2022-22620(「Zombie」)

最初在2013年修復，後來在2016年退回

Google Pixel

CVE-2021-39793*

* 雖然編號中提到是2021，但該漏洞是在2022年修復並披露的。

不同LInux子系統中的同樣漏洞

Atlassian Confluence

CVE-2022-26134

CVE-2021-26084

Windows

CVE-2022-26925(「PetitPotam」)

CVE-2021-36942（補丁回歸）

0day 並非不可控

那麼這意味着什麼？

提到0day利用，人們通常認為這些利用在技術上非常高階，根本沒有希望捕獲並阻止。但數據展示給我們的確實另一番景象。截至目前，今年至少有一半0day 和此前了解的漏洞密切相關。和在我們發布的2020年漏洞回顧報告中的結論和發現結果非常相似。

2022年很多的在野0day 是因為此前的漏洞未完全修復而造成的。比如 Windows win32k 和 Chromium 屬性訪問攔截漏洞，這些PoC 利用採取的執行流雖然打補丁了，但根因問題並未解決：攻擊者還能通過不同的路徑觸發原始漏洞，捲土重來。再比如 WebKit 和 Windows PetitPotam 問題，雖然原始漏洞已被修復，但在某個點退回了，因此攻擊者可再次利用同樣的漏洞。在 iOS IOMobileFrameBuffer 漏洞案例中，雖然通過檢查大小是否小於某個特定值的方式解決了一個緩衝區溢出漏洞，但並未檢查該大小的最低界限。

檢測到在野0day後，這是攻擊者的失敗案例，但卻是我們防禦人員的禮物，我們可以儘可能多地學習經驗教訓並採取措施，確保該向量無法再被使用。我們的目標是，每當我們檢測到他們的exploit之時就是迫使攻擊者從零開始之時：他們不得不發現全新漏洞，投入時間學習並分析新的攻擊面，必須開發全新的利用方法。要實現這一效果，我們需要正確全面的修複方案。

這樣做並非為了將負責響應漏洞報告的安全團隊所面臨的挑戰最小化。正如我們在2020年的年度回顧報告中提到的那樣，「正確並全面地打補丁並非僅僅是開關開關那樣簡單：它要求投資、優先排序和規劃，還要求開發出的打補丁流程既能快速保護用戶，又能確保補丁是完整全面的，有時候二者是無法平衡的。雖然我們知道組織機構中的安全團隊對此並不驚訝，但本分析提醒我們仍然需要做更多的工作。雖然確切的投資可能取決於每個獨特情境，但我們發現了人員/資源、激勵結構、流程成熟度、自動化/測試、發布節奏和合作夥伴關係之間的共同主題。」

四大分析工作

在實踐方面，可採取如下措施確保所有漏洞得到正確、全面的修復。零日項目團隊計劃繼續採取如下措施，但希望並提倡平台安全團隊和其它獨立安全研究員也能夠投入此類分析工作中：

了解正被利用的底層漏洞。同時嘗試了解該漏洞是如何被引入的。執行根因分析有助於確保修複方案正在修復該底層漏洞而不僅僅是破解PoC。根因分析通常是變體和補丁分析取得成功的一個前提條件。

查找和所報告漏洞類似的其它漏洞。這項工作涉及查看別處同樣的漏洞模式、更加全面地審計包含該漏洞的組件、修改模糊測試工具以了解這些工具之前為何未發現該漏洞等。多數研究人員一次會發現一個以上的漏洞。通過查找並修復相關變體，攻擊者就無法在修復原始漏洞的情況下，僅憑「即插即用」的方式利用新漏洞。

分析與根因漏洞相比，所提出的（或發布的）補丁的完整性。廠商應該提早和漏洞發現者分享修復漏洞的計劃，以便在廠商自身的內部分析的同時，發現人員能夠分析補丁能否解決漏洞根因。

了解從漏洞中獲取的原語以及遭利用的方式。雖然目前的行業標準是修復漏洞，但緩解利用技術並不常常發生。雖然並非每種利用技術都可得到緩解，但希望它將成為默認行為而非例外行為。應當及時分享利用樣本，以便廠商和安全研究員能夠執行利用技術分析。

以透明的方式共享這些分析也有助於提升整個行業水平。我們提倡廠商和其他人也公開自己的分析結果。這有助於開發人員和安全專業人員更好地了解攻擊者已經知曉的漏洞情況，希望以此推動更好的解決方案和安全性。

谷歌的分析研究報告可見：https://googleprojectzero.github.io/0days-in-the-wild/rca.html。

題圖：Pixabay License‍

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

奇安信代碼衛士 (codesafe)

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

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