详解iOS零点击无线电近程漏洞 （三）

在这篇文章中，我们将为读者详细介绍近期在iOS中发现的一个零点击无线电近程漏洞，由于篇幅过大，我们将分多篇发表。更多精彩内容，敬请期待！

（接上文）

Radiotap标准

在前文中，我们已经考察了802.11 AWDL帧中数据的组织结构：最前面是一个ieee80211头部，然后是Apple OUI、AWDL Action帧的头部，等等。如果我们的WiFi适配器连接到一个WiFi网络，我们就能利用这些信息来传输这样的帧。但问题是，我们并没有连接到任何网络。这意味着，我们需要给自己的帧附加一些元数据，以告诉WiFi适配器以无线方式传输这个帧时，所需要注意的事项。例如，它应该使用什么频道、什么带宽及调制方案来注入该帧？它是否应该尝试重传，直到收到ACK为止？注入帧时，它应该使用什么样的信号强度？

Radiotap是一个通信标准，用于详细描述这种类型的帧元数据；无论是在注入帧还是接收帧时，都需要用到这些元数据。实际上，它就是一个可变大小的头部，我们可以将其放到要注入的帧的前面（或者从嗅探到的帧的开头部分读出该头部）。

不过，我们指定的Radiotap字段到底是否被遵守和应用，具体取决于我们使用的驱动程序：有的驱动程序可能不允许从用户空间向帧中注入内容。下面是一个使用MacBook Pro上的内置MacOS数据包嗅探器，从AWDL帧中捕获的radiotap头部的示例。需要注意的是，这里Wireshark已经对二进制的Radiotap格式进行了相应的解析处理：

Wireshark已经对pcaps中的radiotap头部进行了解析，并以人类可读的形式展示出来

从这个radiotap头部中，我们可以看到时间戳、数据传输速率，频道（5.220 GHz，即频道44）和调制方案（OFDM）。此外，我们还可以看到接收信号的强度和噪声指标。

接下来，让我们详细介绍radiotap头部：

static uint8_t u8aRadiotapHeader[] = {
  0x00, 0x00, //version
  0x18, 0x00, //size
  0x0f, 0x80,0x00, 0x00, // included fields
  0x00, 0x00,0x00, 0x00, 0x00, 0x00, 0x00, 0x00, //timestamp
  0x10, // addFCS
  0x00,// rate
  0x00, 0x00,0x00, 0x00, // channel
  0x08, 0x00, //NOACK; don't retry
};

在了解radiotap标准和基本的头部之后，我们就可以使用cap_inject接口和监控模式下的无线适配器，以无线方式发送AWDL帧了：

int pcap_inject(pcap_t *p, const void *buf, size_tsize)

当然，上述代码还不能立即正常工作，而且经过一些反复试验，发现似乎它没有严格遵守规定的速率和频道。另外，我们发现使用该适配器进行注入操作时，似乎只能在1Mbps下工作，并且radiotap头部中指定的频道并非用于注入的频道。不过，这个问题不难解决——我们可以手动设置wifi适配器的频道：

iw dev wlan0 set channel 6

尽管1Mbps的注入速度的确很慢，但这足以让测试AWDL帧以无线方式进行传输，我们可以通过运行在另一个监听模式下的设备上的Wireshark来检测这个帧。但在目标设备上，似乎什么也没有检测到。因此，现在是时候进行一些调试工作了!

用DTrace进行调试

SEEMOO实验室的论文已经给出了MacOS的启动参数建议，以便让AWDL内核驱动程序记录更为细致的日志信息。尽管这些日志信息是非常有帮助的，但其中的信息通常仍然无法满足我们的要求。

在最初提交的PoC中，我展示了如何使用MacOS内核调试器来修改一个待传输的AWDL帧。通常情况下，根据我的经验，MacOS的内核调试器不仅难用，并且很不可靠。尽管从技术上讲可以使用ldb的python绑定来编写相关的脚本，但我并不推荐这样做。

然而，苹果公司还提供了另一种解决方案，那就是DTrace!在我看来，MacOS的内核调试器很糟糕，但DTrace却很好用。DTrace是一个动态跟踪框架，最初是由Sun Microsystems为Solaris系统开发的。它已经被移植到包括MacOS在内的许多平台上，并且是默认安装的。它是Instruments等工具背后的魔力源泉。DTrace允许我们将跟踪代码的小片段hook到几乎任何我们想要的地方，无论是在用户空间程序中，还是在内核中，都是如此。当然，Dtrace有它的怪癖：hook是用D语言写的，而D语言没有循环语句，同时，变量的作用域也需要花点时间才能理解，但并不妨碍它成为终极调试和逆向工具。

例如，每当分配一个新的IO80211AWDLPeer对象时，我可以在MacOS上通过下面的trace脚本进行跟踪，并输出其堆地址和MAC地址：  

self char* mac;
 
fbt:com.apple.iokit.IO80211Family:_ZN15IO80211AWDLPeer21withAddressAndManagerEPKhP22IO80211AWDLPeerManager:entry{
  self->mac =(char*)arg0;
}
 
