今年6月，卡巴斯基的研究者就发现有攻击者利用iMessage来传播恶意软件，iOS 15.7以及此前版本均受到影响。研究人员通过mvt-ios（iOS 移动验证工具包）分析受攻击的设备之后，发现他们可以通过iMessage发送信息，受害者在接收到信息之后，不需要任何用户交互，就能触发系统内漏洞，从而执行任意恶意代码。研究人员将这个攻击活动称为 "Triangulation活动 "。

Triangulation活动的首次公开报道请看这篇文章，正如研究人员在三角测量行动的第一篇文章中提到的，最初发现的受攻击设备正是在莫斯科总部工作的卡巴斯基员工。所有这些设备都连接到公司的Wi-Fi网络，这样研究人员就可以记录和检查网络流量。在花了一些时间调查Wireshark之后，研究人员最终发现了以下内容：

1.在表现出可疑行为之前，连接到iMessage服务器的设备通常负责接收信息和下载附件；

2.在下载了可能是附件的几千字节数据后，这些设备建立了与服务器backuprabbit[.]com的连接，在不到一分钟的时间内与服务器交换数据；

3.接下来，设备连接到以下服务器进行更长的会话：

cloudsponcer[.]com

snoweeanalytics[.]com

topographyupdates[.]com

unlimitedteacup[.]com、

virtuallaughing[.]com

4.设备重启后，所有可疑活动都停止了；

所有与服务器的通信都是通过HTTPS进行的，所以研究人员无法从流量中恢复任何额外的细节。

设备映像

由于所有的设备都触手可及，研究人员下一步就是检查它们的内容。不幸的是，研究时可用的取证采集软件基于checkra1n和类似的漏洞，不适用于运行iOS 15和16的现代处理器。

检查备份

研究人员下一步决定使用设备的iTunes备份来代替完整的设备映像，这一程序必须在相当保密的情况下进行，以免提醒攻击者。

由于研究人员不知道攻击者的确切能力，只能默认他们在监听设备的麦克风，阅读电子邮件和即时通信对话。所以，研究人员不得不亲自安排会议，把手机放在飞机模式下，有时放在法拉第包里。研究人员使用libimobiledevice的优秀工具来获取备份，并通过使用移动验证工具包构建事件时间轴来检查它们，该时间轴结合了文件系统时间戳和从各种系统数据库中提取的数据记录。研究人员专注于iMessage目录，因为早在2021年，Citizen Lab的研究人员通过检查这些目录中的文件发现了FORCEDENTRY漏洞。

Triangulation活动背后的攻击者非常隐蔽，研究人员在备份中没有发现任何漏洞利用的迹象，他们还搜索了恶意软件的可执行文件，但也没有找到。

不过，研究人员还是发现了可疑网络活动的时间戳。为此，他们开始寻找时间轴上发生在同一时间的重复事件。结果，研究人员发现了一个看起来像新指示器的东西，数据使用记录提到了一个名为“BackupAgent”的系统进程，不过这个进程根本不应该被执行，因为二进制文件在几年前就被弃用了。

在设备日志中观察到的来自BackupAgent进程的异常活动，研究人员在Triangulation 活动的第一篇文章中就分享过这个片段。

基于这个异常的发现，研究人员编写了第一版的triangle_check工具，它使研究人员能够快速确认设备的备份是否包含潜在攻击的痕迹。

试图拦截恶意iMessage

进一步查看事件时间轴，研究人员发现了第二个痕迹，在BackupAgent进程使用数据之前，修改了一个空的SMS附件目录。由于目录被修改了，但不包含任何文件，这通常意味着可以高度肯定最后一个操作是文件删除，有一个传入的附件，它被删除几秒后，名为BackupAgent的进程正在运行可疑的网络代码。

由于Triangulation 活动背后的攻击者似乎足够聪明，可以从受攻击的设备中删除恶意附件，因此研究人员决定尝试在iMessage传递过程中捕获传入消息。在寻找拦截imessage的方法时，研究人员发现了谷歌Project Zero团队编写的Frida脚本。它是为Mac电脑设计的，所以研究人员拿了一台备用的Mac mini，在上面安装了Frida。然后，研究人员要求几位目标同事用他们的苹果id登录Mac mini。这样，研究人员能够监控和拦截他们收到的imessage，接下来要做的就是等待攻击者再次攻击。

