首页 >> 网络安全 >>漏洞分析 >> 让我们一起调试:CVE-2020-9992
详细内容

让我们一起调试:CVE-2020-9992

时间:2020-09-27     作者:Nikias Bassen   阅读

苹果最近发布了期待已久的iOS / iPadOS 14.0更新以及更新的Xcode 12.0。作为此更新的一部分,Apple修复了开发工具中的一个漏洞,该漏洞是我们Zimperium zLabs研究人员和产品安全副总裁Nikias Bassen以及独立安全研究人员Dany Lisiansky共同努力于今年早些时候报告的。我们将此漏洞命名为“ c0ntextomy”。


c0ntextomy是MobileDevice.framework / Xcode和iOS / iPadOS / tvOS开发工具中的设计缺陷,它使同一网络中的攻击者可以在iOS / iPadOS / tvOS设备上远程执行代码。


名称“ c0ntextomy”源自contextomy,上下文定义为“一种非正式的谬误,是一种错误的归因,其中一种段落被从其周围的事物中删除,从而扭曲了其预期的含义” [Wikipedia:contextomy ] 。选择它来反映此漏洞的演变方式,即在执行实际的SSL握手后错误地取消了SSL上下文,从而有效地使我们相信该连接是安全的,即使它实际上未加密。


结果,这使Wi-Fi调试容易受到MITM攻击的攻击,攻击者能够劫持正在运行的调试会话并在目标设备上执行任意代码。


Apple的最新更新修复了此漏洞,但是仅适用于最新版本的iOS和iPadOS。如下所述,旧版本的iOS / iPadOS仍然部分或什至完全脆弱。我们强烈建议所有依赖Xcode的远程开发人员工具(例如,远程调试,单元测试等)的开发人员将其更新为Xcode 12,并将设备更新为iOS / iPadOS 14。


完整的安全公告附在下面,并详细介绍了该漏洞,并复审了Apple的补丁程序。


安全咨询

MobileDevice.framework / Xcode和iOS / iPadOS / tvOS开发工具中的设计缺陷使同一网络中的攻击者可以在目标设备上远程执行代码。


作者

Dany Lisiansky(@ danyl931),独立安全研究员

ZIMPERIUM zLabs安全研究员兼产品安全副总裁Nikias Bassen(@pimskeks)

强制性哈希推文

1.png

额外积分

  • Eliyahu Stern 报告了有关libimobiledevice在iOS 13上支持debugserver的问题,并指出SSL握手后,连接以纯文本形式继续:https : //github.com/libimobiledevice/libimobiledevice/issues/793#issuecomment-500749243。请注意,他报告的问题与USB通信失败有关。


受影响的组件

  • macOS / Xcode MobileDevice.framework,IDEiOSSupportCore,DTDeviceKit(Base).framework,lldb-rpc-server

  • iOS / iPadOS / tvOS调试服务器等。/开发工具(开发人员磁盘映像)

受影响的版本

  • macOS 10.12.4至10.15.6 / Xcode 9.0至11.7

  • 在最新硬件上运行的iOS / iPadOS / tvOS 11.0至iOS 13.7

  • 供应商

  • 苹果公司。

  • CVE

  • CVE-2020-9992


披露时间表

  • 发现漏洞:2019年6月14日

  • 供应商通知:2020年3月12日

  • 供应商要求将披露期限延长至“今年夏季末”:2020年4月14日

  • 供应商通知我们补丁已在新Beta版本中提供,并计划在未来的安全更新中发布:2020年8月6日

  • 发现绕过新补丁的降级攻击影响了iOS 13.6和13.7:2020年8月14日

  • 供应商解释说,只有即将面世的iOS / iPadOS / tvOS 14和watchOS 7可以完全解决:2020年9月5日

  • 漏洞修复时间:2020年9月16日


概要

尽管服务连接设置执行了实际的SSL握手,但macOS / Xcode的MobileDevice.framework和iOS / iPadOS / tvOS的开发工具中的设计缺陷导致通过网络进行清晰的文本通信。


影响力

处于特权网络位置的攻击者可能能够获得任意远程执行代码,最终导致敏感用户数据从受害者设备中泄漏出来。


描述

macOS上的MobileDevice.framework封装了通过lockdownd启动iOS / iPad / tvOS设备上的服务所需的(私有)API,lockdownd是在设备上运行的主要服务守护程序。它同时支持USB和Wi-Fi连接(透明,因为这实际上是通过usbmuxd处理的),并且包含用于主机设备通信中的大多数服务的协议实现,例如Apple File Conduit(AFC),Backup System( MobileBackup2)等


