2021年即將過去。這似乎是一個沒有什么存在感的年份。 這一年里，我們經歷了2020歐洲杯，2020奧運會，整體感覺是把2020年重新過了一遍。但CVE編號還是不斷提醒我，這是2021年了。而且，在漏洞攻擊領域這是極為精彩的一年。
本文簡單總結一下我心目中的2021年十大漏洞利用，重點考慮漏洞的影響范圍和利用技術的創新度。因所知有限，我僅在我所能了解的領域做些總結，屬于個人學習筆記。排名不代表先后。很多破解大賽上的精彩利用沒能納入表單，實屬本人沒來得及仔細分析。大家如果認同表單，說明我們有共識；如果不認同，說明技術世界很精彩，都是值得慶賀的事情。
江湖上一直傳聞NSO有iMessage 0Click遠程代碼執行的利用，但沒人能想象是如何做到的。2019年，Google Project 0曾在iOS 12上利用 NSKeyedUnarchiver反序列漏洞重現過iMessage 的0Click攻擊[1]。進入iOS 14時代后，Apple在iMessage數據處理鏈路上做了很多安全改進，包括引入重沙盒環境的BlastDoor服務處理不可信數據、不惜性能成本引入Dyld Shared Cache重新隨機化機制等[2]。這使得iMessage 0Click攻擊更加神龍見首不見尾。幸運的是，Project 0近期公開了針對iOS 14 iMessage攻擊樣本的分析報告，揭示了部分細節[3]。攻擊是通過iMessage發送一個GIF圖片實現的。而這個GIF圖片，實際是一個畸形PDF文件。
漏洞發生在PDF文件解析過程，是一個平淡無奇的整數溢出導致的堆溢出。這個堆溢出的品相“看似”也一般，溢出時只能把對象指針越界寫到臨近內存。就是這么一個平淡無奇的漏洞，攻擊者在JBIG2格式環境下構造了的精彩絕倫的利用過程。
? 首先，通過精細堆布局，使整數溢出轉化為一個堆溢出，用JBIG2Bitmap對象指針覆蓋原本的JBIG2Segment對象指針；此次覆蓋非常重要，既能利用JBIG2Bitmap和JBIG2Segment的類型繼承關系避免基于PAC(Pointer Authentication Code)的虛函數調用保護，又能及時截斷溢出，避免過內存過度破壞造成崩潰。
? 溢出真正破壞的對象則是JBIG2Bitmap對象自身。JBIG2Bitmap對象中，使用32位整數表示Bitmap的長、寬等維度信息。溢出發生時，一個64位的JBIG2Bitmap指針，剛好會覆蓋到JBIG2Bitmap對象的長、寬字段。iOS用戶態指針基本是0x1xxxxxxxx形態，即高32位是1，低32位介于0x100000 and 0xffffffff之間。覆蓋后，JBIG2Bitmap對象中的高度被指針的低32位覆蓋，寬度被寫成0x1。雖然不能精確控制高度，但是可以肯定的是，這個“高度”遠超過JBIG2Bitmap本身的數據內存的長度。
? 后續使用這個被破壞JBIG2Bitmap時，就造成了一個越界寫。通過這個受限的越界寫，替換JBIG2Bitmap中的數據內存指針，就構造了一個真正的無邊界Bitmap。
至此，我們已經可以領略到這個利用過程中堆布局的精細和巧妙。盡管如此，很多利用開發高手都可能實現這個任意讀寫能力。然而，雖然具備了任意讀寫，在無交互、無腳本執行的環境下，如何驅動這個任意讀寫能力，是制約漏洞利用的最大障礙。
這個利用接下來的操作就如同天外飛仙了。利用基于JBIG2 中的段命令實現與/或/非/異或等邏輯門操作，使用70,000多個段命令定義了自己的虛擬計算架構！該虛擬計算架構，有其虛擬寄存器，并且實現了64位的加法、比較操作；這意味著圖靈完備的計算能力。
這個PDF解析是在IMTranscoderAgent進程中完成的。Project 0也將繼續分享攻擊如何進一步逃逸IMTranscoderAgent沙盒的，相信也十分精彩。還有一個很容易被忽視的細節，這個PDF解析的代碼不是Apple自己開發的，而是使用了Xpdf的開源代碼。那么問題來了，Xpdf里是否修復了這個漏洞？其他使用了Xpdf代碼的產品是否修復了這個漏洞？對于其他受影響的產品，是否還需要如此復雜的攻擊過程？
【參考資料】
1.https://googleprojectzero.blogspot.com/2020/01/remote-iphone-exploitation-part-1.html
2.https://googleprojectzero.blogspot.com/2021/01/a-look-at-imessage-in-ios-14.html
3.https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html
時間撥回2016年。那一年的黑帽大會(Blackhat USA)上，來自Fortify的兩個安全研究員Alvaro和Oleksandr做了題為《A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land》的報告[1]。報告詳細介紹了JNDI/LDAP注入的原理、危害和攻擊手段。時間再撥到2013年，有人向Log4j2開源社區提交支持JNDI Lookup 插件的請求并被采納[2]。就這樣，一個2013年就存在的洞，2016年就本應該被發現的問題，在2021年爆發了[3]。如果用一個詞描述這個漏洞利用，我覺得“大道至簡”比較合適。相比于漏洞利用，漏洞披露過程和場外聲音更“嘈雜”，影響更廣泛。
【參考資料】
1.https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
2. https://issues.apache.org/jira/browse/LOG4J2-313
3. https://logging.apache.org/log4j/2.x/security.html
毫無疑問，新冠疫情帶來了Zoom的崛起。2021年4月份舉辦的Pwn2own破解大賽上，Zoom的遠程0click項目獎金高達20萬美金 [1]。Thijs Alkemade 和 Daan Keuper兩人聯手成功贏下了該項目并公開了技術細節[2]。
通常而言，通信類軟件的0Click攻擊難度系數大，主要是因為暴露給0Click的攻擊面非常小。如何尋找和擴大攻擊面是漏洞挖掘和利用開發的重點。而且由于現在操作系統平臺上，普遍開啟了地址隨機化等防護機制，能否遠程內存布局和泄漏從而繞過地址隨機化成為重要障礙。
這次的0Click攻擊，起源于一個堆溢出漏洞。攻擊者仔細研究了Zoom通信協議后，掌握了遠程堆布局的途徑，然后利用Zoom的邏輯問題，直接和目標Zoom建立HTTPS通信；在TLS 握手過程中，利用堆溢出在目標Zoom內存中，覆蓋URL請求里的0截止符(zero-terminator)；因為目標Zoom發送URL請求時，是根據0截止符判斷URL的結束，而原本的0截止符被覆蓋，導致目標Zoom會泄漏額外的非零數據，實現了遠程的信息泄漏。在信息泄漏和遠程堆布局的能力基礎上，攻擊者很容易再次溢出覆蓋vtable或者函數指針等方式，利用ROP技巧實現任意代碼執行。
回到堆溢出漏洞本身，漏洞根源在于，使用橢圓曲線的Diffie-Hellman密鑰交換過程中，假定密鑰長度不會超過1024；而一旦攻擊者提供的密鑰超過1024字節，就會造成堆溢出。無獨有偶，Project Zero在Network Security Services (NSS) 密碼庫中也發現了一個內存溢出（CVE-2021-43527），原因是NSS處理ASN.1 數字 signature字段時，默認簽名不會超過2048字節[3]。NSS是一個被廣泛使用的密碼庫。如果不是因為Log4j2的漏洞，現在安全圈可能還在排查CVE-2021-43527的影響范圍[4]。再聯想到心臟滴血漏洞，密碼庫代碼實現問題依然嚴峻。
【參考資料】
1.https://www.zerodayinitiative.com/advisories/ZDI-21-971/
2. https://sector7.computest.nl/post/2021-08-zoom/
3.https://bugs.chromium.org/p/project-zero/issues/detail?id=2237
4.https://googleprojectzero.blogspot.com/2021/12/this-shouldnt-have-happened.html
有句戲言，“iOS完美越獄”比大熊貓還少。就這樣，Fugu14 iOS 完美越獄發布了，還是開源的[1]。如果用一個詞形容Fugu14里用到的漏洞，我會選擇“優雅”。
? 首先來看用戶態。為了加速App啟動，iOS上啟用了一個新的機制叫做“dyld closure”。App第一次啟動后，系統會把這個App、dyld和動態庫等資源鏈接好后存入一個名為.closure的緩存文件。這個Closure類似于App的運行時快照。App再次運行時，無需從新創建內存環境，而是加載這個Closure即可。但是這個closure文件的保存、加載和驗證過程，都存在邏輯不足。Fugu14利用了這些特性，把普通App的Closure做了修改，將Closure中的主進程文件替換成了系統應用Spotlight，并修改了Closure的加載規則，從而獲得了在Spotlight進程中的代碼執行能力。Fugu14之所以選擇Spotlight，是因為這個系統應用沒有沙盒約束。
? 接下來看內核漏洞。在強大的用戶態代碼執行能力的基礎上，Fugu14利用DriverKit的一個邏輯漏洞：創建一個IOUserClient，但是不去設置task成員；當task為0時，IOMemoryDescriptor::withAddressRanges直接操作物理內存地址。簡單的說，Fugu14攻擊內核時，直接獲取了任意物理地址的讀寫能力。iOS 14實際上做了大量的針對虛擬內存管理的安全改進，但是這些面向虛擬地址的安全機制在任意物理地址讀寫能力面前全部失效。
? 簡單的說一下PAC bypass。強如任意物理地址讀寫也并不能在iOS內核空間直接實現任意代碼執行。基于ARM V8.3架構的PAC特性，iOS內核具備強大的控制流完整性保護。Fugu14在任意內存讀寫能力基礎上，把內核正常接口thread_set_state轉化成了一個簽名gadget，從而達到劫持控制流的效果。這個PAC bypass技巧和我們的繞過技巧基本一致，下筆之時還在心痛。
? 最后看PPL繞過。這是整個攻擊鏈條中最驚艷的一個環節。PPL是Apple在iOS上實現的一個基于硬件的物理內存頁面保護機制[2]。簡單的說，Apple基于定制化寄存器，確保只有PPL Text段代碼才能修改特定物理頁面。而PPL Text的代碼，在修改特定物理頁面之前，進行非常嚴格的檢查。即使具備PAC bypass能力，可以在內核執行任意函數，也不能直接繞過PPL防護。過往PPL繞過技術也十分精彩[3]，但是很復雜。Fugu14中，有一個非常巧妙的新發現：對于一個 64位物理地址，PPL Text對這個地址進行權限屬性檢查時，會使用全64位值；然而一旦通過了PPL Text檢查，硬件處理這個物理地址時，只使用低63位。借助這個軟硬件邏輯不一致，Fugu14輕松的調用PPL Text段代碼修改PPL保護頁面。
Fugu14整個利用鏈條上，都是邏輯漏洞佐以內存破壞漏洞利用技巧。代碼穩定，邏輯清晰，受益良多。
【參考資料】
1. https://github.com/LinusHenze/Fugu14
2. https://blog.siguza.net/APRR/
3. https://googleprojectzero.blogspot.com/2020/07/the-core-of-apple-is-ppl-breaking-xnu.html
寫到這里，發現還沒有自己的漏洞，必須發揮一下主場優勢“夾帶私貨”了。這里簡單介紹一下天府杯上iPhone 13 Pro遠程越獄里的內核漏洞。
根據Apple的官方公告，漏洞發生在IOMobileFrameBuffer (IOMBF)內核擴展中[1]。IOMFB是iOS設備上一個非常重要的內核擴展，主要用于管理屏幕顯示。諸如屏幕亮度、色調等參數的調節都是通過這個擴展實現的。熟悉iOS的同行可能注意到了，自從iPhone 12起，IOMFB大部分功能都已經移植到了DCP協處理器中。這個DCP協處理器運行單獨固件，專門處理屏幕管理功能。
事實是，我們首先攻擊了協處理器；在完全控制了DCP協處理器后，進一步攻擊應用處理器。在iOS上，上一個通過協處理器攻擊應用處理器的案例可能要追溯到2017年[2]。Project Zero在打掉iPhone上WiFi協處理器后，攻擊了應用處理器。隨著硬件升級，iPhone上裝備了越來越多的協處理器，負責圖像處理、運動感知等任務等。自2018年A12芯片起，iOS上引入了System Coprocessor Integrity Protection (SCIP)機制 [3]，強化協處理器運行環境安全。此次攻擊為未來iOS漏洞研究提供了一個新的視角，把異構多核處理器核間通信的安全問題再次暴露出來。
【參考文獻】
1. https://support.apple.com/en-us/HT212976
2. https://googleprojectzero.blogspot.com/2017/09/over-air-vol-2-pt-1-exploiting-wi-fi.html
3.https://support.apple.com/en-gb/guide/security/welcome/web
盤古實驗室聞觀行和Slipper在2021年7月30日MOSEC’21上披露了華為麒麟芯片Bootrom的一系列漏洞[1]；不到一周后，Blackhat USA上TASZK Security Labs對麒麟芯片可信啟動鏈做了深入分析，也公開了一系列漏洞[3]。Bootrom是整個設備的可信基石，一旦Bootrom被攻破，設備再無安全可言。更為嚴重的是，由于Bootrom是固化在硬件中的代碼，通常是無法通過軟件升級進行漏洞修復。
歷史上，iPhone手機的幾次Bootrom漏洞洞都造成了長遠影響。例如，2019年，蘋果A5至A11系列芯片的Bootrom被發現存在UAF漏洞CVE-2019-8900，這個不能被修復的漏洞永久性地影響從iPhone 4S到iPhone X等型號手機[4][5]。
更令人吃驚的是，華為居然通過OTA升級，修復了Bootrom的漏洞！整個修復方案令人拍案叫絕。雖然華為沒有公布修復細節，根據TASZK Security Labs的后續分析（對，他們最初也不理解為什么OTA升級能夠修復BootRom的漏洞）[2]，OTA升級后會做一次額外的EFUSE write操作；正是這個write操作，完全禁止設備在啟動階段進入USB下載模式，從而避免了后續下載模式中的各種漏洞。
針對麒麟Bootrom漏洞，攻防雙方聯袂呈現了一場技術盛宴。一句話總結，攻的精彩，修的絕妙。
【參考資料】
1. https://github.com/hhj4ck/checkm30
2. https://labs.taszk.io/articles/post/huawei_kirin990_bootrom_patch/
3.https://www.blackhat.com/us-21/briefings/schedule/index.html#how-to-tame-your-unicorn---exploring-and-exploiting-zero-click-remote-interfaces-of-modern-huawei-smartphones-23337
4. https://github.com/axi0mX/ipwndfu
5. https://checkra.in/
Sudo的堆溢出漏洞CVE-2021-3156獲得了今年Pwnies最佳提權漏洞獎[1]。拋開這個漏洞的影響范圍不談，這個漏洞帶給安全研究人員對*NIX環境下本地提權的經典重現就足夠了：Suid-root 程序、命令行參數解析溢出、經典的觸發模式、靈活的利用方法[2]，還有，漏洞已存在了10年之久。我們再欣賞一下這個POC:
$ sudoedit -s '\' `perl -e 'print "A" x 65536’
除了上面引用的漏洞分析報告[2]，國外有個信息安全網紅博主@LiveOverflow制作過一期視頻，講解了他對這個漏洞重現過程，尤其是分析了為什么這個漏洞沒有被傳統的Fuzzing工具挖掘出來，非常值得學習。Sudo這個漏洞，不僅影響Linux，也影響macOS；如果大家嘗試在macOS上寫這個漏洞的利用，就會更好的理解不同系統上漏洞緩解機制對漏洞利用開發的影響。換成M1 Mac更好玩。
【參考資料】
1. https://pwnies.com/winners/
2.https://www.qualys.com/2021/01/26/cve-2021-3156/baron-samedit-heap-based-overflow-sudo.txt
這是今年Pwnies最佳服務端漏洞大獎獲得者[1]。Windows Exchange 是被廣泛使用的郵件服務器。ProxyLogon[2]攻擊允許攻擊者在未授權的情況下，直接攻擊Windows Exchange的443端口，獲得服務器上遠程命令執行。漏洞發現者Orange Tsai在Blackhat USA上分享了詳細的漏洞細節[3]。
ProxyLogon掀開了攻擊Windows Exchange的浪潮。一方面，Orange Tsai在2021年1月把ProxyLogon漏洞細節提交給微軟；微軟確認后計劃于3月發布補丁。可是在補丁正式發布之前，2021年2月末，大量使用ProxyLogon漏洞的在野利用被捕獲。在野利用和Orange Tsai提交給微軟的POC一致。詳細時間線可以參考[2]。
另一方面，Windows Exchange的各種攻擊面相繼曝光，各種新漏洞被發現。Orange Tsai在今年的Pwn2own大賽上使用另一套漏洞（ProxyShell）實現了Exchange的遠程入侵；天府杯上，國內研究團隊基于授權賬戶實現了Exchange遠程代碼執行(CVE-2021-42321)。
【參考資料】
1. https://pwnies.com/winners/
2. https://proxylogon.com/
3. https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf
PrintNightmare 不是一個漏洞，而是一系列誤會混合了一系列漏洞。漏洞發生在Windows系統的Print Spooler服務中，這是一個負責執行打印任務和打印機交互的服務。結合微軟的公告和公開的技術分析[2,3,4]，我個人整理出來的時間線是這樣的。微軟將多個研究人員報告的漏洞，合并修復后發布本地提權漏洞 CVE-2021-1675的補丁；補丁修正的地方比較多，以至于安全研究員都以為漏洞被正確修復，于是公開了概念驗證樣本POC；然而很快被指出，CVE-2021-1675不僅沒有修復好，而且還可能被遠程觸發。這樣一來，一個不完備的補丁，暴露了遠程可觸發的安全漏洞。
噩夢就此開始。微軟緊急發布CVE-2021-34527，進一步修復CVE-2021-1675殘余的問題。可是故事還沒有結束。CVE-2021-34527也沒有完全解決問題，補丁仍然可能被繞過。微軟又發布了CVE-2021-36958補丁。故事結束了嗎？我不知道。我沒有統計微軟在2021年給Print Spooler發布多少補丁，據說現在打印服務的正常功能都已經受影響了。
如果大家還對漏洞細節感興趣，可以參考 [1]。PrintNightmare這個案例再次證明，復雜軟件中漏洞修復不是一個簡單的事情。修編碼錯誤容易，修機制性問題難于上青天。
【參考資料】
1.https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-Diving-Into-Spooler-Discovering-Lpe-And-Rce-Vulnerabilities-In-Windows-Printer.pdf
2.https://www.rapid7.com/blog/post/2021/06/30/cve-2021-1675-printnightmare-patch-does-not-remediate-vulnerability/
3.https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1675
4.https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-34527
5.https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-36958
Log4shell爆發前，全球的安全公司可能正在圍剿CVE-2021-40444 [1]。這是一個被在野利用的漏洞。攻擊者通過惡意Office文檔或者RTF格式的文檔觸發漏洞，實現遠程代碼執行。這個漏洞，投遞方式豐富、利用簡單、攻擊穩定，注定是個長期風險。漏洞整個利用鏈條中，沒有內存安全問題，而是組合了各種奇葩特性；在所有利用技巧中，從CAB文件解壓釋放INF文件中，存在路徑穿越問題，可能是唯一的“明顯”編碼錯誤。
【參考資料】
1. https://www.microsoft.com/security/blog/2021/09/15/analyzing-attacks-that-exploit-the-mshtml-cve-2021-40444-vulnerability/