iMessage Privacy (2)

发表于 | 分类于

MITM攻击

iMessage是很复杂的，它依赖于PUSH协议，以及所有的协议层都进行了大量的加密。在这一章节，我们将会研究对iMessage进行MITM攻击的条件。现在我们希望协议能够更加的透明。

为此，我们将会在很多地方设置一个攻击者：在发送者和苹果公司服务器之间，在苹果公司服务器和接收者之间。如果你希望获得一个快速简单的概述，或许你应该先看一下我们描述MITM的原始草图。

hand_schema

测试协议

正如之前所见，iMessage所使用的两个主要服务是PUSH服务器和ESS服务器。因此，为了进行攻击，我们需要冒充这些服务器。有很多方法可以实现，比如ARP欺骗和BGP路由注入（如果你可以的话），而我们只是简单通过修改/etc/hosts的方式，就像之前的PUSH代理一样。

以下是我们所使用的工具：

  • 能够运行下面工具的Python脚本
  • PushProxy，以及Quarkslab的imessage-mitm.py处理器，来截取iMessage
  • Quarkslab的ess-mitm.py，来截取和修改Apple ESS响应
  • 一个DNS代理软件。我们选择了dnschef。

从加密的角度来说，我们往目标keychain中添加了一个root CA，从而让我们可以使用我们自己的证书而不会被iDevice拒绝。

这样，我们就准备好了所有所需的工具。

单边MITM

现在，攻击者位于发送者和苹果公司服务器之间，并且在发送者的设备上。我们姑且把发送者叫做Dhillon，接收者叫做Belinda，在中间的那个坏家伙叫做Evil。我们将会一步一步得讲解是如何进行攻击的。

首先，我们先看看一下消息的传播：

mitm

  1. Dhillon给Belinda写了一条消息。
  2. Dhillon的iDevice向ess.apple.com发送请求。
  3. Evil截取到这个请求。
    3.1 Evil向ess.apple.com请求Belinda的信息（Push-Token，RSA和ECDSA密钥）。
    3.2 Evil将Bel的RSA和ECDSA密钥替换成自己的密钥。
  4. Dhillon向Belinda发送他的消息：这条信息用本来属于Bel的RSA密钥（现在已经替换成Evil的了）来进行加密，并且用Dhillon的ECDSA密钥进行签名。
  5. Evil截取到IM的payload：
    5.1 他用自己的密钥来解密payload。
    5.2 他可以修改这条消息，并用Belinda真正的RSA密钥来再次加密。
    5.3 因为他是在设备上，所以他可以用Dhillon的ECDSA私钥来重新签名这条消息。
  6. Belinda接收到这条消息后，发现它被正确的签名了，所以她可以读取它。

正如上面所说的，这里一个很关键的条件是攻击者，也就是Evil，可以获取到发送者的ECDSA私钥

现在就让我们来看看当Belinda回复这条消息的时候会发生什么：

mitm

  1. Belinda写了一条消息。这条消息用Dhillon的RSA密钥来加密，并且用Belinda的ECDSA密钥来签名。
  2. 这条消息发送到苹果公司的Push服务器，然后再发送到Dhillon的设备。
  3. Evil截取到这条消息：
    3.1 因为Evil可以获取到Dhillon的RSA私钥，所以Evil可以解密这条消息。
    3.2 Evil可以修改这条消息，并用Dhillon的RSA公钥来重新加密。
    3.3 Evil可以用他自己的ECDSA密钥来重新签名修改后的消息，因为Dhillon已经相信了这是Bel的ECDSA密钥。
  4. Dhillon接收到这条修改的消息：
    4.1 他用Evil的ECDSA密钥来检查消息的签名，一切都没问题。
    4.2 所以他就用自己的RSA私钥来解密这条消息。

同样的，在回复的过程中，一个很关键的条件是攻击者，Evil，需要获得RSA私钥。

双边MITM

现在，让我们来考虑一件事情：我们想要同时对Dhillon和Belinda进行MITM攻击。我们假设Evil是在Dhillon和Belinda的iDevice都运行他的MITM。

现在假设，Dhillon向Belinda发送一条消息：

