今天小編分享的科技經驗：蘋果最復雜攻擊鏈細節披露：歷時4年，一條iMessage竊走所有隐私數據，歡迎閲讀。
新智元報道
編輯：潤 好困
【新智元導讀】iPhone 曝出「史上最復雜」硬體級别漏洞！黑客只需一條 iMessage 即可拿到所有敏感數據，而用户不會有任何察覺。整個漏洞涉及的鏈條極其復雜，讓 Karpathy 都驚呼：不是普通人能幹出來的事。
最近，卡巴斯基的研究人員發現，有黑客在四年多的時間裏給數千部 iPhone 留下了一個非常隐蔽的後門。
通過這個硬體級别的後門，能直接獲得 iPhone 最高級别的 Root 權限。而要成功利用這個後門，必須要對蘋果產品最底層的機制有非常全面細致的了解。
以至于發現這個漏洞的卡巴斯基研究人員稱「無法想象這個漏洞是如何被意外發現的。」在他看來，除了蘋果和 ARM 之外，幾乎不可能有人能獲知這個漏洞。
而間諜軟體可以通過這個復雜的漏洞，将麥克風錄音、照片、地理位置和其他敏感數據傳輸到攻擊者控制的伺服器。
盡管重新啓動就能關閉這個漏洞，但攻擊者只需在設備重新啓動後向設備發送新的惡意 iMessage 文本，就能重新開啓這個漏洞。
期間完全不需要用户進行操作，而且也不會留下任何蛛絲馬迹，非常隐蔽。
對此，OpenAI 科學家 Andrej Karpathy 表示：這無疑是我們迄今為止所見過的攻擊鏈中最為復雜的一個。
對此，Karpathy 認為，這已經不是個人行為能夠觸及的範疇了，應該是國家層面的行為了。
而一位聲稱自己還用 Palm 手機的網友回復道：「我堅持用 Palm 手機的意義就在這裏。」
甚至還有網友感嘆：「如果你成功地惹惱了具備這種技術能力和資源的人，可能你最不需要擔心的就是自己手機裏的數據了。」
目前，蘋果公司已于 2023 年 10 月 25 日修復了這一核心安全漏洞。
「三角行動」攻擊鏈
這個漏洞被發現的研究人員稱為「三角行動」（Operation Triangulation）。
- 攻擊者通過 iMessage 發送一個惡意附件，應用程式會在用户毫無察覺的情況下開啓這個漏洞。
- 該附件利用了一個遠程代碼執行的漏洞（CVE-2023-41990），該漏洞存在于一個只有蘋果公司知道的、未公開的 ADJUST TrueType 字體指令中。這個指令自九十年代初就存在，直到最近一個更新才被移除。
- 攻擊過程中，它采用了一種稱為「返回 / 跳轉導向編程」的高級編程技巧，并且使用了多個階段的代碼，這些代碼是用 NSExpression/NSPredicate 查詢語言編寫的，它們修改 JavaScriptCore 庫的環境，以執行一個用 JavaScript 編寫的權限提升的漏洞攻擊程式。
- 這個 JavaScript 漏洞攻擊程式經過特殊處理，使其變得幾乎無法讀懂，同時也盡可能地縮小了它的體積。然而，它仍然包含大約 11000 行代碼。這些代碼主要用于分析和操縱 JavaScriptCore 和内核内存。
- 它還利用了 JavaScriptCore 的一個調試功能 DollarVM ( $vm ) ，通過這個功能，攻擊者可以在腳本中操縱 JavaScriptCore 的内存，并調用系統原生的 API 函數。
- 這個攻擊工具被設計成兼容新舊型号的 iPhone，并且對于新型号的設備，它包含了一個用于繞過指針認證碼（PAC）的技術，這使得攻擊能夠針對最新設備生效。
- 它通過利用 XNU 内存映射系統調用（mach_make_memory_entry 和 vm_map）中的一個整數溢出漏洞（CVE-2023-32434），實現了以用户級别對設備所有物理内存的讀寫控制。
- 該工具還運用了硬體内存映射 I/O（MMIO）寄存器來規避頁面保護層（PPL），這一問題在 CVE-2023-38606 中已經被緩解。
- 利用了所有漏洞之後，JavaScript 漏洞便能随意操控設備，包括部署間諜軟體。不過，攻擊者選擇了：（a）啓動 IMAgent 進程，注入代碼以清除利用痕迹；（b）無痕模式下運行 Safari 進程，并引導至含有下一階段内容的網頁。
- 該網頁内嵌了一個腳本，能夠确認受害者身份，一旦驗證通過，便會加載下一階段的攻擊代碼：Safari 漏洞。
- Safari 漏洞通過 CVE-2023-32435 來執行 shellcode。
- 這個 shellcode 進一步執行另一個内核級漏洞，同樣利用 CVE-2023-32434 和 CVE-2023-38606。它在規模和功能上都非常龐大，但與 JavaScript 編寫的内核漏洞截然不同。它們共享的只是與上述漏洞利用相關的部分代碼。然而，其大部分代碼也專注于解析和操控内核内存。
- 這一漏洞最終獲得了 root 權限，并繼續執行其他階段的操作，這樣就可以加載間諜軟體。
謎一樣的漏洞
讨論的焦點是一個已經得到修復的安全漏洞，編号為 CVE-2023-38606。
新一代 iPhone 在硬體層面增加了額外的安全防護措施，專門用來保護内核内存中的敏感區網域。
即使攻擊者能夠讀寫内核内存，比如利用 CVE-2023-32434 漏洞實施的這次攻擊，這種防護也能阻止他們完全控制設備。
研究人員發現，攻擊者為了規避這種硬體防護，竟然利用了蘋果自家設計的 SoC 中的另一項硬體功能。
簡單來説，攻擊者的手法是這樣的：他們在繞過硬體防護的同時，将數據、目标地址和數據的哈希值一并寫入到芯片中未被固件使用的某些未知硬體寄存器，以此來對特定的物理地址進行數據寫入。
研究人員推測，這個不為人知的硬體功能很可能是為了蘋果工程師或工廠的調試或測試而設計的，或者是意外包含在内的。由于固件并未使用這一功能，研究人員對于攻擊者是如何知曉并利用這一功能的方式一無所知。
技術細節
在系統級芯片（System on a Chip, SoC）中，各種外設可能會提供特殊的硬體寄存器，以供中央處理器（CPU）使用，從而控制這些外設。
為了實現這一點，這些硬體寄存器被映射到 CPU 可以訪問的内存中，這種方式被稱為「内存映射輸入 / 輸出 ( Memory-Mapped I/O, MMIO ) 」。
蘋果的產品，如 iPhone、Mac 以及其他設備中，周邊設備的 MMIO 地址範圍被存儲在一個特殊的檔案格式中，名為「設備樹（DeviceTree）」。
這些設備樹檔案可以從固件中提取，并且可以使用 dt（DeviceTree）工具來查看它們的内容。
例如，在這張截圖裏，可以看到 cpu0 的 acc-impl MMIO 範圍的起始地址（0x210f00000）和大小（0x50000）。
深入研究「三角行動」（Operation Triangulation）攻擊中使用的漏洞時，研究人員意外發現，攻擊者為了繞過硬體級别的内核内存保護所使用的大部分 MMIO 地址，并沒有在設備樹中定義。
這個漏洞專門針對蘋果從 A12 到 A16 的 SoC，攻擊的是位于 0x206040000，0x206140000 和 0x206150000 的神秘 MMIO 寄存器塊。
這激發了研究人員的好奇心，進行了一系列的嘗試。翻遍了各種設備的設備樹檔案和固件檔案，但都沒找到任何線索。
這讓研究人員困惑不已，這些被攻擊者利用的 MMIO 地址，為什麼不在固件中使用呢？攻擊者是怎麼發現這些地址的？這些 MMIO 地址到底屬于哪些周邊設備？
之後研究人員決定去查看一下這些未知 MMIO 塊附近是否有其他已知的 MMIO 地址。這次，他終于找到了一些有價值的信息。
在 gfx-asc 的設備樹條目的信息中，這是 GPU 的協處理器。
設備樹中 gfx-asc 條目的數據轉儲
它包含兩個 MMIO（Memory-Mapped I/O）内存映射範圍：0x206400000 – 0x20646C000 和 0x206050000 – 0x206050008。
gfx-asc MMIO 範圍與漏洞所用地址的相關性
要更加準确地描述，這個漏洞使用了以下一些未知的地址：0x206040000、0x206140008、0x206140108、0x206150020、0x206150040 和 0x206150048。
研究人員發現，這些地址大部分位于兩個 gfx-asc 内存區網域的中間，而剩餘的一個地址則靠近第一個 gfx-asc 區網域的起始位置。
這暗示了所有這些内存映射輸入輸出（MMIO）寄存器很有可能是屬于圖形處理單元（GPU）的協處理器！
随後，研究人員對這個漏洞進行了更深入的分析，并且發現了一個進一步的證據。
在初始化過程中，漏洞首先會寫入一些位于每個 SoC 特定地址的内存映射輸入輸出（MMIO）寄存器。
if ( cpuid == 0x8765EDEA ) : # CPUFAMILY_ARM_EVEREST_SAWTOOTH ( A16 ) base = 0x23B700408 command = 0x1F0023FF
elif ( cpuid == 0xDA33D83D ) : # CPUFAMILY_ARM_AVALANCHE_BLIZZARD ( A15 ) base = 0x23B7003C8 command = 0x1F0023FF
elif ( cpuid == 0x1B588BB3 ) : # CPUFAMILY_ARM_FIRESTORM_ICESTORM ( A14 ) base = 0x23B7003D0 command = 0x1F0023FF
elif ( cpuid == 0x462504D2 ) : # CPUFAMILY_ARM_LIGHTNING_THUNDER ( A13 ) base = 0x23B080390 command = 0x1F0003FF
elif ( cpuid == 0x07D34B9F ) : # CPUFAMILY_ARM_VORTEX_TEMPEST ( A12 ) base = 0x23B080388 command = 0x1F0003FF
if ( ( ~read_dword ( base ) & 0xF ) != 0 ) : write_dword ( base, command ) while ( True ) : if ( ( ~read_dword ( base ) & 0xF ) == 0 ) : break
漏洞中 GFX 電源管理器控制代碼的偽代碼
在設備樹和 Siguza 開發的工具 pmgr 的輔助下，研究人員發現所有這些地址都對應于電源管理器中的 GFX 寄存器所在的 MMIO（Memory-Mapped Input/Output）範圍。
最後，當研究人員嘗試去訪問這些未知區網域的寄存器時，得到了第三個證實。
GPU 的協處理器幾乎立刻報錯，顯示信息：「GFX SERROR Exception class=0x2f ( SError interrupt ) , IL=1, iss=0 – power ( 1 ) 」。
這樣，研究人員就确認了所有這些未知的 MMIO 寄存器，它們是被用來進行漏洞利用的，确實屬于 GPU 的協處理器。
這促使研究人員更深入地研究這個固件，這些固件也是用 ARM 架構編寫且未加密的，但是他在固件中并沒有找到任何與這些寄存器相關的信息。
他決定更仔細地研究這個漏洞是如何操縱這些未知的 MMIO 寄存器的。在所有寄存器中，0x206040000 特别引人注目，因為它位于一個與其他所有寄存器都不同的獨立 MMIO 塊中。
它僅在漏洞的初始化和結束階段被操作：在初始化過程中是第一個被設定的寄存器，在結束階段是最後一個。
根據研究人員的經驗，很明顯這個寄存器不是用來啓用 / 禁用漏洞所利用的硬體功能，就是用來中斷控制。
研究人員開始追蹤中斷的線索，不久之後，他不僅識别出了這個未知的寄存器 0x206040000，還發現了地址範圍 0x206000000 – 0x206050000 究竟映射了什麼。下面展示的是研究人員能夠識别出的漏洞代碼的逆向工程結果。
def ml_dbgwrap_halt_cpu ( ) :
value = read_qword ( 0x206040000 )
if ( ( value & 0x90000000 ) != 0 ) : return
write_qword ( 0x206040000, value | 0x80000000 )
while ( True ) : if ( ( read_qword ( 0x206040000 ) & 0x10000000 ) != 0 ) : break
def ml_dbgwrap_unhalt_cpu ( ) :
value = read_qword ( 0x206040000 )
value = ( value & 0xFFFFFFFF2FFFFFFF ) | 0x40000000 write_qword ( 0x206040000, value )
while ( True ) : if ( ( read_qword ( 0x206040000 ) & 0x10000000 ) == 0 ) : break
成功将之前偽代碼中的 ml_dbgwrap_halt_cpu 函數與 XNU 源代碼的 dbgwrap.c 檔案中同名函數匹配起來。該檔案包含了用于操控主 CPU 的 ARM CoreSight MMIO 調試寄存器（ARM CoreSight MMIO debug registers）的代碼。
源代碼顯示，存在四個與 CoreSight 相關的 MMIO 區網域，它們分别是 ED、CTI、PMU 和 UTT。每個區網域占據 0x10000 字節，且彼此緊鄰。
ml_dbgwrap_halt_cpu 函數利用了 UTT 區網域。與其他三個區網域不同，UTT 并非來自 ARM，而是蘋果專門為了便利性添加的專有特性。
主 CPU 的每個核心都有自己的 CoreSight MMIO 調試寄存器區塊，但不同于 GPU 協處理器，它們的地址可以在設備樹中找到。
另一個有趣的發現是，漏洞的作者（們）知道如何利用蘋果公司專有的 UTT 區網域來重新啓動 CPU，而這部分代碼并不包含在 XNU 源代碼中。可以合理推測，這一操作很可能是通過實驗得出的。
然而，通過實驗是無法發現攻擊者在第二個未知區網域内對寄存器的操作的。研究人員不确定那裏有哪些 MMIO 調試寄存器區塊，如果這些寄存器并未被固件所用，攻擊者是如何發現其用途的也是個謎。
現在，再來關注漏洞利用的其他未知寄存器。
def dma_ctrl_1 ( ) :
ctrl = 0x206140108
value = read_qword ( ctrl ) write_qword ( ctrl, value | 0x8000000000000001 ) sleep ( 1 )
while ( ( ~read_qword ( ctrl ) & 0x8000000000000001 ) != 0 ) : sleep ( 1 )
def dma_ctrl_2 ( flag ) :
ctrl = 0x206140008
value = read_qword ( ctrl )
if ( flag ) : if ( ( value & 0x1000000000000000 ) == 0 ) : value = value | 0x1000000000000000 write_qword ( ctrl, value ) else: if ( ( value & 0x1000000000000000 ) != 0 ) : value = value & ~0x1000000000000000 write_qword ( ctrl, value )
def dma_ctrl_3 ( value ) :
ctrl = 0x206140108
value = value | 0x8000000000000000
write_qword ( ctrl, read_qword ( ctrl ) & value )
while ( ( read_qword ( ctrl ) & 0x8000000000000001 ) != 0 ) : sleep ( 1 )
def dma_init ( original_value_0x206140108 ) :
dma_ctrl_1 ( ) dma_ctrl_2 ( False ) dma_ctrl_3 ( original_value_0x206140108 )
def dma_done ( original_value_0x206140108 ) :
dma_ctrl_1 ( ) dma_ctrl_2 ( True ) dma_ctrl_3 ( original_value_0x206140108 )
if ( cpuid == 0x8765EDEA ) : # CPUFAMILY_ARM_EVEREST_SAWTOOTH ( A16 ) i = 8 mask = 0x7FFFFFF
elif ( cpuid == 0xDA33D83D ) : # CPUFAMILY_ARM_AVALANCHE_BLIZZARD ( A15 ) i = 8 mask = 0x3FFFFF
elif ( cpuid == 0x1B588BB3 ) : # CPUFAMILY_ARM_FIRESTORM_ICESTORM ( A14 ) i = 0x28 mask = 0x3FFFFF
elif ( cpuid == 0x462504D2 ) : # CPUFAMILY_ARM_LIGHTNING_THUNDER ( A13 ) i = 0x28 mask = 0x3FFFFF
elif ( cpuid == 0x07D34B9F ) : # CPUFAMILY_ARM_VORTEX_TEMPEST ( A12 ) i = 0x28 mask = 0x3FFFFF
dma_init ( original_value_0x206140108 )
hash1 = calculate_hash ( data ) hash2 = calculate_hash ( data+0x20 )
write_qword ( 0x206150040, 0x2000000 | ( phys_addr & 0x3FC0 ) )
pos = 0while ( pos<0x40 ) : write_qword ( 0x206150048, read_qword ( data + pos ) ) pos += 8
phys_addr_upper = ( ( ( ( phys_addr>>14 ) & mask ) <<18 ) & 0x3FFFFFFFFFFFF ) value = phys_addr_upper | ( hash1<
dma_done ( original_value_0x206140108 )
只要操作無誤，硬體就會執行直接内存訪問（DMA）操作，把數據寫入指定的内存地址。
利用這項硬體特性，攻擊者可以繞過頁面保護層（Page Protection Layer, PPL），主要用途是修改頁表條目。此外，它還能修改受保護的 __PPLDATA 段内的數據。盡管這個漏洞并未用于修改内核代碼，但在研究人員進行的一次測試中，曾成功修改了内核的 __TEXT_EXEC 段内的一條指令，并引發了一個顯示預期地址和值的「未定義内核指令」錯誤。
這種情況只出現過一次，其他嘗試都導致了 AMCC 錯誤的發生。關于那次成功的嘗試，研究人員有一些思路，未來研究人員計劃深入研究，因為他認為，将一個本用于攻擊的漏洞轉化為正面用途，比如在新款 iPhone 上啓用内核調試功能，将會非常有意義。
讨論了所有與 MMIO（Memory-Mapped I/O）寄存器相關的工作之後，現在來關注最後一個話題：哈希值的計算方法。具體的算法如下所示。
sbox = [ 0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016, 0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045, 0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117, 0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D, 0x06B, 0x0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105, 0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C, 0x052, 0x076, 0x08A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3, 0x12D, 0x205, 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206, 0x209, 0x07C, 0x0BA, 0x0D6, 0x155, 0x193, 0x253, 0x28B, 0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058, 0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 0x196, 0x199, 0x256, 0x165, 0x259, 0x263, 0x30D, 0x313, 0x098, 0x064, 0x114, 0x0A2, 0x15C, 0x0EA, 0x20C, 0x0C1, 0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315, 0x0EC, 0x1A6, 0x29A, 0x266, 0x1A9, 0x269, 0x319, 0x2C3, 0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141, 0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8, 0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070, 0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144, 0x1B8, 0x224, 0x1D4, 0x182, 0x242, 0x2D2, 0x32C, 0x281, 0x351, 0x389, 0x1D8, 0x2D4, 0x352, 0x38A, 0x391, 0x0D0, 0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0x2E4, 0x358, 0x394, 0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302, 0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250, 0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x370, 0x3A8, 0x3C4, 0x160, 0x290, 0x308, 0x3B0, 0x3C8, 0x3D0, 0x1A0, 0x260, 0x310, 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380 ]
def calculate_hash ( buffer ) :
acc = 0 for i in range ( 8 ) : pos = i * 4 value = read_dword ( buffer + pos ) for j in range ( 32 ) : if ( ( ( value>>j ) & 1 ) != 0 ) : acc ^= sbox [ 32 * i + j ]
return acc
該未知硬體功能使用的哈希函數偽代碼
如你所見，這是一種定制的算法，其哈希值的計算依賴于一個預先定義好的 sbox 表（sbox table）。他嘗試在龐大的二進制檔案庫中搜尋它，但一無所獲。
你可能已經注意到，這個哈希并不特别安全，因為它只有 20 位（兩次各計算 10 位），但只要沒人知道如何計算和應用它，它就足夠用了。這種做法最恰當的描述就是「隐晦式安全（security by obscurity）」。
如果攻擊者沒有使用這個硬體特性，并且固件中沒有任何關于如何使用它的指引，他們如何可能發現并利用它呢？
研究人員又做了一個測試。他發現 Mac 内置的 M1 芯片也具備這一未知的硬體特性。接着，他利用了功能強大的 m1n1 工具進行了一次實驗。
該工具具備一個 trace_range 功能，可以追蹤對指定 MMIO 寄存器範圍的所有訪問，用它來監測 0x206110000 到 0x206400000 内存範圍的活動，但結果顯示 macOS 并未使用這些寄存器。
這次涉及到的 GPU 協處理器是最近才在蘋果的 SoC 中首次出現的。研究人員懷疑這個硬體功能在之前的零售固件中有過任何用途。
盡管如此，也不能排除它可能曾在某個特定固件更新或 XNU 源代碼的發布中不小心泄露過，之後又被删除的可能性。
研究人員原本希望通過 iOS 16.6 中對這個漏洞的修復，來探究第二個未知區網域裏隐藏了什麼。最後确實找到了蘋果是如何解決這個問題的，但他們故意将修復措施弄得難以理解。
蘋果通過在設備樹的 pmap-io-ranges 中加入了 MMIO 範圍 0x206000000 – 0x206050000 和 0x206110000 – 0x206400000 來防止這個漏洞被利用。
XNU 根據這裏的信息來判斷是否允許某些物理地址的映射。所有記錄在案的條目都貼上了一個标籤名，這些标籤清楚地説明了這些内存範圍的用途。
存儲在 pmap-io-ranges 中的條目示例
在這裏，PCIe 指的是 「高速周邊設備互連（Peripheral Component Interconnect Express）」，DART 是「設備地址解析表（Device Address Resolution Table）」，DAPF 代表「設備地址過濾器（Device Address Filter）」，諸如此類。
下面列出的是被漏洞利用的内存區網域的标籤名稱。這些标籤在列表中顯得格外醒目。
利用漏洞的區網域條目
「隐晦式安全」并不安全
可以看到，這個漏洞非比尋常，我們既不清楚攻擊者如何學會利用這個未知的硬體特性，也不知道它最初是用來做什麼的。
甚至都不确定它是由蘋果開發出來的，還是類似 ARM CoreSight 這樣的第三方組件造成的。
但漏洞説明了一個事實：只要存在能夠繞過安全防護的硬體特征，那麼無論多麼先進的硬體安全措施，在精明的攻擊者面前都會變得毫無用處。
硬體安全常常依賴于「隐晦式安全」（security through obscurity），相較于軟體來説，硬體更難逆向工程分析。
但這種方法本身是存在缺陷的，因為所有的秘密終将有被揭露的一天。那些依賴于「隐晦式安全」來維護的系統，永遠無法做到真正的安全。
