揭秘三角行动(Operation Triangulation)一
2023-12-28 16:47:25 Author: mp.weixin.qq.com(查看原文) 阅读量:8 收藏

背景

2023年6月1日,俄罗斯联邦安全局(FSB)和俄罗斯外交部称查出一起美国情报机构通过美国苹果公司移动设备开展的情报行动。

FSB声明如下:

俄罗斯联邦安全局(FSB)称,在与俄罗斯联邦警卫局(FSO)的一起联合行动中,查出一起美国情报机构通过美国苹果公司移动设备开展的情报行动。

俄安全局称,对俄罗斯电信基础设施进行安全评估期间,他们发现了“异常”情况,这些“异常”仅出现在苹果手机上,“异常”原因是“一个以前未发现的恶意程序利用制造商提供的软件漏洞(入侵手机)”。

俄安全局称,数千台苹果手机感染了这种恶意软件,且不仅有俄罗斯公民的手机成为攻击目标,“发现有外国号码和外国用户被感染的情况,这些SIM卡的主体登记为驻俄大使馆或外交使团,其中包括北约国家和‘后苏联空间国家’(指作为俄罗斯近邻的原苏联各加盟共和国),还有以色列、叙利亚和中国。”

俄罗斯外交部在一份声明中称,这些隐藏数据是通过美制手机的软件漏洞收集的,几十年来,美国情报机构一直利用IT公司在互联网用户不知情的情况下收集大量用户数据。

为什么叫三角行动(Operation Triangulation)?

在“三角行动”这个案例中,攻击者在攻击链的早期使用了一个特殊的验证机制 - 让受害者浏览器渲染一个黄色的三角形,然后计算这个三角形的哈希值。这个验证手段是该攻击链的一个独特标志。

卡巴斯基研究人员在分析这个攻击链时,注意到了这个使用三角形渲染的验证机制。因为这个机制在该攻击链中起到了关键作用,所以研究人员决定据此来命名这个APT攻击活动,取名为“三角行动”(Operation Triangulation)。

最有趣的发现:

1.零点击远程漏洞利用

攻击者能够通过零点击的方式,只需要受害者查看一个恶意制造的iMessage,就可以在他们的iPhone上执行代码。这种不需要任何用户交互就能入侵设备的手段非常可怕。

2.硬件功能绕过保护机制

报告讲述了攻击者如何利用苹果设备的一个隐藏硬件功能完全绕过内核保护。这种利用硬件回门的方式非常罕见且高级,能完全突破iOS的安全防线。

3.利用机器学习分析数据

报告提到这可能是首次有记录的APT利用机器学习技术分析所窃取的数据,表明先进对手已经掌握了该领域技术。

4.两个独立攻击系统的组合

报告表示,整个攻击看似由两个不同目的的系统联合执行,一个侧重网络攻击,一个侧重零点击利用,这种互补的创新组合值得关注。

5. 对Mac OS的关注

几个报告都暗示攻击者也在扩展至Mac OS平台,如果获得跨平台攻击能力将更加危险。

卡巴斯基是如何抓到“triangle DB”APT平台样本的?

在调查中,虽然能够判断特定设备是否被感染,但无法检索有效载荷,因此采取了设下陷阱、进行中间人攻击的策略,通过服务器配备WireGuard和Mitmproxy,在目标设备上安装了根证书,重定向所有流量,解密并读取所有流量,同时通过Telegram机器人实时监控新的感染,最终通过代理修改数据包内容,成功检索和解密了大量有关验证器、漏洞利用代码、植入的间谍软件等精彩内容的信息。

 “triangle DB”是一个被部署在受害者设备上的复杂APT后门程序,其主要功能包括:

1.收集敏感信息

它可以收集设备上的各种敏感信息,如通讯录、短信、照片、录音、位置信息、Apple ID等。

2.控制手机传感器

它可以控制手机的麦克风、摄像头等传感器,进行间谍活动。

3.与C2通信

它可以与命令和控制服务器通信,接收控制指令并发送窃取的数据。

4.下载并执行插件

它可以从C2服务器下载并执行各种功能插件,扩展其间谍能力。

5.隐蔽自身

它可以监视日志文件,一旦发现研究人员的访问就停止运行,删除证据。

6.持续控制设备

它可能在设备重启后持久运行,实现对设备的持续控制。

7.跨平台支持

它可能同时支持iOS和MacOS,实现跨平台利用。

攻击者的Bad OPSEC(犯了哪些错误)

1.在检查这些备份时,我们发现尽管攻击者在利用过程中清除了一些痕迹,但他们未能删除所有痕迹。因此,我们能够洞察感染过程的细节。在这次行动中,攻击者非常在意隐秘行事,他们删除了所有带有漏洞利用代码的附件,但他们忘记删除存储这些iMessage附件的文件夹。

2.除了删除iMessage附件,他们还从不同数据库中删除了大量证据,例如SMS数据库等。但他们又忘记了iOS取证中一个最重要的数据库(数据使用数据库?)。这个数据库包含大量应用程序跟踪和网络使用信息。检查这个数据库后,我们发现一个名为“BackupAgent”的可疑进程,它进行了网络连接。与此同时,我们在网络中发现了连接到可疑域名。

