历时 4 年，苹果 iPhone 遭史上最复杂攻击：一条 iMessage 窃走所有隐私数据

原标题：历时 4 年，苹果 iPhone 遭史上最复杂攻击：一条 iMessage 窃走所有隐私数据

最近，卡巴斯基的研究人员发现，有黑客在四年多的时间里给数千部 iPhone 留下了一个非常隐蔽的后门。

通过这个硬件级别的后门，能直接获得 iPhone 最高级别的 Root 权限。而要成功利用这个后门，必须要对苹果产品最底层的机制有非常全面细致的了解。

以至于发现这个漏洞的卡巴斯基研究人员称「无法想象这个漏洞是如何被意外发现的。」在他看来，除了苹果和 ARM 之外，几乎不可能有人能获知这个漏洞。

而软件可以通过这个复杂的漏洞，将麦克风录音、照片、地理位置和其他敏感数据传输到攻击者控制的服务器。

尽管重新启动就能关闭这个漏洞，但攻击者只需在设备重新启动后向设备发送新的恶意 iMessage 文本，就能重新开启这个漏洞。

期间完全不需要用户进行操作，而且也不会留下任何蛛丝马迹，非常隐蔽。

对此，OpenAI 科学家 Andrej Karpathy 表示：这无疑是我们迄今为止所见过的攻击链中最为复杂的一个。

对此，Karpathy 认为，这已经不是个人行为能够触及的范畴了，应该是国家层面的行为了。

而一位声称自己还用 Palm 手机的网友回复道：「我坚持用 Palm 手机的意义就在这里。」

甚至还有网友感叹：「如果你成功地惹恼了具备这种技术能力和资源的人，可能你最不需要担心的就是自己手机里的数据了。」

目前，苹果公司已于 2023 年 10 月 25 日修复了这一核心安全漏洞。

「三角行动」攻击链

这个漏洞被发现的研究人员称为「三角行动」（ Triangulation）。

- 攻击者通过 iMessage 发送一个恶意附件，应用程序会在用户毫无察觉的情况下开启这个漏洞。

- 该附件利用了一个远程代码执行的漏洞（CVE-2023-41990），该漏洞存在于一个只有苹果公司知道的、未公开的 ADJUST TrueType 字体指令中。这个指令自九十年代初就存在，直到最近一个更新才被移除。

- 攻击过程中，它采用了一种称为「返回 / 跳转导向编程」的高级编程技巧，并且使用了多个阶段的代码，这些代码是用 NSExpression / NSPredicate 查询语言编写的，它们修改 JavaCore 库的环境，以执行一个用 Java 编写的权限提升的漏洞攻击程序。

- 这个 Java 漏洞攻击程序经过特殊处理，使其变得几乎无法读懂，同时也尽可能地缩小了它的体积。然而，它仍然包含大约 11000 行代码。这些代码主要用于分析和操纵 JavaCore 和内核内存。

- 它还利用了 JavaCore 的一个调试功能 DollarVM ($vm)，通过这个功能，攻击者可以在脚本中操纵 JavaCore 的内存，并调用系统原生的 API 函数。

- 这个攻击工具被设计成兼容新旧型号的 iPhone，并且对于新型号的设备，它包含了一个用于绕过指针认证码（PAC）的技术，这使得攻击能够针对最新设备生效。

- 它通过利用 XNU 内存映射系统调用（mach_make_memory_entry 和 vm_map）中的一个整数溢出漏洞（CVE-2023-32434），实现了以用户级别对设备所有物理内存的读写控制。

- 该工具还运用了硬件内存映射 I / O（MMIO）寄存器来规避页面保护层（PPL），这一问题在 CVE-2023-38606 中已经被缓解。

- 利用了所有漏洞之后，Java 漏洞便能随意操控设备，包括部署软件。不过，攻击者选择了：（a）启动 IMAgent 进程，注入代码以清除利用痕迹；（b）无痕模式下运行 Safari 进程，并引导至含有下一阶段内容的网页。

- 该网页内嵌了一个脚本，能够确认受害者身份，一旦验证通过，便会加载下一阶段的攻击代码：Safari 漏洞。

- Safari 漏洞通过 CVE-2023-32435 来执行 shellcode。