与此同时，研究人员积极监控SIEM日志，寻找可疑活动的痕迹。很快，研究人员就发现了熟悉的网络连接，这表明一款带有iMessage帐户的手机成功攻击。然而，当我们检查Mac mini上的iMessage拦截日志时，却没有消息痕迹。因此，系统无法捕获可能包含漏洞的消息，所以我们开始寻找其他方法来捕获恶意软件。

在通过Mac设备拦截iMessages的计划失败后，研究人员决定尝试解密之前从流量分析中识别出的C2服务器的HTTPS通信。

为此，需要做到：

搭建Linux服务器，安装HTTPS拦截工具mitmproxy；

在几个已知被攻击的iOS设备上安装了根SSL证书(研究人员之前通过mitmproxy生成的)；

在这些设备上安装Wireguard VPN客户端，并配置它们使用研究人员的mitmproxy实例作为VPN服务器。

研究人员还开发了一个Telegram机器人，当受监控的设备被攻击时，它会通知研究人员：

不幸的是，这种方法不允许研究人员拦截苹果服务(包括iMessage)的HTTPS流量，因为iOS为此实现了SSL绑定。因此，研究人员无法解密来自VPN的iMessage流量。

捕捉JavaScript验证器

一旦攻击者再次攻击了其中一个目标，研究人员查看了mitmproxy日志，注意到它成功地解密了C2服务器的流量：

研究人员希望获得的有效负载是iOS的漏洞。但是，它是JavaScript验证器，它只是收集有关受害浏览器的信息并将其发送到C2服务器。

研究人员观察到受攻击的设备接收响应发送到C2服务器的验证信息的有效负载。然而，虽然研究人员能够拦截HTTPS流量，但无法解密它。这是因为JS验证器使用NaCl库为C2通信实现了自己的加密层，使用的加密算法基于公钥加密。具体来说，为了与C2服务器通信，JS验证器如下：

1.生成一个随机密钥对(由私钥和公钥组成)；

2.从生成的私钥和C2服务器的公钥中派生共享密钥；

3.使用此共享密钥加密发送到C2服务器的消息并解密从C2服务器接收到的消息。

密钥生成

为了解密C2服务器通信，有必要知道由JS验证器随机生成的私钥。但是，这个密钥保存在内存中，不会被发送到C2服务器，所以研究人员必须做一些额外的工作来解密验证器的流量。

如上图所示，JS验证器通过调用nacl.box.keyPair()方法生成一个随机密钥对。为了解密流量，研究人员编写了一个很小的mitmproxy附加组件，用于查找对nacl.box.keyPair()方法的调用。然后用另一个方法nacl.box.keyPair.fromSecretKey()替换它们，该方法根据提供的私钥初始化对。

从上图中可以看出，研究人员将私钥硬编码到该方法的参数中，从而隐藏验证器的加密方案。一旦在受攻击的设备上执行了后门验证器，就可以解密JS验证器的所有通信。

二进制验证器和关于附件的提示

一旦攻击者再次攻击了其中一个目标，研究人员就能够分析验证器进一步执行的有效负载。结果发现它包含两个漏洞：一个针对WebKit，另一个针对iOS内核。这两个漏洞的最终目标是在目标设备上启动二进制验证器阶段。

如上所述，二进制验证器包含一个清除恶意iMessage痕迹的函数。具体来说，研究人员发现这个函数向SMS.db数据库发出以下SQL请求：

条件“uti==”com.apple.watchface“”给了我们另一个提示：现在很明显，恶意附件是.watchface文件。因此，通过更多关于附件的信息，研究人员计划并执行了获取附件的下一次尝试。

发送iMessage附件的过程

为了设计另一种获取附件的策略，研究人员决定更详细地研究发送iMessage附件的过程。这个过程包括以下几个步骤：

1.发送方生成一个随机的AES密钥并用它加密附件；

2.加密的附件被上传到iCloud；

3.iCloud加密附件的链接与AES密钥一起发送给收件人，AES密钥使用设备的公共RSA密钥进行额外加密。

因此，要获取恶意附件文件，研究人员必须检索两个组件：

1.加密的附件；

2.用于加密的AES密钥。

获取加密的附件非常简单，因为可以通过mitmproxy拦截到iCloud服务器的流量。之前，研究人员写过iOS不允许解密苹果服务的HTTPS流量，iCloud附件链接却是一个例外。