苹果系统芯片(SoC)中的漏洞

卡巴斯基(Kaspersky)的GReAT团队发现了一项存在于苹果系统芯片(SoC)中的漏洞,该漏洞在最近的iPhone攻击中扮演了关键角色,这次攻击被称为“Operation Triangulation”(三角测量行动)。该漏洞使攻击者能够绕过运行iOS版本高达iOS 16.6的iPhone上基于硬件的内存保护(指的是iPhone设备中通过硬件实施的一系列机制,旨在保护设备的内存免受恶意操作和未经授权的访问。绕过意味着攻击者成功利用了硬件层面的漏洞,绕过了这些内存保护机制,使其能够执行恶意代码或操纵受保护的内存区域。)。

发现的漏洞是一个硬件特性,可能基于“通过混淆提高安全性”的原则(这句话指出所发现的漏洞是一种硬件上的特性,有可能是基于“通过混淆提高安全性”的原则而设计的,其用途可能是为了测试或调试系统。在计算机领域,通过混淆提高安全性意味着故意使系统或组件的某些方面复杂或难以理解,从而增加攻击者分析和利用漏洞的难度。由于这种硬件特性未被公开记录,因此它的存在和目的可能在设计时并未广泛传达,可能是为了内部用途而存在。),并且可能旨在进行测试或调试。在初始的0-click iMessage攻击和随后的提权之后,攻击者利用了这个硬件特性来绕过基于硬件的安全保护,并操纵受保护的内存区域的内容。这一步骤对于获取对设备的完全控制至关重要。苹果已经解决了这个问题,标识为CVE-2023-38606。

据卡巴斯基所知,这个特性并未公开记录,这在使用传统的安全方法进行检测和分析时带来了重大挑战。GReAT研究人员进行了大量的逆向工程,仔细分析了iPhone硬件和软件集成,特别关注了内存映射I/O(MMIO)地址,这对于在系统中实现CPU与外围设备之间的高效通信至关重要。攻击者用于绕过基于硬件的内核内存保护的未知MMIO地址未在任何设备树范围内被识别,这构成了一个重大挑战。团队还必须解密SoC的复杂运作以及它与iOS操作系统的交互,特别是有关内存管理和保护机制的方面。这个过程涉及对各种设备树文件、源代码、内核映像和固件进行仔细检查,以寻找对这些MMIO地址的任何引用。

苹果系统芯片(SoC)是由苹果公司设计和制造的一种集成电路,它集成了多个关键的计算和通信组件,包括中央处理器(CPU)、图形处理器(GPU)、内存控制器、存储控制器、图像信号处理器、神经网络处理器等。这些组件都集成在一个单一的芯片上,形成了一种高度集成的解决方案,用于驱动苹果设备的各种功能。

苹果的SoC主要用于其移动设备,如iPhone、iPad和iPod Touch。在过去,苹果使用Intel的处理器作为其计算设备的主要芯片,但从2010年开始,苹果逐渐开始采用自家设计的SoC。这一转变的一个标志性事件是苹果在2010年推出的A4芯片,它首次集成在iPad中,随后被用于其他iOS设备。

随着时间的推移,苹果不断推出更新版本的SoC,例如A5、A6、A7等,每一代都带来更强大的性能、更高效的能源利用和更先进的功能。苹果的SoC是通过在设计和优化方面进行整合,以实现对其硬件和软件之间协同作用的最大控制。这也有助于提供对iOS设备的优化性能和卓越的用户体验。

=====================================================

以下是卡巴斯基GReAT团队今天的演讲全文编译:

各位好,我是Boris Lauren,今天我在这里与两位年轻而优秀的学生研究人员一起。这是他们第一次在这样大的群众面前进行演讲。今天我们将讨论一个可能是我们见过的最复杂的攻击之一。想象一下,你发现了对你同事的iPhone进行零点击攻击,并管理捕获了整个攻击过程。这正是我们遇到的情况。我们称这些攻击为“三角行动”。这些都是针对iOS设备的有目标性攻击,并被Kaspersky发现,也针对Kaspersky进行。

今天我们将讲述这个复杂攻击的故事。我们将讲述我们如何捕获了整个攻击过程。我们也将回顾整个攻击链。我们将给出远程代码执行漏洞、越狱检测绕过、疯狂的内核漏洞以及不可思议的硬件漏洞等详细信息。我们还将回顾在这次攻击中使用的实际间谍软件。在此,我把话筒交给Lena,让他来讲述我们是如何发现这次攻击的。

非常感谢,Boris。你可能会问,我们是如何获取并分析这次攻击的所有链路的。答案是,尽管“三角行动”背后的攻击者非常有经验,但他们还是犯下了许多错误,而我们则尽最大努力利用他们的错误来全面分析这次恶意运动。

