CVE-2018-4087 PoC: 利用bluetoothd绕过沙盒

在我之前发布的题为“New Crucial Vulnerabilities in Apple’s bluetoothd daemon”的博客文章之后,我发布了PoC漏洞。

PoC的目的是为了方便IT管理员和渗透测试人员等人的评估而发布的,不能用于其它非法地方。 此外,此PoC和任何其他相关材料仅在负责向Apple披露并且Apple已解决问题后才会发布。

作为我在Zimperium的zLabs平台研究团队工作的一部分,我从默认应用程序沙箱内分析了iOS mach message IPC,最终目的是通过升级以逃离沙箱。

要启动项目,我需要映射mach端口来从沙箱内访问。 我从他的* OS Internals Volume III书中使用了Jonathan Levin(@Morpheus__)的sbtool。

我打算为你们的研究揭示该漏洞的完整PoC,就有了这篇博文。

Apple在最新的操作系统版本中解决了这两个漏洞:iOS – 11.2.5,watchOS – 4.2.2,tvOS – 11.2.5。 Apple为每个漏洞分配了2个CVE:

  1. CVE-2018-4087: Rani Idan (@raniXCH) of Zimperium zLabs Team
  2. CVE-2018-4095: Rani Idan (@raniXCH) of Zimperium zLabs Team

Apple Releases:

  • https://support.apple.com/en-il/HT208462 – tvOS 11.2.5
  • https://support.apple.com/en-il/HT208463 – iOS 11.2.5
  • https://support.apple.com/en-il/HT208464 – watchOS 4.2.2

POC源代码: https://github.com/rani-i/bluetoothdPoC

 

bluetoothd

不同的沙盒进程可以与不同的守护进程进行通信,如mediaserverd,bluetoothd和其他使用IPC的守护进程来使用守护进程功能。 在我们的例子中,我们将重点关注与bluetoothd的消息通信。

bluetoothd启动“com.apple.server.bluetooth”端口并在该端口上接受队列中mach消息。

Mach消息是* OS中的一种IPC形式; 为更高的IPC框架腾出空间,其使用并没有得到苹果公司的改进或记录,。

现在,函数apple_bluetoothd_mig_server将接收发送给com.apple.server.bluetooth的每个mach消息,并通过mach消息ID处理它。

在我们的情况中,为了简化这个过程,一个沙盒过程要求启动一个服务端口,并使用bootstrap_check_in注册它的端口。 之后,该进程可以使用从launchd检索到的mach端口与服务进行通信。

我们来看看apple_bluetoothd_mig_server:

你可以看到处理mach消息的函数从发送给bluetoothd的消息的msgh_id中减去0xFA300的值,然后获得匹配的回调,最终用输入消息调用它。

此外,你可以看到函数检查消息ID是否低于或等于0x83 – 这意味着我们有0x84可用的回调位置。

由于这个二进制文件没有符号,我开发了一个小工具来解析这个结构体,使我从不同库图像获得的更多信息。 这样就可以创建可用回调的完整列表。

*“machUnderfined_handler”功能未定义,因为这里使用的图像是iPod touch,并且某些功能不存在。

在我们的例子中,我们将关注mach__BTLocalDeviceAddCallbacks; 这个回调函数是消息标识符为3的消息处理程序。

mach__BTLocalDeviceAddCallbacks_3函数正在检查mach消息是否为0x48的大小,并且它不是一个复杂的mach消息。

之后,它会尝试使用session_token将回调地址添加到匹配的会话。

当一个合法的客户端使用bluetoothd创建会话时,它将创建一个会话令牌给bluetoothd,并使用该令牌客户端由bluetoothd标识。

注意这个重要的地方 – 这个会话令牌是什么?不辛的是,Apple使用session_token作为客户端和bluetoothd之间的端口名称。它与通信所使用的端口(字面上是端口名称)完全相同。

这是一个巨大的问题,因为mach端口具有特定的结构,这使得它非常容易暴力破解。 session_token属于mach_port_t类型。

在我的PoC中,我收到了从launchd到bluetoothd的端口,以便与bluetoothd直接通信。通过使用该端口,我强制执行了session_token(mach port struct),并最终通过劫持bluetoothd及其客户端之间的会话向bluetoothd客户端注册新的回调。

攻击过程:

1.bluetoothd的客户端连接到它并获得客户端需要用于mach通信的会话令牌,以便将其自身识别为bluetoothd。

2.恶意应用程序(沙盒应用程序)可以强制使用会话令牌,因为会话令牌由通信机器端口组成,并且由mach_port_t结构构成。

3.在成功强制执行令牌之后,恶意应用程序可以在将消息发送到客户端时调用的客户端进程上注册新的返回地址。

还有很重要一点,它意味着从沙盒环境运行的恶意应用程序需要在具有不同沙盒环境的bluetoothd客户端上添加回调地址。

我所劫持的所有bluetoothd客户端列表(bluetoothd也要注册为客户端):

  • SpringBoard
  • mDNSResponder
  • aggregated
  • wifid
  • Preferences
  • CommCenter
  • iaptransportd
  • findmydeviced
  • routined
  • UserEventAgent
  • carkitd
  • mediaserverd
  • bluetoothd
  • coreduetd

 

接下来怎么利用它?

这个漏洞可以用来泄漏每个客户端的机器端口,并且在每个客户端上,它会都会有很多的攻击方式。

泄漏客户机的端口可以通过合适的跳转小工具并将端口发送回沙盒应用来完成。

 

Apple的修复

我向苹果公司报告了这个问题,事实上,他们解决了这个问题,但我认为解决方案可以设计得更好。

该修复程序仍不能确保会话不会被劫持。 Apple将会话令牌从实际的端口改为随机令牌。

 

披露时间

10/11/2017 – 发现第一个bug

14/11/2017 – 上报bug给Apple

05/12/2017 – Apple确认bug

25/01/2018 – Apple发布补丁

 

感谢

我很感谢苹果的专业回复,Nikias Bassen(@pimskeks)和其他Zimperium团队

本文由 华盟网 作者:AlexFrankly 发表,其版权均为 华盟网 所有,文章内容系作者个人观点,不代表 华盟网 对观点赞同或支持。如需转载,请注明文章来源。

0

发表评论

// 360自动收录 // 360自动收录