当服务成功启动时,设备的锁定状态将向主机报告该服务可用的端口号,并且属性列表封装的字典还包含一个名为EnableServiceSSL 的键,其值为True 或False 。直到iOS 12.4.x,所有通过USB启动的服务都将其设置为False ,但是所有通过Wi-Fi启动的服务,或者是通过USB在具有iOS / iPadOS / tvOS 13.x或更高版本的设备上启动的,都将此项设置为是的。如果为真 它告诉主机或更准确地说是MobileDevice.framework中的处理代码,该通信应该被加密,因此它执行SSL握手,并且通信通常将以加密形式继续进行。


但是,这对于开发人员工具(如debugserver)的服务而言是不同的。一旦Xcode看到有可用的设备,则Xcode通过开发人员磁盘映像(DDI)来提供设备端实现。


在设备方面,lockdownd正在处理所有已启动服务的SSL握手。服务正在锁定状态下执行“签入”,从而允许他们接管连接。根据服务启动代码,如果连接是通过Wi-Fi进行的,则EnableServiceSSL始终为True。并且服务执行secure_lockdown_checkin ,通常紧随其后的是lockdown_get_socket ,然后还要执行lockdown_get_securecontext,以便它可以安全地通信。但是,在debugserver的情况下,它从不调用lockdown_get_securecontext,因此它甚至不希望在当前实现中进行加密的服务通信。


开发人员工具服务的主机端实现是在MobileDevice.framework之外实现的。调试服务器服务的启动是在Xcode的IDE插件IDEiOSSupportCore 中以-[DVTiOSDevice startDebugServerServiceForLaunchSession:] 的方法完成的,该方法随后将调用-[DTDKMobileDeviceToken startDebugServerServiceWithExtension:] (DTDeviceKitBase.framework),该方法通过特定方法通过其他方法调用MobileDevice.framework中的AMDeviceSecureStartService,以请求服务启动,这还将执行SSL握手。返回IDEiOSSupportCore将调用“成功”块,然后使用AMDServiceConnectionGetSocket 请求已建立连接的套接字文件描述符。最后,Xcode只会将此文件描述符作为参数传递给lldb-rpc-server:


/Applications/Xcode-beta.app/Contents/SharedFrameworks/LLDBRPC.framework/Resources/lldb-rpc-server –unix-fd 68 –fd-passing-socket 70


该代码根本不检查是否应使用SSL,但是debugserver中的设备端实现甚至不希望安全通信。结果,lldb-rpc-server 以纯文本方式通信。


对于工具服务com.apple.instruments.remoteserver 可以看到相同的问题,该服务在开发人员磁盘映像上的Library / PrivateFrameworks / DVTInstrumentsFoundation.framework / DTServiceHub中实现。以与debugserver相同的方式,Xcode启动服务,执行SSL握手,但随后继续以纯文本形式进行通信。在设备方面,它将再次简单地在签入后从锁定状态获取套接字,而无需考虑针对服务启动建议的SSL需求。更多的服务可能会受到影响,但是在撰写此通报时尚未对其进行分析。


需要注意的是,有是一个MobileDevice.framework API,它也被用于其它地方,例如用于崩溃报告取服务。该服务使用AFC,并且主机端服务实现也在DTDeviceKitBase.framework内的MobileDevice.framework之外。通过AMDServiceConnectionGetSocket 获得套接字后,将再次调用AMDServiceConnectionGetSecureIOContext ,从而有效地允许进程使用已建立的SSL会话。 


但这是另一种情况:完整的实现位于DTDeviceKitBase.framework内部,因此它毕竟可以在单个进程中有效地运行。但是在debugserver的情况下,代码被拆分为多个进程。通过上述框架,我们有Xcode要求启动debugserver服务,但随后会生成lldb-rpc-server ,后者又打算与远程设备上的debugserver服务进行通信。由于进程边界的缘故,在这里检索'SecureIOContext'可能不可行,而且在其当前实现中,lldb-rpc-server 只能与文件描述符一起使用。


设计缺陷

现在,这个问题显而易见:这是建筑设计的缺陷。当为iPhone创建MobileDevice.framework时,最初没有使用SSL的服务。这也是由于以下事实:在较早的iOS版本中,没有Wi-Fi支持服务;从安全角度而言,通过USB连接不需要SSL。创建Xcode或其他外部工具时,仅通过API公开文件描述符以供使用就完全没有问题。但是,系统在不断发展,因此出现了创建“ Wi-Fi同步”的日子,之后,服务被迫以加密方式进行通信。这是扩展MobileDevice.framework以在服务启动时执行SSL握手(如果设备请求的话)并支持SSL服务连接的时间。 


几年后,在iOS 11上,Xcode(以及与此相关的iOS)也获得了“远程调试”或“远程开发”的功能,只是看起来该代码未适合反映SSL服务要求,因此在debugserver和Xcode frameworks / lldb-rpc-server的实现中都可见。这就是为什么我们在服务连接上看到SSL握手(在MobileDevice.framework内部实现),但是随后通过纯文本通信对其进行欢迎的原因。 