这个研究的故事始于我们在内部网络中检测到的可疑活动。我们有一个专门为移动设备提供的内部WiFi网络。有一天,当我们使用网络监控解决方案监控流量时,发现几台基于iOS的设备有可疑活动。当时,我们只发现了一些可疑的域名,并注意到一些有趣的事实:第一,这些域名的命名风格相似,都是两个单词加上".com"后缀;第二,这些域名总是成对使用,通常第一个域名在利用阶段使用,第二个域名用于命令与控制(C2);第三,我们观察到向这些域名的大量出站流量;最后,这些域名使用的是伪装身份注册,并由Cloudflare进行保护。

通过观察受感染设备的流量,我们能够找到一种模式,可以帮助我们检测新的感染。首先,设备会连接到iCloud服务器并下载iMessage附件,然后它会向第一级利用框架服务器(在大多数情况下是backuprabbit[.]com)执行几次请求,之后它会断开连接,并与第二级命令与控制服务器进行定期通信。

在我们推断我们的员工设备遭到入侵后,我们必须获取更多关于这次攻击的信息,而不仅仅是恶意网络活动。为此,我们决定在办公室四处奔波,收集这些设备进行取证分析。当然,在那个时候,我们不知道这个恶意软件具有什么功能,所以我们必须谨慎地通知设备所有者感染的事实,然后为进一步分析做一个备份。