fbt:com.apple.iokit.IO80211Family:_ZN15IO80211AWDLPeer21withAddressAndManagerEPKhP22IO80211AWDLPeerManager:return
 printf("new AWDL peer: %02x:%02x:%02x:%02x:%02x:%02xallocation:%p", self->mac[0], self->mac[1], self->mac[2],self->mac[3], self->mac[4], self->mac[5], arg1); 
}

这里，我们共创建了两个hook，一个在函数入口处运行，另一个在同一函数返回前运行。我们可以使用self->语法在入口点和返回点之间传递变量，而DTrace能够确保入口和返回点的正确匹配。

我们必须在dtrace脚本中使用重整后的（mangled）C++符号；借助于c++filt命令，我们可以得到去重整后的（demangled）版本：

$ c++filt -n_ZN15IO80211AWDLPeer21withAddressAndManagerEPKhP22IO80211AWDLPeerManager
IO80211AWDLPeer::withAddressAndManager(unsigned charconst*, IO80211AWDLPeerManager*)

实际上，入口点处的hook用于“保存”指向MAC地址的指针，该指针被作为第一个参数传递；并将其与当前线程和堆栈帧相关联。然后，返回点处的hook负责打印该MAC地址和函数的返回值（返回点处的hook中的arg1是函数的返回值），在本例中，就是新分配的IO80211AWDLPeer对象的地址。

借助于DTrace，我们可以很轻松地建立自定义堆日志工具的原型。例如，如果您的跟踪目标是一个特定的分配长度，并希望了解哪些对象在那里结束，则可以使用类似下面的DTrace脚本：

/* some globals with values */
BEGIN {
 target_size_min = 97;
 target_size_max = 128;
}
 
fbt:mach_kernel:kalloc_canblock:entry {
  self->size= *(uint64_t*)arg0;
}
 
fbt:mach_kernel:kalloc_canblock:return
/self->size >= target_size_min ||
 self->size<= target_size_max   /
{
 printf("target allocation %x = %x", self->size, arg1);
  stack();
}

其中，两个“/”之间的表达式使得hook代码只有符合特定条件时才会执行。在这个例子中，将条件限制为调用了kalloc_canblock，其大小介于target_size_min和target_size_max之间。同时，内置的stack()函数会打印堆栈跟踪信息，便于我们了解特定长度范围内的内存分配情况。即使是系统调用而触发内核空间的分配，我们仍可以使用ustack()在用户空间继续跟踪该堆栈。

DTrace还可以安全地对无效地址解除引用，而不会让内核崩溃，这使得它在原型设计和调试堆的过程中非常有用。通过一些巧妙的方法，它还可以处理其他一些事情，比如转储链接列表和监视特定对象的销毁。

我强烈建议大家花一点时间来学习DTrace；一旦您掌握了其编程模型，就会发现它的确是一个非常强大的工具。

抵达入口点

通过使用DTrace来记录栈帧，我能够追踪合法的AWDL帧在代码中的路径，并确定伪造的AWDL帧走了多远。通过这个过程，我发现，至少对于MacOS系统来说，内核中有两个AWDL解析器：一个是我们已经在IO80211Family kext中看到的解析器，另一个解析器则要简单得多，它主要用于特定芯片组的驱动程序中。在这个更简单的解析器中，有三项检查没有通过，从而使得伪造的AWDL帧根本无法抵达IO80211Family代码：

首先，对源MAC地址进行验证。 MAC地址实际上包含多个字段:

MAC地址的前半部分是一个OUI。T第一个字节的最低有效位定义了该地址是多播还是单播。 T第二位定义了该地址是本地管理的还是全球唯一的。

另外，libpcap例子中的源MAC地址01:23:45:67:89:ab其实是一个不合时宜的选择，因为它设置了多播位。但是，AWDL只想处理单播地址，并拒绝来自多播地址的帧。为了解决这个问题，我们可以选择一个没有设置多播位的新MAC地址。

接下来的检查是，帧的变长有效载荷部分的前两个TLV的类型，它们必须分别为类型4（同步参数），和类型6（服务参数）。

最后，同步参数中的频道号码必须与实际接收该帧的频道相匹配。

随着这三个问题的解决，我终于能够让任意控制的字节出现在远程设备的actionfr ameReport方法上，这就意味着，我们的项目需要进入下一个阶段了。

AWDL客户端的框架

我们已经看到，AWDL使用时分复用技术，在用于AWDL的频道（通常是6和44）和设备所连接的接入点使用的频道之间快速切换。通过解析AWDL对等体发送的PSF和MIF帧中的AWDL同步参数TLV，就可以计算出它们将来何时会被监听。OWL项目使用linux libev库，以试图只在其他对等体的监听时间段内进行传输。

就我们的目的而言，这种方法还面临几个问题。

首先，非常重要的一点是，这使目标定位变得非常困难。AWDL的Action帧（通常）被发送到一个广播目标MAC地址（即ff:ff:ff:ff:ff:ff:ff:ff）。这是一个网状网络，这些帧旨在供所有对等方用于构建网状网络。