在这里查看大图,如何实现SSL支持并添加了“外部服务”,设计缺陷显而易见:MobileDevice.framework处理SSL握手,同时您仍然可以从外部获得直接连接的“原始”文件描述符到设备上的服务。 


这基本上破坏了从消费者应用程序对服务通信代码的抽象。是的,如上所述,您可以通过AMDServiceConnectionGetSecureIOContext 获取“ SecureIOContext”,但这在整个进程中不可用。仅通过提供一种打破服务抽象的方法,此设计缺陷就使得可能/太容易“创建”此公告中描述的问题。


拟议的解决方案

有多种方法可以解决此问题。一种方法可能是提供一个API,该API将返回可在外部使用的服务上下文,并且可以将其传递给AMDServiceConnectionSend ,AMDServiceConnectionReceive 等(实际上可以透明地处理带有或不带有SSL上下文的连接)。 


另一种选择是确保可以从另一个进程中使用SSL上下文。这应该可以通过共享内存或XPC来实现,并为此设计适当的API。 

最后,也应该可以将服务启动代码移到lldb-rpc-server中。这样,就不会有进程边界,因此就没有理由绕过服务抽象。

无论如何,lldb-rpc服务器以及设备端调试服务器也需要更新以支持加密通信。


补丁

该漏洞已使用Xcode 12和iOS / iPadOS / tvOS 14进行了全面修补,并在iOS / iPadOS / tvOS 13.6和13.7中进行了部分修补(请参阅降级攻击)。


该修补程序包含在Xcode中,该Xcode提供了更新的开发人员磁盘映像,这些映像引入了受影响的锁定服务的新的安全变体。


在主机方面,Xcode现在将首先尝试连接到安全变量(后缀DVTSecureSocketProxy )。成功后,将通过进程内代理路由连接,该进程内代理将利用SSL上下文剥离加密层,最后将原始数据传输到lldb-rpc-server 。


在设备方面,类似于主机,安全服务将在内部代理安全连接以剥离加密层,并使用它向组件公开原始数据。


降级攻击

在补丁发布之前,我们被告知以下版本应包含该补丁:

  • 适用于iOS和iPadOS 13.6,macOS 10.15.6,tvOS 13.4.8或watchOS 6.2.8的Xcode 12 beta 3+ Tools

  • 具有iOS和iPadOS 14 beta 3 +,macOS Big Sur 11 beta 3 +,tvOS 14 beta 3+或watchOS 7 beta 3+的Xcode 12 beta 3+工具

在分析Xcode 12 beta 3 和Xcode 12 beta 4 以验证我们报告的漏洞的假定修复程序之后,我们注意到iOS <13.6 的Developer Disk Images 根本不包含任何缓解措施。在13.6和14.0的DDI 的Xcode的12 Beta 3的 做包含新* .DVTSecureSocketProxy 受影响的服务变体; 但是,它们仍然提供了旧的,不安全的变体。随着Xcode的12测试4 (及以上)的14.0 DDI 也不会有不安全的变种了,而13.6 DDI 仍然有他们。


Xcode当前缓解措施的问题在于,当无法启动服务的安全变体时,它会退回到不安全的服务变体中。如前所述,在Xcode 12 beta 4 (及更高版本)的14.0 DDI 下,不安全的变体不再可用,因此在这种情况下不能滥用回退机制来促进“降级”攻击,但是13.6-13.7 DDI 仍然受到影响。


通过数据包检查,MITM攻击者可以匹配* .DVTSecureSocketProxy StartService数据包(基于大小或其他启发式数据),该数据包将被发送到设备上的锁定设备。当攻击者随后故意断开连接时,它将看起来像Xcode一样,新的安全变体不可用,并且它将退回到不安全的变体。在这种情况下,这将导致原始漏洞仍然可以利用。


为了证明这种“降级”攻击是可行的,我们提出了一个简单的PoC,一旦lockdownd收到com.apple.debugserver.DVTSecureSocketProxy 变体的StartService数据包,它就会有目的地使SSL连接失败。通过将SSLRead 挂在lockdownd中,扫描服务字符串并返回错误代码,这将模拟先前描述的MITM攻击者删除连接的情况。然后,Xcode将假定服务启动刚刚失败,并退回到不安全的debugserver服务(如果可用),因此,您仍然可以通过Wi-Fi在纯文本连接上愉快地进行调试。


概念验证

可以在此GitHub存储库中找到概念证明(POC)https://github.com/c0ntextomy/c0ntextomy,该概念证明其具有调试会话劫持,远程代码执行和敏感数据泄露的漏洞。有关更多详细信息,请查阅README.md。


原文地址:https://github.com/c0ntextomy/c0ntextomy

.
更多

1589982338979126.png


ots网络社区

www.ots-sec.cn

联系方式
更多

投稿邮箱:1481840992@qq.com

交流群2群:622534175

ots网络社区3群:1078548359

关注我们
更多
技术支持: 建站ABC | 管理登录