mitm

  1. Dhillon编写了一条消息。
  2. Dhillon的iDevice向ess.apple.com发送请求。
  3. Evil截取到这个请求：
    3.1 Evil向ess.apple.com请求Belinda的信息（Push-Token，RSA和ECDSA密钥）。
    3.2 Evil将Bel的RSA和ECDSA密钥替换成自己的
  4. Dhillon向Belinda发送他的消息：这条消息用Belinda的RSA密钥进行加密（实际上上Evil的），并用Dhillon的ECDSA密钥进行前面。
  5. Evil截取到IM payload：
    5.1 他用自己的密钥来解密payload。
    5.2 他可以修改这条消息，并用自己的密钥来加密。
    5.3 同样的，他用自己的密钥进行签名。
  6. 这条消息发送到APSN并被转发到Belinda的设备

因为Evil对两端都进行监听，所以发送和接收的过程是相似的：

  1. Evil在Belinda的iDevice上接收到这条消息。
  2. Evil用他自己的RSA私钥对这个payload进行解密。
  3. Evil用Belinda的RSA公钥进行加密。
  4. Evil用自己的ECDSA密钥对这个消息进行签名，因为他用自己的密钥来假装成Dhillon的。
  5. Evil将消息转发给Belinda。
  6. Belinda检查消息的签名，任何事都显得很正常，看起来是Dhillon发过来的。
  7. Belinda解密这条消息。

整个过程的关键是Evil必须同时在两端进行监听，也即Dhillon到苹果服务器之间、Belinda到苹果服务器之间。通过这种方法，我们就不再需要获得用户的私钥。

MITM

假设攻击者可以替代苹果服务器，来进行MITM攻击。
要实现这种假设需要满足很多条件：

  • 大范围的网络控制，以便可以重定向iDevice的网络通信（通过DNS获取其他方法）
  • 让每一个目标都信任的PUSH和ESS证书

很明显，不是每一个人都有这种能力。或许只有某些部门能够做到吧。。。谁知道呢

下面是典型MITM攻击步骤：

mitm

  1. Evil把他的RSA和ECDSA发送给Dhillon。
  2. Evil把他的RSA和ECDSA发送给Belinda。
  3. 当Dhillon发送消息的时候，在消息发送给Belinda之前，Evil可以查看、修改和重新签名这条消息。
  4. 当Belinda接收到这条消息，她用自己的RSA密钥来解密这条消息，然后用Evil的ECDSA密钥来检查消息的签名，因为她以为这是Dhillon的密钥。

因为Evil是通讯过程的中间进行监听，所以Belinda回复消息给Dhillon的过程是一样的：

mitm

总的来说，要实现上面这些步骤需要以下条件：

  1. 他需要在目标设备上有一个有效的CA。
  2. 攻击者需要重定向所有目标的通信到他自己。
  3. 他需要向每一个目标提供密钥，从而来冒充通信的另一端。

为什么点对点的加密不足够

实际上，并不是所有的攻击者都可以满足上述的条件。现在，我们来看一下苹果公司在整个过程的影响：

  1. 他需要在目标设备上有一个有效的CA -> 苹果公司有这样的CA。
  2. 攻击者需要重定向所有目标的通信到他自己 -> 苹果公司不需要这样做，因为所有的通信都会经过苹果公司的PUSH服务器。
  3. 他需要向每一个目标提供密钥，从而来冒充通信的另一端 -> 苹果公司有密钥服务器，ESS。

所以，苹果公司可以进行MITM攻击，他们只需要跟踪发送给目标的密钥。然后，你已经知道iMessage是如何加密的：一个RSA密钥加密一个AES密钥。

aes

因为苹果公司可以更改密钥，所以苹果公司可以解密AES密钥，因此，也就可以看到消息的内容了。

苹果公司的声明：

For example, conversations which take place over iMessage and FaceTime are protected by end-to-end encryption so no one but the sender and receiver can see or read them.Apple cannot decrypt that data.

是的，正如苹果公司声明的，的确是点对点加密，但是密钥的构造并不可信，所以苹果公司可以解密你的数据，如果他们愿意的话，或者更有可能的是，他们被要求这么做。

防止苹果公司或者第三方的MITM攻击