- 这个 shellcode 进一步执行另一个内核级漏洞，同样利用 CVE-2023-32434 和 CVE-2023-38606。它在规模和功能上都非常庞大，但与 Java 编写的内核漏洞截然不同。它们共享的只是与上述漏洞利用相关的部分代码。然而，其大部分代码也专注于解析和操控内核内存。

- 这一漏洞最终获得了 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）工具来查看它们的内容。

设备树中 MMIO 的存储示例

例如，在这张截图里，可以看到 cpu0 的 acc-impl MMIO 范围的起始地址（0x210f00000）和大小（0x50000）。

深入研究「三角行动」（ Triangulation）攻击中使用的漏洞时，研究人员意外发现，攻击者为了绕过硬件级别的内核内存保护所使用的大部分 MMIO 地址，并没有在设备树中定义。

这个漏洞专门针对苹果从 A12 到 A16 的 SoC，攻击的是位于 0x206040000，0x206140000 和 0x206150000 的神秘 MMIO 寄存器块。

这激发了研究人员的好奇心，进行了一系列的尝试。翻遍了各种设备的设备树文件和固件文件，但都没找到任何线索。

这让研究人员困惑不已，这些被攻击者利用的 MMIO 地址，为什么不在固件中使用呢？攻击者是怎么发现这些地址的？这些 MMIO 地址到底属于哪些外围设备？

之后研究人员决定去查看一下这些未知 MMIO 块附近是否有其他已知的 MMIO 地址。这次，他终于找到了一些有价值的信息。

在 gfx-asc 的设备树条目的信息中，这是 GPU 的协处理器。

设备树中 gfx-asc 条目的数据转储

它包含两个 MMIO（Memory-Mapped I / O）内存映射范围：0x2000000–0x206C000 和 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_ALANCHE_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 利用程序使用 0x206040000 寄存器的伪代码

成功将之前伪代码中的 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，而是苹果专门为了便利性添加的专有特性。

研究人员确认了地址范围 0x206000000 到 0x206050000 确实是 GPU 协处理器的 CoreSight MMIO 调试寄存器区块，这是通过向对应地址写入 ARM_DBG_LOCK_ACCESS_KEY 实现的。

主 CPU 的每个核心都有自己的 CoreSight MMIO 调试寄存器区块，但不同于 GPU 协处理器，它们的地址可以在设备树中找到。

另一个有趣的发现是，漏洞的作者（们）知道如何利用苹果公司专有的 UTT 区域来重新启动 CPU，而这部分代码并不包含在 XNU 源代码中。可以合理推测，这一操作很可能是通过实验得出的。

然而，通过实验是无法发现攻击者在第二个未知区域内对寄存器的操作的。研究人员不确定那里有哪些 MMIO 调试寄存器区块，如果这些寄存器并未被固件所用，攻击者是如何发现其用途的也是个谜。

现在，再来关注漏洞利用的其他未知寄存器。

寄存器地址 0x206140008 和 0x206140108 负责控制启用 / 禁用以及执行漏洞所依赖的硬件功能。

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) 利用程序使用 0x206140008 和 0x206140108 寄存器的伪代码

寄存器 0x206150020 专门用于苹果的 A15 / A16 Bionic SoC。在漏洞利用的启动阶段，此寄存器会被设置为 1；而在漏洞利用完成后，会恢复为初始的数值。

寄存器 0x206150040 被用来保存一些状态标识和目标物理地址的低位部分。

最后的寄存器，0x206150048，则负责存储待写入的数据以及目标物理地址的高位部分。这些数据会与数据的校验哈希值以及另外的数值（可能是指令）一起打包。该硬件功能会将数据分块，每块大小为 （0x40）字节进行对齐写入，并且需要连续九次写操作将全部数据写入至 0x206150048 寄存器。

if (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) i = 8 mask = 0x7FFFFFF elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_ALANCHE_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 << i) | (hash2 << 50) | 0x1Fwrite_qword(0x206150048, value) dma_done(original_value_0x206140108) 利用漏洞使用 0x206150040 和 0x206150048 寄存器的伪代码

只要操作无误，硬件就会执行直接内存访问（DMA）操作，把数据写入指定的内存地址。