在检查这些备份时,我们发现尽管攻击者在利用过程中清除了一些痕迹,但他们未能删除所有痕迹。因此,我们能够洞察感染过程的细节。在这次行动中,攻击者非常在意隐秘行事,他们删除了所有带有漏洞利用代码的附件,但他们忘记删除存储这些iMessage附件的文件夹。通过检查移动取证工具包(https://docs.mvt.re/en/latest/)生成的日志,我们可以看到SMS附件文件夹已被修改,但不包含任何文件。

除了删除iMessage附件,他们还从不同数据库中删除了大量证据,例如SMS数据库等。但他们又忘记了iOS取证中一个最重要的数据库(数据使用数据库?)。这个数据库包含大量应用程序跟踪和网络使用信息。检查这个数据库后,我们发现一个名为“BackupAgent”的可疑进程,它进行了网络连接。与此同时,我们在网络中发现了连接到可疑域名。

BackupAgent是一个iOS中存在的正规二进制文件,但自iOS 4以来已不再使用,因此不应该有任何网络连接。这为“三角行动”中的第一个明确的入侵证据(BackupAgent进程的数据使用情况。)

在调查的这一阶段,我们可以判断特定设备是否被感染,但无法检索任何有效载荷。所以我们决定设下陷阱,进行中间人攻击但不被检测到。为此,我们准备了一个配备WireGuard和Mitmproxy的服务器,在目标设备上安装了根证书,并将所有流量重定向到该服务器。如此,我们就可以解密并读取所有流量了。为了有效的实时监控,我们还开发了一个Telegram机器人,可以通知我们新的感染。 

最重要的是,通过代理,我们可以修改所有数据包。这实际上给了我们无限的力量。首先,在任何修补的情况下,我们就可以获取第一个有效载荷,它是一个带有JavaScript代码的HTML页面。该代码执行各种检查,并进行画布指纹识别,渲染一个黄色三角形,然后计算其哈希值。这也是我们称此次攻击为“三角行动”的原因。接下来,为了检索每个阶段,我们不得不破解各种非对称加密。我们的方法是即时修改这些阶段的代码逻辑,将其移到我们的Mitmproxy插件中,使用正则表达式逐步解密后续阶段。

最后,我们实现了一个400行的Mitmproxy插件,它帮助我们检索并解密了大量精彩内容,包括验证器、漏洞利用代码、植入的间谍软件以及其他模块。最终,我们完成了全部检索。我的同事Boris和Georgi将为您详细介绍我们所获取的内容。

这次攻击使用了一个恶意附件作为启动点。这个附件是一个PDF文件,但真正的漏洞利用代码隐藏其中。它是一个TrueType字体漏洞利用。可能大多数人都听说过TrueType,这是世界上最常见的字体格式,由苹果公司在1991年开发,并共享给了微软,内置于Windows 3.1系统中。因此,Windows上存在大量与TrueType字体处理相关的漏洞。我阅读了TrueType字体编程文档,并使用IDA Pro反汇编工具对其进行逆向工程。我也注意到文档缺失了许多细节,所以我检查了iOS处理TrueType字体的实际代码,以弥补文档的不足。

几乎立即我在iOS中的某些地方发现了一些奇怪的东西,有一个未记录的指令,在任何地方都未提及。我试图在苹果和微软的网站上查阅不同的文档,在GitHub上谷歌搜索,但一无所获。这个指令唯一的提及就是在Windows的汇编代码中,它是唯一的提及。它说这是一个苹果专有的不支持的指令,这是90年代初的说法。所以我们有一个未记录的苹果专有指令,你能猜到漏洞在哪里吗?

这个指令的代码进行了两个方向的一些调整,你可以看到这段代码几乎相同,可以推断开发人员只是拷贝黏贴了一段代码。这两段代码块之间唯一的不同之处是,开发人员这里应该是nPoint减1,否则会指向工作点缓冲区之外。另一个缓冲区包含了指向其他数组的偏移量,如果这些偏移量被损坏,攻击者就能“覆写”更多内存中的内容,并以此方式获得代码执行。这种TrueType字体解析的代码来自90年代,利用起来就像大多数90年代的漏洞一样,使用解释器和其他内容进行漏洞利用。我不会详细讨论其利用方式,但有趣的是,我想讨论苹果如何修复这个漏洞的时间线。这种构造从90年代初就存在,然后在2023年1月悄然被删除。我们知道到那时攻击者已经在利用这个漏洞。我不知道实际发生了什么,我相信苹果突然开始接收大量的Crash日志,并怀疑发生了一些不好的事情,因为自90年代以来这条指令很可能没有被使用过。苹果决定将其删除是正确的,但没有警告任何人这种利用则是不好的。为了利用新的iPhone,攻击者需要额外的越狱检测绕过漏洞。

在新版iPhone上,有一些特殊的指令用于对指针进行签名和检查。其工作方式是指针中的虚拟地址位于最低部分,指针的高位包含密码签名。攻击者需要用pkez指令对它们的指针进行签名,这基本上就像使用默认模式进行签名。攻击者利用这些弱点来绕过检测。首先,有太多不同的指针使用默认模式进行签名,其次,这些指针可以在内存中容易发现。首先绕过pPac缓存,获取你要执行的函数的地址的最低部分,然后在内存中尝试找到它,看是否在其附近有数据,如果地址的最低部分与之匹配,那么你就找到了你要找的。这就是漏洞以及如何利用它的方式。

首先,他们找到了dlsym函数的签名指针,可以用来通过函数名获取任何其他函数的签名指针。他们获取imp_protect函数的签名指针,构造了一个包含一个导出表的伪装mach-o,这个导出表指向通常不导出的LD库中的函数签名指针。然后他们为这个mach-o构建了一个加载器对象,将其注入已加载镜像列表中。这样他们就可以调用这个伪造的mach-o中的imp_func,并获取sign_pointer函数的签名指针,用任何modifier对任意指针进行签名,完全绕过PAC。

攻击者用这种方式执行了一个ROP链和一些表达式。在Objective-C中有一种特殊的查询语言叫做NSExpression和NSPredicate,它们看起来像这样,可以用这种语言做任何事情。我认为可以编写一个脚本,将Objective-C代码转换为这种格式,以调用任何函数、进行类型转换等。很可能也可以完全自动完成这种转换。攻击者执行了一个二进制的属性列表,它基本上用作表达式的容器。所有这些表达式都用于执行下一个阶段的exploit,该exploit使用JavaScript编写。

iOS应用可以运行JavaScript,但没有JIT编译。该exploit充分利用这一点来获得最大的功能。攻击者修改了JavaScript代码库的内存,使其拥有非常大的内存量,禁用垃圾回收,最后启用名为$vm的特殊调试功能。通过该调试功能,它提供了可以从脚本内部调用的特殊函数。这些函数可以用来获取对象的地址,以及获取读写原语。这个JavaScript exploit是我见过的最复杂的exploit,特别是考虑到它是JavaScript。该exploit进行了混淆以使其难以阅读并最小化大小,但仍然有11000行代码。简单地重新格式化它,在这个exploit中,攻击者能够直接从JavaScript执行任何API函数。这也是PlayStation 4和5漏洞利用中的一种流行技术,因为和这种情况一样,也没有JIT编译。为了获得这种功能,攻击者构建了一个伪造的对象,并将其与一系列gadget结合使用,以便用任意参数数量执行任何函数。

现在我想讨论内核漏洞,这是一个非常简单且强大的漏洞。它利用内存映射中的多个整数溢出,不需要任何内存破坏就可以实现利用,非常容易利用,且非常可靠。

我们有这样的一个系统调用,叫做vm_map_make_memory_entry,用于在不映射的情况下创建内存条目。你可以提供特定的偏移和大小,它会为你创建内存条目。内存映射是操作系统的关键组成部分,这就是它在许多沙箱中可用的原因。这个系统调用对偏移和大小进行了检查。偏移和大小这里是输入参数,这意味着可以轻松绕过,允许攻击者创建巨大的内存条目,远大于原始对象的大小,基本上覆盖这里设备上可用的所有其他空间。 

然后我们有一个vm_map_Contents,用于映射某个特定的内存区域。它也有一个检查,对这样巨大的内存条目也会被绕过。这使攻击者能够映射父内存对象之外的内存。如果我们将这个漏洞与特殊的父内存对象结合起来,它可以映射设备的所有物理空间。

这是iPhone的物理内存映射,我们有一些带有内存映射IO寄存器的区域,还有显示内存、挥发性存储等。这只是一个例子。在RAM中,有一个特殊的内存映射对象,叫做PurpleGraphicsM,基本上是一个帧缓冲区,可以与这个漏洞一起使用,映射到用户级别。这样,攻击者就能够从用户级别映射读取和写入设备的所有物理内存。

之后的整个利用只是内存的解析。攻击者为PurpleGraphicsM创建一个恶意内存条目,获取它的基地址,因为它在不同设备和版本之间可能不同,攻击者需要它来将真实物理地址转换为原始地址。然后他们找到一个叫做iBootHandoff的特殊对象,它位于iBoot之后的内存中,具有内存映射。攻击者从它获取DRM基地址。他们还能够从特殊寄存器获取内核及其大小的物理地址。这不仅对新版iPhone有效,也对旧版有效。他们在RAM中找到每个CPU的数据结构,也找到VM page数组。之后,他们分叉大量线程,并从其中一个线程的active_thread字段中的内核地址获取它的内核地址。然后他们能够将线程的内核地址转换为其物理地址。因为他们有这个物理映射原语,他们可以操纵它,通过线程的getState获取内核读权限。对于内核写权限,攻击者对每个iOS版本使用不同的技术,但仍然是关于解析内存。

我认为第一个漏洞很好,内核漏洞很疯狂,但这个简直太不可思议了。在我看来,iOS攻击者的生活相当痛苦。

因为你需要远程代码执行,你需要越狱检测绕过,你需要内核漏洞利用。在其他平台上,到了这一步就基本成功了,你可以为所欲为。但在这里,你需要面对终极BOSS,基于硬件的内存保护。 

其中包括PPL,保护内核关键内存区域,也可以防止攻击者向用户进程注入恶意代码;KR,保护内核可执行代码;P-Kernel-P。但是,如果我告诉你,攻击者实际上能够绕过所有这些非常复杂的先进基于硬件的内存保护机制,这会让攻击者非常高兴。

所有这些都是通过苹果设备中存在的另一个硬件功能实现的。新款苹果设备中的系统芯片中存在这样的硬件功能,它可以完全绕过基于硬件的内核内存保护。你只需要写入目标地址、写入数据以及写入数据的哈希到未知的内存映射硬件寄存器中,这些寄存器未被固件使用。

苹果的系统芯片不仅仅是一个CPU,还集成了许多不同的外设,打包成一个芯片。它只使用其中很少的一些外设,通过特殊的内存映射硬件寄存器与它们交互。基本上,这些是位于内存特定地址的硬件设备的寄存器。这些地址存储在特殊的设备树文件中。漏洞利用使用了6个我找不到任何信息的未知寄存器。我检查了不同设备和固件版本的设备树,都没找到。我检查了内核镜像、内核扩展、iBoot固件、协处理器固件,寻找对这些地址的任何直接引用,但一无所获。最后,我发现苹果M1和M2芯片也有这个硬件功能,映射到完全相同的地址。我用过很多专门的工具来跟踪对特定区域的所有访问,它也没有报告任何使用。那么攻击者如何使用一些未知的、从未在任何地方提及过的硬件寄存器呢?

我得到了一个主意,也许检查一下这些未使用寄存器周围映射的内存区域是什么,很快我就找到了匹配。我们有一个GPU处理器,它有两个内存映射寄存器区域,与攻击者使用的区域非常接近。看起来非常像这样,我们有两个已知的GPU处理器内存映射寄存器区域,然后是一个攻击者使用的区域,位于它们之间;另一个块也靠近第一个已知GPU区域。这很有可能与GPU处理器有关。事实上,之后我能够证实这一点。

让我们看看漏洞如何使用这些寄存器。这个与其他所有寄存器不同,你可以看到它在一个单独的块中,只在漏洞利用的初始化和终止阶段被访问。根据我的经验,我知道它要么启用要么禁用被利用的这个功能,或者只用于控制中断。我决定采取第二种猜测,很快就能识别出这段代码。

右边你可以看到与M CPU的核心调试寄存器交互的代码。M CPU有多个核心,这些硬件寄存器的地址实际上存在于该设备的设备树中。那么核心侧是什么?这是ARM开发的一个特殊的硬件块,也存在于苹果处理器中。它有一个特殊的块叫UT,苹果声称这是他们自己的专有技术,但其实就是放在核心侧块中以方便使用。这样,我能识别出左侧代码实际上是与GPU处理器的核心调试寄存器交互。

到目前为止,我解开了一半谜题,但直到今天,我仍然不知道攻击者使用的第二个块究竟是什么。我们知道这个寄存器用于保持和运行GPU处理器,那么其他寄存器呢?这两个用于启用和禁用该功能。这个只针对A15和A16设备。这两个最有趣:一个用于设置目标地址的低半部分和标志位;一个用于设置数据和数据的哈希值,与目标地址的高半部分和某种命令组合。它们是这样一起使用的:数据需要以64字节对齐的块写入;所有数据需要顺序写入到该寄存器;目标地址的高半部分和哈希也需要写入。

这样可以做什么呢?可以修改页表条目,在用户层注入代码;可以修改受PPL保护的数据段中的数据;甚至可以修改内核的可执行区域,绕过所有基于硬件的内核内存保护,但是必须知道如何计算这个密钥哈希值,这不是CRC。如果我不告诉你这个哈希算法,你将无法验证我说的任何内容。

你可以看到这是一个自定义的哈希算法,使用预定义的替换表,非常简单,只占10比特,计算起来一共20比特,但如果你不知道这个算法,你将无法使用这个功能。同样,如果你不知道以什么顺序向什么地址写入什么值,你也无法使用它。就像它的安全说明所说,只要没人知道它,它就很安全。

目前我们不知道攻击者是如何发现这个功能的,它的原始目的是什么,是苹果开发的还是某第三方公司像ARM的核心侧。也许苹果甚至不知道他们的处理器中存在这样的东西。事实上,这个漏洞与我在2019年CCC上讨论的一个很相似。当时我演示了如何通过内存映射的DRM寄存器破解索尼播放站蓝光光驱。索尼通过这些寄存器访问所有DRM,但后来他们停止这样做,直接通过绝对地址访问DRAM,因为它被完全映射到了SoC地址空间。但我知道如何使用这个功能,因为我在早期版本中看到过它。由于没有人在固件中使用它,我就利用了它。

这个案例中是否也可能发生类似的情况呢?老实说,我不知道。也许是苹果意外发布了一些内部信息,然后将其删除。也许发生过类似的事情,但我不知道,这就是我需要其他iOS安全研究人员的帮助的原因。我们可能可以一起解开这个迷题。

我非常期待了解苹果如何修复这个漏洞。我发现他们是这样缓解的:他们在设备树中有一个特殊表格,包含禁止映射的内存区域,有起始地址、大小、标志和标签名等信息。表中的所有条目都非常具体,你可以看到受保护的内容,如PCI配置空间、设备地址解决表等等。为了修复这个漏洞,他们需要做的是......

因为它仍会永远存在于SoC的寄存器中,苹果只从新版本中删除它。苹果添加了两个新条目,它们看起来像这样:标签名称不太具描述性,与其他区域的内容明显不同。

非常复杂的攻击链,攻击者可以为所欲为,如生成进程、注入恶意软件、修补内存中的任何内容等。但攻击者做了一些不同的事情。他们生成了两个进程,一个注入到Safari中,只做一件简单的事,让Safari打开一个提供的网页链接,这就是验证器页面,就像Leo一开始向你展示的那样,首先验证受害者,获取指纹信息,如果是正确的受害者,提供另一个阶段的漏洞利用,是一个Safari的0day漏洞。之后它执行一个shellcode和另一个完全不同的内核提权漏洞,只有一些部分是相同的,大部分代码都不同,体积非常大,具有大量功能,有些功能甚至没有使用,因为攻击者忘记去除未使用的函数。但总而言之,它非常不同。之后,攻击者再次验证受害者,以确保它是他们想要感染的准确目标。只有在所有这些之后,他们才提供实际的恶意软件。

所有的这些额外的复杂性是完全不必要的,但攻击者这样做是为了确保没有人知道最后阶段的恶意软件到底是什么。所有这一切只是为了保护这个恶意软件,所以没有人会发现最后一步的内容。

现在我的同事Georgi将为您详细讲解这些恶意软件。

这个恶意软件由内核提权漏洞部署,非常迷人。比如,让我们看看这个验证组件。如果你开始逆向工程,你会立即发现它运行几个操作,开发人员甚至将这些操作的名称留在了代码中,这样就很容易理解它们的作用。

从这个列表中你会立即识别出,这个验证程序删除各种日志和痕迹,获取诸如网络接口和已安装应用程序等信息。

对于日志删除,验证程序从特定进程中删除崩溃日志,这些进程在利用过程中可能产生崩溃日志,属于诸如iMessage、网页浏览器和恶意软件本身等组件。这样可以确保取证研究人员无法获取这些日志,推断漏洞的工作方式。除了删除崩溃日志,他们还清除了用于发送exploit链的恶意iMessage的痕迹。为此,他们获取所有收到的iMessage列表,对每个iMessage获取发送者的Apple ID,计算这个Apple ID的MD5哈希,并与40个MD5哈希进行匹配。如果匹配,表示这条消息来自攻击者,需要被删除。这样可以使通过备份分析获得漏洞附件变得不可能。

从ATT的角度来看,在验证代码中包含这40个哈希不是很明智,因为如果你有足够的时间,可以破解这些哈希,得到攻击者使用的Apple ID列表。这正是我们所做的,我们成功恢复了大多数电子邮件地址,并最终暴露了攻击者。当然,我们已将这些电子邮件报告给苹果进行调查。

在执行日志清理后,验证程序开始收集有关被感染设备的信息。它检查设备是否越狱,其代码能检测所有常见的越狱方法,如Pangu、Unc0ver、checkra1n等。此外,它还可以检测在越狱设备上常见安装的软件,如Cydia或iFile。另外,在感染过程中,它还会检查漏洞是否在Corellium上运行。Corellium是一个可以在云端运行iPhone的平台,常被用于安全研究。如果发现漏洞在Corellium上启动,它们将不起作用,攻击者还会收到通知。

如果你仔细看幻灯片,除了检查设备是否越狱,你可能还注意到代码中有一个未使用的操作,叫做PSP检测。既然未使用,我们需要找出PSP检测的含义。首先PSP让我们联想到 PlayStation Portable,一种过去十年受欢迎的游戏机,但为何要在iOS上检查PSP呢?是否是攻击者在检查受害者是否是一个游戏爱好者。但是,如果我们从网络安全的角度看PSP,它代表个人安全产品,也就是杀毒软件的高大上说法。但是iOS上没有杀毒软件,还是有在Mac OS上工作的安全产品,所以这个在iOS上未使用的操作可以用来检测Mac OS上安装的安全解决方案。因此,“三角行动”可能也以Mac OS计算机为目标。这说得通,因为iOS和MacOS共享相同的XNU内核,如果一个漏洞能在iOS上运行,适配到MacOS上也不是很困难。

在所有这些检查之后,验证程序还收集有关被感染设备的大量信息,如用户名、Apple ID、序列号等,所有这些信息被发送到C2服务器,用于评估受害者是否是正确的目标。如果检查全部完成,受害者确实是预期的,则攻击者部署最终有效载荷,一个名为“triangle DB”的复杂APT平台。当我们查看这个平台的代码时,发现它可以在10年以上的旧版iOS上运行,这一数字表明该代码已经使用了很长时间。

这个平台当然用于网络间谍活动,它通过从C2服务器下载的插件收集数据,旨在从你的手机窃取几乎所有信息。它可以访问麦克风、摄像头、密码、钥匙串、通讯录、系统中的文件以及地理位置数据。此外,它还请求操作系统的权限来访问与感染手机相近的其他设备列表。我们还观察到triangle DB窃取诸如WhatsApp、Telegram和iMessage等即时通讯软件的数据。这些插件的代码本身也非常有趣,例如录音插件以一种自定义格式写入输出数据,同时包括录音过程中发生的事件信息。这个模块只在受害者屏幕关闭时录音,很难用肉眼检测到。另外,如果它发现有人正在读取系统的事件日志,它会关闭自身并通知攻击者,可能已经暴露。

我希望通过和您分享所有这些信息,能让您相信,攻击者从受感染手机中收集了大量信息。

但是这里有一个问题,攻击者收集这些信息后如何分析它呢?他们必须处理吉字节甚至太字节的数据。例如,当我们在像CCC这样的活动中旅行时,我们会拍很多照片,每天成百上千张照片。例如,就照片而言,攻击者如何找出对他们有用和无用的照片呢?

这个问题的答案实际上是机器学习。我们发现了一个插件,它使用苹果的神经网络引擎从保存的照片中提取元数据。让我展示它的工作原理。每当您在相册中保存一张图片时,苹果的机器学习模块就会开始分析它。例如,对于您在此看到的这张照片,该引擎设法发现它包含椰子、沙滩、水和吸管。此外,该引擎可以执行光学字符识别,在照片上检测文本。例如,在这张照片中,它设法检测到椰子上刻着的“小海滩”字样。除此之外,它还能检测图片中的动物,并识别相册中是否存储了文档。攻击者获取所有这些标签,并将它们发送到C2服务器进行进一步分析。在我看来,这非常令人印象深刻,因为这实际上是我们第一次看到威胁行为者使用机器学习来分析窃取的数据。

最后,我们要说的是,请收集和检查家用网络日志,这非常简单。只需要谷歌一下如何做就可以了,你应该在家里做到这一点。当然,你在工作中也应该这样做。安全性的保密性是行不通的,因为最终一切秘密都会被发现。如果你开发了非常先进的、基于硬件的内存保护,使利用非常困难,那么你就不应该有可以完全绕过它们的简单方法。我们也期望机器学习和AI技术的采用会有所增长,当所有设备都支持这些技术时,恶意软件也将利用它们,借助机器学习,它们将非常容易获取有关你的所有信息,只需询问你设备上的机器学习对你有哪些了解。我们当然应该为此做准备,想出解决方案。非常感谢大家!

======================================================

问答环节:

Q:是的,互联网对你的演讲反响强烈,表示了极大的感谢。这里当然有一个关于归因的问题。你对此有什么见解,可以分享什么吗?

A:嗯,如果我们没有非常有力的证据,我们从不对归因进行猜测。不幸的是,在这种情况下,我们没有这样的证据。这是我们的座右铭,当我们不确定时,我们从不做任何猜测。

Q:非常感谢你精彩的演讲,观察你的工作过程与分享非常有趣,这真的很好,非常感谢!我有一个与第一个问题相关的简短问题,对于不能运行脚本或不知道编程的用户,从你的经验来看,他们是否可以通过视觉手段检测到手机的异常行为,并意识到出问题了?例如对于非技术人员?

A:我认为......谢谢你的问题。我认为所有证据都是隐藏的。唯一的选择是做一个备份,并尝试找到我们讨论过的指标。很遗憾,由于iOS是封闭系统,如果你的设备遭到非常复杂的攻击,没有简单的方法发现它是否被入侵。如果你使用感染的设备,它不会显示任何被入侵的迹象。恶意软件只是默默运行在后台,感觉非常好。发现这种复杂攻击的唯一方法是使用网络日志或获取备份,并尝试看看是否有什么可疑之处。

Q:我有一个关于魔术MMIO寄存器缓解的问题。这是由硬件强制执行的还是由PPL内核例如完成?如果你有PPL绕过并可以映射任意物理内存,你仍然可以写入这些寄存器并修补内核吗?

A:他们的想法是苹果在内核中添加了特殊代码,我认为是pmap函数。基本上,它只是检查是否允许从这些阻止区域映射内容。主要思想是攻击者不应使用这些区域中的内容来绕过PPL,但如果攻击者已经拥有PPL,他们可能可以利用它并将其用于KTR绕过。这需要进一步检查。

Q:首先,非常感谢你的精彩演讲。我想问这个漏洞是否仍适用于A17,是否已打补丁。

A:今天我们讨论的所有漏洞都在......iOS 16.6中打了补丁。我们等待了半年以确保所有设备都很安全。所以如果每个人都更新了,你会完全安全。但如果你想越狱手机,我相信其他研究人员将能够使用其中的一些内容来创建越狱工具。我具体问的是MMIO寄存器,它们是否完全消失了。不,这种缓解措施是在iOS 16.6中发布的,早于A17。

Q:那么,整个研究从检测到联系苹果报告全部内容花了你多长时间?

A:我想大概有半年多一点。

Q:你的演示文稿中暗示可以重新启用广告跟踪。你发现了任何可疑的广告跟踪流量吗?

A:关于广告跟踪,我们不确定他们为什么要这样做。我们有一些奇怪的理论,比如也许他们会通过这种广告跟踪方式传递其他漏洞利用,但没有证据,我们也不知道为什么他们需要这些信息,为什么需要启用广告跟踪。这很神秘。我认为这可能是因为该系统主要侧重于通过Web漏洞感染受害者,但在某些时候他们需要零点击功能,所以将这两个系统组合在一起对他们来说很容易,而不必花时间对其进行开发或调整。我认为重点是通过Web感染设备,可能在广告跟踪的帮助下。

Q:你暗示可以将iOS漏洞移植到MacOS。你看到过任何证据吗?

A:关于Mac漏洞利用,除了PSP之外,也有更多迹象表明它适用于MacOS。后门中有一个“populate config”字符串,只用于Mac。代码中有很多字符串提示Mac的存在。但我们没有在MacOS上看到漏洞利用。但是代码中有很多证据提示这一点。

从理论上讲,需要跨越多大的鸿沟,将iOS漏洞移植到MacOS?如果我们谈论基于苹果芯片的Mac设备,那么利用基本上是相同的。但iPhone比Mac更安全,因为Mac设备没有实现基于硬件的内存保护PPL。在Mac上,注入代码到其它处理器是可行的。

Q:首先,非常感谢你的精彩演讲。我想问这个漏洞是否可以持久化,例如通过重置iPhone并恢复备份,它是否仍将持续存在

A:?由于iOS系统的缘故,没有办法在系统上实现持久化,这个漏洞也没有使用它。所以在重启后,攻击者需要再次感染设备。

Q:谢谢你的演讲。我的问题是,近期的iOS版本引入了锁定模式这一安全特性。我想知道漏洞链的任何部分是否会被锁定模式缓解,如果是,是哪些部分?这一点我不太确定,因为我知道锁定模式阻止了一些特定的功能,但我认为这些系统调用会被所有进程使用,所以可以从WebKit容器、SpringBoard等执行它们。我认为锁定模式不太可能阻止这类攻击,但如果我们谈论恶意附件,它可能有助于阻止下载。这需要进一步调查。

Q:谢谢你的演讲。我只是想问除了读取事件日志之外,还有没有其他触发AP卸载的方式?

A:嗯,可以通过多种方式卸载它,例如从另一台手机运行漏洞利用,攻击者会觉得可疑而将其卸载;从越狱固件运行也可视为可疑,进行可疑操作就会立即感染失败。这在高级持续威胁中很常见。具体来说,我们只看到它在记录系统事件日志时停止。

往期精选

围观

威胁猎杀实战(六):横向移动攻击检测

热文

全球“三大”入侵分析模型

热文

实战化ATT&CK:威胁情报


文章来源: https://mp.weixin.qq.com/s?__biz=MzU0MzgyMzM2Nw==&mid=2247485278&idx=1&sn=9def52d0d9063e86acb16533be2a52e8&chksm=fb04c436cc734d20b8c67348f7db21fa10921ad3826b37c713e847b73972f50de82b6c1f1e6b&scene=58&subscene=0#rd
如有侵权请联系:admin#unsafe.sh