2017-09-08 14:03:35
阅读：441次
点赞(0)
收藏
来源： martinvigo.com
作者：WisFree
译者：WisFree
预估稿费：200RMB
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
写在前面的话
本系列文章分上下两集，上集将对苹果Call Realy服务的运行机制以及协议内容进行阐述，并让大家对该协议有一个大致的了解，而下集将会告诉大家如何利用该协议中的安全漏洞来对目标用户展开间谍活动。
介绍
苹果在iOS 8和Yosemite中引入了一套名叫“Continuity”的新功能，这些功能将允许iPhone与其他例如Mac和iPad之类的苹果设备以一种新型的方式协同工作。实际上，苹果的Handsoff、即时热点以及Airdrop等功能和服务都是由Continuity提供的。在这些新服务中，有一个名叫“Call Relay”的服务。从本质上来说，该服务允许用户使用其他的苹果设备来拨打或接听电话。该功能并不是传统的VOIP服务，因为它是一种基于专项协议的P2P通信链接。
为了能够正常工作，参与通信的双方设备（iPhone跟其他拨打/接听电话的苹果设备）需要处于同一WiFi网络中，而这个特性引起了我的注意。苹果的安全白皮书对于这部分功能的介绍内容并不多，文档中只有四小段内容介绍了Call Relay的工作机制以及相关的安全信息，其内容大致如下：“通话音频将会从你的iPhone手机无缝传输（使用一种安全的点到点连接）到其他苹果设备上。”
工作机制
我们先要从整体上了解这个协议的运行机制，以及参与通信的设备所使用的交互方式。现在，我们假设有人给目标用户拨打了电话，他的iPhone手机响了，但他选择使用MacBook来接这通电话。
接下来，我们还要区分不同场景下的通信参与方。
首先，基站会与iPhone通信并处理来电通话。接下来，iPhone的来电铃声便会响起，并给苹果推送一条来电通知。苹果的Push Notification Service（APNS-推送通知服务）会给登录了相同苹果ID的所有苹果设备推送这条来电通知，并告知这些设备该用户目前有一通来电等待接听。MacBook所接收到的推送通知中包含iPhone的内部IP和端口，并将来电对方的信息以及通话选项（接听/挂断）显示给用户。最后，MacBoos会将第一个数据包通过局域网发送给iPhone（IP地址），并等待响应。接下来，P2P链接会成功建立，然后在MacBook和iPhone之间传输通话语音数据。
场景分析
该协议可以在上图所示的三种场景下工作，即GSM、互联网和本地网络，但我们的分析重点将主要放在本地网络场景中。
实现方法
首先，我需要在相同环境下（相同设备、苹果ID、手机号码和拨号方式）收集来电信息样本，这样我就可以通过对比字节数据来找出发生改变的地方。除此之外，我还收集了很多不同环境（稍有改变）下的数据样本以便我通过分析识别出操作系统版本和用户ID等信息。
想要手动完成这些操作肯定是很困难的，因此我们这里需要使用到一款名叫Netzob的工具。简单来说，Netzob可以帮我们通过识别模式、数据格式和接口来对协议进行详细分析（使用了复杂的数学模型和静态分析技术）。换句话说，我们只需要将数据样本导入至Netzob，它就可以帮我们把数据格式化导出，并显示数据之间的关系。
注:在这篇文章中，我不打算对该协议的逆向分析过程进行详细描述，因为我们的目的是为了寻找该协议中存在的安全漏洞，因此我所介绍的内容都是为这一目标服务的。如果你想了解更多相关内容，请参考我在Ekoparty的一次演讲（西班牙语）或卡巴斯基实验室的安全分析结果。
苹果的Call Relay协议
我是用Scapy编写了一些脚本【脚本地址】，并用脚本来模拟iPhone和MacBook，这样不仅可以帮助我识别出某些初始攻击向量，而且还有助于我找出该协议中存在的其他漏洞。
该协议由以下四个处理阶段组成:
发现阶段
上图显示的是来电时MacBook发送给iPhone的第一个数据包，iPhone会等待接收这个数据包，接收之后它便会翻转四位字节数据，并将其回传给MacBook，整个过程类似于一次SYN-ACK。
识别阶段
接下来便是识别阶段中的另外两个数据包，这一次，iPhone在响应时会修改两个字节的数据，但最有意思的地方在上图中的Field 9部分。这些字节数据全部都在可打印的范围内，将其格式化为字符串之后，我们发现它其实就是一个UUID。更重要的是，我们竟然找到了一个未经加密的文本，而我们接下来就可以对这些字节数据动手脚了。
协商阶段
首先我们可以看到，header从原来的“0f”变成了“2004000400”，这就表明我们处于该协议的另一个处理阶段了。先看上图中的红色方框部分，MacBook和iPhone通过交换四个字节数据得到了一个双方都认可的八字节随机数据。MacBook生成并发送了前四个字节，而iPhone以相同的方式予以响应。在接下来的数据包中（绿色部分），我们可以看到MacBook使用了双方认可的字节数据来作为某种计数器（最后一位字节数据每次加1）。
另一个有趣的部分是橙色标注的区域，这部分内容可能代表的是该阶段中数据包的不同状态，因为它们的header都是一样的。
声音传输阶段
跟之前一样，我们可以观察到数据包的header从原先的“2004000400”变成了“e000”，这表示我们又进入了该协议的另外一个阶段。跟刚才的识别阶段类似，我们可以发现Field 1-1中显示的是一个按次序递增的十进制计数器。在我的测试过程中，计数器会每二十分钟更新一次，并在来电通话的过程中传输大量的数据包。这个过程很可能是用于实现加密处理的，目的估计是为了防止重放攻击的发生。
Filed 1-2-1代表每一次通话的静态值，每一台设备的这个值都不同。通过对协议进行逆向分析并模拟拨打了数百通电话之后，我发现这个值并不是随机值。因为它总是在增加，但我还不清楚这个值是基于什么生成的。最后蓝色框框里面的数据就是纯粹的随机字节了。
寻找安全漏洞
既然我们已经大致了解了苹果Call Relay协议的大体工作流程以及内部运行机制，那么我们就可以开始尝试寻找协议中可能存在的安全漏洞了。在寻找漏洞的过程中，我们一定要保持思路清晰，不然你很可能会迷失方向，然后又不得不从头开始。
在测试的过程中，我尝试进行了以下几种操作，但是都以失败告终了：
窃听正在进行的通话
解码/解压缩/解密语音Payload
进行重放攻击
将语音Payload重定向至攻击者设备
伪装成目标用户拨打电话
注入语音Payload
但是下面这几次操作尝试都成功了：
DoS语音拨号
通过打开目标用户手机的麦克风来对其进行窃听和监视
模拟多方通话来电
总结
在这篇文章中，我们对苹果的Call Relay协议已经有了一个大致了解，在本系列文章的下集中，我们将告诉大家如何利用这些漏洞来展开攻击，并自行动手制作一款间谍工具，感兴趣的同学请及时关注安全客的最新文章。
本文由 安全客 翻译，转载请注明“转自安全客”，并附上链接。
原文链接：http://www.martinvigo.com/diy-spy-program-abusing-apple-call-relay-protocol/
