.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
今年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附加組件。