利用这项硬件特性，攻击者可以绕过页面保护层（Page Protection Layer, PPL），主要用途是修改页表条目。此外，它还能修改受保护的__PPLDATA 段内的数据。尽管这个漏洞并未用于修改内核代码，但在研究人员进行的一次测试中，曾成功修改了内核的__TEXT_EXEC 段内的一条指令，并引发了一个显示预期地址和值的「未定义内核指令」错误。

这种情况只出现过一次，其他尝试都导致了 AMCC 错误的发生。关于那次成功的尝试，研究人员有一些思路，未来研究人员计划深入研究，因为他认为，将一个本用于攻击的漏洞转化为正面用途，比如在新款 iPhone 上启用内核调试功能，将会非常有意义。

讨论了所有与 MMIO（Memory-Mapped I / O）寄存器相关的工作之后，现在来关注最后一个话题：哈希值的计算方法。具体的算法如下所示。

ox = [ 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, 0x0, 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, 0x3, 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 ^= ox[32 * i + j] return acc 该未知硬件功能使用的哈希函数伪代码

如你所见，这是一种定制的算法，其哈希值的计算依赖于一个预先定义好的 ox 表（ox table）。他尝试在庞大的二进制文件库中搜寻它，但一无所获。

你可能已经注意到，这个哈希并不特别安全，因为它只有 20 位（两次各计算 10 位），但只要没人知道如何计算和应用它，它就足够用了。这种做法最恰当的描述就是「隐晦式安全（security by obscurity）」。

如果攻击者没有使用这个硬件特性，并且固件中没有任何关于如何使用它的指引，他们如何可能发现并利用它呢？

研究人员又做了一个测试。他发现 Mac 内置的 M1 芯片也具备这一未知的硬件特性。接着，他利用了功能强大的 m1n1 工具进行了一次实验。

该工具具备一个 trace_range 功能，可以追踪对指定 MMIO 寄存器范围的所有访问，用它来监测 0x206110000 到 0x2000000 内存范围的活动，但结果显示 macOS 并未使用这些寄存器。

这次涉及到的 GPU 协处理器是最近才在苹果的 SoC 中首次出现的。研究人员怀疑这个硬件功能在之前的零售固件中有过任何用途。

尽管如此，也不能排除它可能曾在某个特定固件更新或 XNU 源代码的发布中不小心泄露过，之后又被删除的可能性。

研究人员原本希望通过 iOS 16.6 中对这个漏洞的修复，来探究第二个未知区域里隐藏了什么。最后确实找到了苹果是如何解决这个问题的，但他们故意将修复措施弄得难以理解。

苹果通过在设备树的 pmap-io-ranges 中加入了 MMIO 范围 0x206000000–0x206050000 和 0x206110000–0x2000000 来防止这个漏洞被利用。

XNU 根据这里的信息来判断是否允许某些物理地址的映射。所有记录在案的条目都贴上了一个标签名，这些标签清楚地说明了这些内存范围的用途。

存储在 pmap-io-ranges 中的条目示例

在这里，PCIe 指的是 「高速外围设备互连（Peripheral Component Interconnect Express）」，DART 是「设备地址解析表（Device Address Resolution Table）」，DAPF 代表「设备地址过滤器（Device Address Filter）」，诸如此类。

下面列出的是被漏洞利用的内存区域的标签名称。这些标签在列表中显得格外醒目。

利用漏洞的区域条目 「隐晦式安全」并不安全

可以看到，这个漏洞非比寻常，我们既不清楚攻击者如何学会利用这个未知的硬件特性，也不知道它最初是用来做什么的。

甚至都不确定它是由苹果开发出来的，还是类似 ARM CoreSight 这样的第三方组件造成的。

但漏洞说明了一个事实：只要存在能够绕过安全防护的硬件特征，那么无论多么先进的硬件安全措施，在精明的攻击者面前都会变得毫无用处。

硬件安全常常依赖于「隐晦式安全」（security through obscurity），相较于软件来说，硬件更难逆向工程分析。

但这种方法本身是存在缺陷的，因为所有的秘密终将有被揭露的一天。那些依赖于「隐晦式安全」来维护的系统，永远无法做到真正的安全。

参考资料：

广告声明：文内含有的对外跳转链接（包括不限于超链接、二维码、口令等形式），用于传递更多信息，节省甄选时间，结果仅供参考，IT之家所有文章均包含本声明。