虽然在同一时间利用附近的每个监听的AWDL设备将是一个有趣的研究问题，但这也带来了许多挑战，它们已经远远超出了最初的范围。因此，我非常需要一种方法来确保只有我控制的设备才能处理我发送的AWDL帧。

通过一些实验发现，所有的AWDL帧也可以被发送到单播地址，这时设备仍然可以解析它们。这就带来了另一个挑战，因为AWDL虚拟接口的MAC地址是在每次激活接口时随机生成的。在MacOS上测试时，只需运行下列命令即可：

ifconfig awdl0

通过以上命令，我们就可以确定当前的MAC地址。对于iOS系统来说，情况却有点复杂；我选择的技术是在AWDL的社交频道上进行嗅探，并将信号强度与设备的移动联系起来，以确定其当前的AWDL MAC。

当我们向一个单播地址发送AWDL的Action帧时，还有一个重要的区别：如果该设备目前正在该频道上监听并接收帧，它将发送一个ACK。这被证明是非常有用的。我们最终将使用AWDL的Action帧来建立一些相当复杂的原语，并通过滥用协议来建立一个怪物机器。能够知道目标设备是否真的收到了一个帧，意味着我们可以把AWDL帧当作一个可靠的传输媒介。对于AWDL的典型用法来说，这是没有必要的；但我们对AWDL的用法并不是典型的。

这个ACK嗅探模型将是我们的AWDL帧注入API的构建块。

接收ACK

现在，我们已经能够以无线方式传播ACK了，但是，这并不意味着我们真的能看到它们。尽管我们用于注入的WiFi适配器在技术上必须能够接收ACK（因为它们是一个基本的协议构件），但能够在监控界面上看到它们，当前还是无法保证的。

wireshark的截图显示了一个伪造的AWDL帧，然后是目标设备的确认

由于libpcap接口是相当通用的，因此，没有任何方法可以表明一个帧是否被ACK。内核驱动程序甚至可能不知道是否收到了ACK。我并不想深入研究注入接口的内核驱动程序或固件，因为这本身就是一项重大投资，所以我尝试了一些其他的想法。

由于802.11g和802.11a协议的ACK帧是基于计时的，因此，在每个传输的帧之后有一个短暂的窗口，如果接收者收到了该帧，他们可以进行ACK。正是由于这个原因，ACK帧不包含源MAC地址。这是没有必要的，因为由于计时技术的关系，ACK已经与源设备完美地关联在一起了。

如果我们也在监听模式下监听我们的注入接口，我们也许能够自己接收ACK帧并将其关联起来。如前所述，并不是所有的芯片组和驱动程序都会提供所需的全部管理帧。

对于我的早期原型，我设法在我的WiFi适配器中找到一对频道，其中一个可以成功地在2.4GHz频道上以1Mbps的速度注入，另一个可以成功地在该频道上以1Mbps的速度嗅探ACK。

虽然1Mbps的速度特别慢；一个相对较大的AWDL帧在这个速度下最终会在空中停留10ms或更长时间，所以，如果您的可用窗口只有几ms，每秒也传不了多少帧。不过，作为一个起点来说，这已经足够了。

我为这个exploit建立的注入框架使用了两个线程：一个用于帧注入，一个用于ACK嗅探。帧的注入可以使用try_inject函数，该函数可以提取伪造的源MAC地址，并向第二个嗅探线程发出信号，开始寻找发送到该MAC的ACK帧。

使用pthread条件变量，注入线程可以等待一段有限的时间，在此期间，嗅探线程可能会或可能不会收到ACK。如果嗅探线程确实收到了ACK，它将记录这一事实，然后向条件变量发出信号。注入线程将停止等待，并检查是否收到了ACK。

建议大家浏览一下exploit中的try_inject_internal，以及mutex和条件变量的设置代码。

在try_inject周围有一个叫做inject的封装器，它将不断调用try_inject，直到成功为止。通过这两个方法，我们不仅可以完成时间敏感的帧注入，也可以完成时间不敏感的帧注入。

这两个方法需要用到可变数量的pkt_buf_t指针，以及一个简单的自定义的、可变长度的缓冲区封装对象。这种方法的优点是，它允许我们快速建立新的AWDL框架结构的原型，而不需要编写模板代码。例如，下面就是注入一个基本的AWDL帧并重新传输它直到目标接收它所需的全部代码：

inject(RT(),
       WIFI(dst,src),
       AWDL(),
      SYNC_PARAMS(),
      SERV_PARAM(),
      PKT_END());

虽然建立这个API花了一些时间，不过从长远来看，却能节省大量的时间，同时，还能给让我们轻松尝试新的想法。

随着注入框架的就绪，我们接下来就可以开始考虑如何真正利用这个漏洞了。

小结

在这篇文章中，我们将为读者详细介绍近期在iOS中发现的一个零点击无线电近程漏洞，由于篇幅过大，我们将分多篇发表。更多精彩内容，敬请期待！

（未完待续）