2017-09-19 15:02:16
阅读：225次
点赞(0)
收藏
来源： martinvigo.com
作者：WisFree
译者：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/