同时，AES密钥的获取过程相当困难。它是通过iMessage协议发送的，因此不能通过mitmproxy进行拦截。不过，研究人员发现了一种恢复附件的方法，并通过对目标设备的物理访问提取该密钥。研究人员使用iCloud链接阻止iMessage成功下载附件，因此该漏洞不会激活然后删除附件，但AES加密密钥将存储在SMS.db数据库中。

研究人员决定使用mitmproxy附加组件更改加密附件中的几个字节。这样，研究人员中断了下载加密附件的过程，解密密钥保存在SMS.db数据库中。然后，研究人员下载了受攻击设备的iTunes备份，并从该备份中的数据库中提取了密钥。结果，研究人员获得了攻击者发送的恶意.watchface附件，这是用于使用漏洞利用链的开始。

植入过程

在研究人员获得攻击者使用的漏洞之后，剩下的就是获得植入程序了。二进制验证器是负责从C2服务器下载和激活植入有效负载的组件，它使用RSA和AES的组合进行通信。同样，使用RSA意味着仅使用加密流量是不可能解密植入有效负载的。

为了与C2服务器交换数据，二进制验证器需要：

1.生成一个随机的AES密钥；

2.用验证器配置中指定的服务器的RSA公钥加密生成的AES密钥；

3.使用生成的AES密钥对要发送到C2服务器的消息进行加密；

4.向C2服务器发送加密消息，并接收C2服务器的响应；

5.使用用于加密发送消息的相同AES密钥解密响应。

验证器用以下ARM指令加密所有数据包：

这段代码首先执行“serialized_plist”函数，该函数为发送准备数据。执行之后，寄存器X0指向准备发送到服务器的数据。

下一个要调用的函数是“encryptData”。它有两个参数：一个指向正在加密的数据的指针被传递到X0寄存器，而X1寄存器包含一个带有配置数据(包括加密参数)的pllist。在执行这个函数之后，X0寄存器包含一个指向加密附件的指针。

为了破坏加密过程来拦截来自受攻击设备的数据。研究人员决定将对“encryptData”函数的调用替换为NOP指令(1f2003d5)。这样，X0寄存器的值将不会被指向加密数据的指针覆盖，并且验证器将向研究人员的VPN服务器发送明文数据。

就像JavaScript验证器的情况一样，研究人员通过扩展mitmproxy插件来修补代码：

使用NOP修补对encryptData函数调用的mitmproxy附加代码片段

当明文数据到达研究人员的VPN服务器时，他们会再次通过mitmproxy附加组件模拟密钥交换和数据加密，并控制加密密钥的值。结果，研究人员成功地解密了C2服务器发送的数据，并提取了植入程序。

获取模块

在对TriangleDB植入程序进行逆向工程后，研究人员发现它能够执行辅助模块，这让研究人员想要获得模块二进制文件。在对植入的分析中，发现模块可执行文件通过CRXUpdateRecord和CRXUpdateRunRecord命令传递给植入程序。因此，为了获得这些可执行文件，必须能够解密发送到C2服务器的所有命令。

同样，加密算法是基于RSA的，所以研究人员的操作类似于获取植入程序二进制文件的操作。

不过这一次，研究人员决定：

1.生成自己的RSA公钥/私钥对；

2.将植入配置中的RSA公钥替换为先前生成的公钥。

研究人员将以下代码添加到mitmproxy插件中：

当植入流量到达研究人员的VPN服务器时：

1.用研究人员生成的RSA私钥解密它；

2.保存解密后的流量；

3.使用攻击者使用的公钥对流量重新加密。

通过这种方式，研究人员能够监控由植入程序执行的所有通信，并获得模块二进制文件。

总结

研究人员调查Triangulation活动的过程相当漫长，总共花了几个月的时间。尽管经历了许多波折，研究人员最终还是设法获得了这次攻击中使用的所有阶段，包括向苹果报告的四个零日漏洞，两个验证器，一个植入程序及其模块。

在此过程中，研究人员对iOS内部进行了大量研究，并提出了许多有趣的技术，例如研究人员用于提取iMessage附件的技术。研究人员在研究过程中遇到的主要困难是处理在攻击链的每个阶段都使用的公钥加密。为了绕过加密，研究人员必须开发一个mitmproxy附加组件。

文章翻译自：https://securelist.com/triangulation-validators-modules/110847/如若转载，请注明原文地址