【技術分享】如何利用蘋果的Call Relay協議DIY間諜軟件（下）含視頻
譯者：WisFree
預估稿費：200RMB
投稿方式：發送郵件至linwei#360.cn，或登陸網頁版在線投稿
傳送門
【技術分享】如何利用蘋果的Call Relay協議DIY間諜軟件（上）
寫在前面的話
本系列文章分上下兩集，上集將對蘋果Call Realy服務的運行機制以及協議內容進行闡述，並讓大家對該協議有一個大致的了解，而下集將會告訴大家如何利用該協議中的安全漏洞來對目標用戶進行監控，並自行動手製作間諜工具。
DoS來電通話
雖然這種攻擊方式的影響並不算非常大，但是它仍然能夠體現出模糊測試的實用性。在這種攻擊場景下，我可以偽造一個數據包，並終止任意目標用戶的任意來電通話。也就是說，你只需要發送一個數據包，目標用戶的來電通話就會立刻被掛斷。還記得我們在本系列文章的上集中所介紹的Call Realy協議的不同處理階段嗎？我突然想到，如果我向目標設備發送不同階段的數據包，會發生什麼？比如說，在“聲音傳輸階段”發送一個“通話協商階段”的數據包。實際上，在這種情況下協議並不會處理不符合條件的數據包。當iPhone開始處理一通新的來電時，如果Macbook發送了其他類型的數據包，則通話將會終止。
現在的問題就是如何偽造一個數據包，我們需要這個數據包能夠在事先不知道通話ID之類信息的情況下適用於任何通話來電、用戶和設備。正如上圖所示，我選擇了通話協商階段的第一個數據包，它包含多個與當前通話相關的數據域。為了保證iPhone不會忽略我們的數據包，我需要對其中的部分字節數據修改為空（“0”）。嘗試多次之後，我們得到了下面這個神奇的DoS數據包：
20040004000000000000000000b002000000000000000000000000000000000000000000000000000000000000
我們需要注意數據包的長度，數據包header和b002數據域看起來應該是數據包的類型識別符。如果你將這個數據包發送給iPhone或MacBook，那麼通話將會立刻終止。你可以用它來對目標設備進行泛洪攻擊，並利用該協議來防止用戶接聽電話。
通過麥克風監聽用戶
其實這個才是我的主要目的，即通過手機麥克風來監聽用戶。我進行了大量的嘗試，結果如下：
1. 我無法竊聽通話
2. 我無法注入語音數據
3. 我無法重放通話數據
4. 我無法重定向通話
5. 使用加密
所以說，如果我沒辦法訪問到語音Payload的話該怎麼辦呢？此時，我突然想到了Adi Shamir的一句名言：“在未來，加密算法最大的一個問題並不是會被攻擊者所破解，而是被繞過。”
因此我意識到，也許我需要找到某種側信道攻擊方法來訪問目標用戶的語音信息。此時，我開始思考整個過程中電話掛斷是如何進行的。我認為，如果我在MacBook上掛斷電話，那麼系統則會向iPhone發送一條信息或某種特殊的數據包來通知設備此次通話已結束。我收集到的網絡數據（包括通話結束）如下所示：
我能看到的只是語音Payload數據包停止發送了，這就非常奇怪了，因為MacBook總得要通知iPhone通話一結束吧？因此我再對網絡追蹤數據進行了分析，此次分析數據包括APNS流量：
果然沒錯，掛斷通話時系統向APNS發送了一些數據包。實際上，當你在MacBook上掛斷電話之後，系統並不是使用P2P鏈接來向iPhone發送信息的，當我們點擊“掛電話”之後，MacBook會向蘋果發送一條推送通知。接下來，蘋果會向iPhone發送另一條推送通知，通知內容都是一樣的。此時，iPhone便會關閉相應端口並終止通話。當通話掛斷之後，MacBook將無法在與iPhone通信了。
這種設計存在很大的問題，即蘋果通過這種非常不安全的通信信道（APNS）來實現了Call Relay協議，而且蘋果自己也表示：“推送通知並不能保證被成功送達，請不要在敏感操作中使用推送通知。”
但是蘋果自己都沒有遵守自己的實踐建議，而且OWASP Top 10（移動端）中也描述了這種安全問題。
那麼接下來的問題就是，我們如何去利用這種設計缺陷？如果我能夠阻止“掛斷”消息被送達，會發生什麼呢？
通過利用ARP欺騙+中間人攻擊，我能夠屏蔽掉目標用戶所發送的全部APNS流量。此時，蘋果既無法得知用戶是否掛斷了電話，也無法通知iPhone。從用戶接口層來看，目標用戶不會發現任何可疑的跡象。但問題就是，負責處理通話的守護進程會在後台保持運行，而通話永遠都不會被掛斷。對於用戶來說，他們會認為通話已經結束了，但實際上通話仍在進行中，而攻擊者則在另一邊持續監聽着。
演示視頻如下：
視頻地址：https://youtu.be/zx0wDshqb7o
在多方通話中偽裝用戶
當我發現蘋果使用推送通知來發送重要消息時，我又注意到了該協議還支持多方通話。因此，如果當你正在通話並且此時又有人給你打電話，那你就可以隨時根據自己的需要來切換通話了。
實際上，“切換通話”的信息也是通過推送通知來發送的。這也就意味着，攻擊者將能夠阻止信息被送達，而目標用戶將會看到UI界面發生改變，並認為自己已經成功切換了通話。如果我們能夠結合這兩個問題（切換通話+掛斷電話）來利用該漏洞的話，那麼這種功能就非常的強大了。
簡單來說，處於同一網絡下的攻擊者將能夠通過分析目標用戶的網絡流量來檢測當前正在進行的通話。接下來，攻擊者可以給目標用戶打電話，並替換當前通話。攻擊者需要等待用戶切換通話，但是他們還可以屏蔽掉切換通話狀態的數據包。此時的UI界面顯示的是目標用戶之前的通話方，但實際上攻擊者仍然正在跟目標用戶通話。
演示視頻如下：
視頻地址：https://youtu.be/vsHGL8lDsho
漏洞利用
為了利用這些安全漏洞來實現我們自己的監聽程序，下面有幾個要求是我們必須要滿足的：
1. 我們只能針對蘋果設備發動攻擊；
2. 我們必須能夠發送APNS數據包；
3. 我們需要知道目標用戶的手機號碼；
總結
由於篇幅有限，因此關於“如何檢測網絡內的蘋果設備”、“發送APNS數據包”以及“如何得知目標用戶的手機號碼”等內容請大家移步原文查看。
時間軸
跟之前一樣，我將我的所有發現負責任地披露給了蘋果公司。雖然漏洞的上報和修復過程遇到了各種各樣的問題，但最終這些安全漏洞都成功修復了。根據蘋果公司的安全公告，iOS 10.1和MacOS 10.12.1均已修複本文所介紹的全部安全問題。
蘋果發布的四個漏洞CVE編號如下：
CVE-2016-4635
CVE-2016-4721
CVE-2016-4722
CVE-2016-7577
本文由 安全客 翻譯，轉載請註明“轉自安全客”，並附上鏈接。
原文鏈接：http://www.martinvigo.com/diy-spy-program-abusing-apple-call-relay-protocol/