实际上，并没有很多办法可以避免MITM攻击，因为主要的问题在于苹果公司控制着密钥的结构。

所以，我们有以下两种防止方法：

  1. 让密钥的结构更透明和更公开。
  2. 用不在苹果公司控制下的密钥来加密消息。

总结

苹果公司宣传他们不可以查看点对点加密的iMessage很明显是错的。就正如大家所怀疑的：是的，他们真的可以！

毕竟怀疑终究还是怀疑，还是得用事实来说话，所以希望我们对相关协议的深入分析，能够让大家明白苹果公司是如何能够做到这点的。

但是，我们是否应该继续使用iMessage呢？一般的攻击者是不可能进行MITM攻击的，所以iMessage的安全性对于一般的用户来说，还是足够的。

如果那些通信的信息是很敏感的，以至于你不希望任何的政府机构查看它的话，那你就不应该用iMessage了。

苹果公司，建立了一个相对更透明的PKI，并且有详细的文档来描述相关协议。因此还是可以认为iMessage是目前最有效的和安全的实时通信系统。

苹果公司能够查看你的iMessage吗?

是的，他们可以。

如果你不想。然而如果你很忙但很想知道答案，那么你就应该看一下这部分内容。

下面是我们发现的事实：

  • 基于公开的算法（AES，RSA，ECDSA）使用了合适的密钥长度和实现。
  • 密钥生成代码是开源的。
  • 在客户端和PUSH服务器之间（iMessage相关的苹果公司服务器）没有使用证书绑定。
  • 客户端和苹果公司服务器的身份认证是基于严格的强大的混淆和白盒密码，从而防止第三方iMessage客户端的使用。
  • 用户的密码是通过SSL安全通道用明文的方式发送给苹果公司服务器。对于那些在很多地方都用了这个密码的人来说，这是值得注意的，因为苹果公司可以知道这个密码。
  • 没有绑定证书+明文密码，就意味任何能够往设备中添加证书的人，都可以进行MITM攻击，从而可以得到用户的AppleID和密码。
  • 彩蛋：如果一个设备连接到iPhone Configuration Utility，苹果公司提出的一个管理iPhone设备的企业级解决方案，就会插入一个受信任的CA。所有用这个CA签名的证书都会被信任从而建立安全的SSL通信。这意味着所有使用这个应用的公司通过简单的SSL通信代理，就可以获取到他们所有员工的AppleID和密码。
  • iMessage是在Push协议上运行，跟FaceTime，GameCenter或者通知服务一样。
  • PUSH是在SSL通道通过5223端口连到苹果公司的PUSH服务器。
  • 每一台苹果设备都有一个唯一的Push-Token。
  • 当一个人需要发送消息的时候，客户端会去寻找所有跟目标（叫做URI）关联的Push-Tokens，从而将消息发送到这些URI注册的设备。
  • 当一个人发送一条iMessage的时候，客户端首先连接到苹果公司的密钥服务器，叫做ESS，来获取目标的公钥。

  • 客户端或获得两个密钥

    1）一个ECDSA（256-bit），用来验证目标URI发送的消息的签名。所以当目标URI回复的时候，我们就可以用这个ECDSA来检查消息的签名。

    2）一个RSA（1280-bit），用来加密发送给目标URI的iMessage。

  • iMessage的payload实际上是一个二进制的plist，把序列化的数据组装成字典。

  • iMessage的payload用一个随机的AES密钥来机密，这个密钥连接在加密的payload的开头，这个1280位的数据是用目标的RSA密钥来加密。

aes

  • 每一个消息都会用发送者的ECDSA密钥来签名。
  • iMessage可以用来发送附件。这些附件是保存在iCloud中，用AES会话密钥来加密。

  • 因为苹果公司控制着ESS服务器，所有的iMessage都会发送到苹果公司的PUSH服务器，所以苹果公司可以进行MITM攻击：

    1）苹果公司把假的RSA公钥/ECDSA密钥发送给发送者。

    2）然后苹果公司就可以解密，修改这条消息的payload，并在发送给目标之前重新签名。

  • 所以，是的，虽然有点对点的加密，但是由于密钥的构造由苹果公司控制，所以他们可以在任何时候更改密钥来查看我们iMessage的内容。