在上一篇文章中描述了该漏洞后,我们将在这里讨论如何将其用作 RCE 载体。如前所述,三个不同的模块使用易受攻击的函数来解析从远程设备收到的广告数据,因此有很多内容需要介绍。让我们开始吧。
[1.0] 先决条件
要使该漏洞被用作 RCE 载体,广告数据必须来自外部,即必须由远程攻击者发送并被系统接受为有效,然后才能最终到达受影响模块之一中的易受攻击函数。攻击者只要在可触及的远程设备(即 Windows 计算机)上,就可以轻松发送他们喜欢的广告数据,但本地系统可能会因某些限制而拒绝此类数据。
首先,本地系统必须能够处理至少514字节长的扩展广告数据报告,因为更短的数据不能触发整数溢出。这是因为每个部分必须至少有 2 个字节长(包含类型和大小字段),并且必须至少有 257 个部分才能使溢出发生。为了满足此条件,本地蓝牙控制器必须支持蓝牙 5.0 和扩展广告,并且控制器支持的广告数据的最大长度必须至少为514。这些限制是特定于控制器/供应商的。下表详细说明了这些条件,以及哪些供应商受到影响。我调查了四家供应商:英特尔、高通、联发科和 Realtek,他们都在 Microsoft 驱动程序目录中发布了他们的驱动程序。
* - 出于某种原因,英特尔在其驱动程序更新中将扩展广告数据的最大长度从 1650 减少到 160。22.130.x.x我在两个不同的蓝牙设备上进行了测试,它们的行为相同。到目前为止,限制仍然是 160。
[2.0] 可达性
假设系统存在漏洞的必要条件得到满足,漏洞函数的可访问性取决于多种其他情况。这些情况包括:
-
哪个模块是目标。
-
使用的广告报告类型。并非所有报告都能被所有模块解析,因此攻击者必须选择他们想要使用的特定类型的广告报告。
-
系统是否处于主动还是被动扫描模式,即用户或应用程序当前是否正在扫描蓝牙设备。
-
是否启用 Microsoft Swift Pair。
让我们更好地解释一些条件。
[2.1] 广告扫描
在 Windows 系统上使用蓝牙进行广告扫描的默认行为根据系统是否主动搜索蓝牙设备而有所不同:
-
在活动状态下,系统会扫描来自远程设备的所有广告数据并将其转发到系统。当用户尝试从设置中添加新的蓝牙设备时,或者当本地应用程序请求扫描以处于活动状态时,就会发生这种情况。
-
在被动状态下,系统会关闭对来自远程设备的广告数据的主动扫描,仅接受本地白名单中设备的报告。此列表中的设备只有系统之前配对过的 LE 设备,并且仍在已知设备列表中。
-
这里的一个特例是 Swift Pair,因为它允许某些广告到达主机,即使主机处于被动状态。
[2.2] 快速配对
Swift Pair允许用户在附近的蓝牙设备准备连接时收到通知。想要被识别的设备需要在其广告数据中包含特定的有效负载。此有效负载由控制器识别并转发到主机,主机采取进一步操作(即显示通知)。这在实践中的工作方式是主机MSFT_HCI_Le_Monitor_Enable向控制器发送命令,这使得控制器监视特定 RSSI 范围内的设备,这些设备也满足一组特定的条件。此过程分两步执行:
1) 如果启用了 Swift Pair,主机将发出MSFT_HCI_Le_Monitor_Enable命令,让控制器监控特定 RSSI 范围内的所有设备(使用英特尔蓝牙无线控制器观察到的值为-65dBM至-55dBM0x06 0x00 0x03 ),这些设备在其广告数据中也包括偏移量0处的模式。主机还告诉控制器 RSSI 时间阈值为8秒,并且不应执行任何 RSSI 采样(即,每次设备重新进入 RSSI 范围时,只会发送一个广告数据包)。
2) 控制器识别出此类设备并将广告数据转发给主机后,主机会检查广告数据的格式是否正确。如果正确,它会发出第二个MSFT_HCI_Le_Monitor_Enable命令 - 该命令特定于所识别的设备,并让控制器知道只要来自此设备的广告数据在特定 RSSI 范围内,它就应该转发该数据。在这种情况下,RSSI 采样设置为800ms,这是广告数据包从控制器转发到主机的速率。
假设广告确实到达了主机系统,并非所有广告都会到达所有模块,有些广告甚至无法到达存在漏洞的函数。让我们看看在每个模块中,到达该函数需要哪些条件。
2.3 模块
让我们了解受影响的模块。我们将用它们的简称来指代它们:
-
bthport指的是bthport.sys,即 Windows 蓝牙端口驱动程序。它位于堆栈的最底层,用途非常广泛 - 它实现了相当多的协议层,例如 HCI、L2CAP 和 SDP,同时还是一个具有 IO 处理程序的“经典”驱动程序,用户模式组件可以使用它来发出蓝牙命令。
-
bthserv指的是蓝牙支持服务,这是在支持和启用蓝牙的 Windows 安装上运行的自动化服务。该服务以LOCAL SERVICE用户身份运行,并处理与通过WinRT API向外部应用程序公开的用户模式蓝牙组件相关的逻辑。
-
dafbth指的是dafBth.dll ,它是设备关联服务使用的模块,该服务是一种自动化服务,用于对系统识别的设备进行分类和排序。
[2.3.a] bth端口
bthport仅处理使用存在漏洞函数的特定广告数据报告。条件位于BthLE_ProcessAdvertisementEvent:
-
标记为“可扫描”、“可连接”或“扫描响应”的报告将被处理。但是,其中一些报告对一次可传输的数据量有进一步的限制:
-
可连接的扩展广告报告只能包含251字节的广告数据,不能用于触发漏洞。
-
可扫描的扩展广告报告不得包含任何广告数据,并且不能用于触发漏洞。
-
扫描响应扩展广告报告可以包含任意数量的广告数据,并可用于触发漏洞。
-
所有旧式广告报告只能包含 31 个字节的广告数据,不能用于触发漏洞。
-
所有来自可与已注册 LE 客户端匹配的设备地址的报告都将被处理。
-
注册的 LE 客户端是系统以某种方式连接到的设备。由于这通常需要针对设备进行身份验证以及更复杂的用户交互,我们将忽略这种情况。
-
如果当前使用的蓝牙设备的 PnP 设备属性注册表项中的 NonConnectableDib注册表值设置为“1” ,则全部报告。
-
所调查的四家供应商目前均未启用该功能。
[2.3.b] bth服务
在bthserv中,存在漏洞的函数位于 中Microsoft.Bluetooth.Service.dll。广告数据由一个对象处理GapAdvertisementMonitorImpl,该对象不会过滤广告报告,并将所有广告报告转发给存在漏洞的函数。因此,可达性取决于这些对象的存在。GapAdvertisementMonitorImpl通常在三种不同情况下创建:
-
如果启用了 Swift Pair,蓝牙用户支持服务将注册一个监视对象,以查找想要使用 Swift Pair 连接的设备的广告数据。
-
如果有任何蓝牙低功耗设备与系统配对,则会注册一个监视对象来查找来自这些设备的广告。
-
本地非特权应用程序可以请求使用蓝牙 API 来监视广告,这将创建一个监视对象。
[2.3.c] dafbth
设备关联服务使用的dafbth中存在漏洞的函数可通过CBthProviderAssociation::StartInitOobAssociation访问。当bthserv发出对 的调用时,BthParseOOBBlob会执行此代码,这种情况发生在两种情况下:DafCreateAssociationContextFromOobBlob
-
当找到已准备好的设备时。
-
当新设备连接到系统时。
要触发此模块中的漏洞,攻击者需要欺骗已准备好的设备(不太可能,而且配备已准备好设备的系统很少见),或者让用户通过蓝牙连接到攻击者控制的远程设备。此外,精心设计的广告数据可能已由bthserv通过其自己的易受攻击的代码路径进行处理。鉴于这些条件,利用dafbth中的漏洞的可能性很小,本报告的其余部分将不再关注此模块。
[3.0] 攻击媒介和影响
综合考虑所有这些,我们就能了解该漏洞的真正影响:未经身份验证的物理相邻攻击者可以在 Windows 内核或用户上下文中实现远程代码执行NT AUTHORITYLOCAL SERVICE,具体取决于利用哪个模块。攻击媒介包括通过蓝牙传输到易受攻击设备的数据。设置必要的有效载荷不需要任何控制器编程,可以使用流行的蓝牙主机 API 相对轻松地完成。可以通过向目标系统公布的 MAC 地址发送定向广告来实现有针对性的攻击。
利用 Swift Pair 触发漏洞需要远程设备处于受监控的 RSSI 范围内。尽管 RSSI 是基于邻近度的,并且 Windows 设置的参数表明 RSSI 范围对于大多数蓝牙设备而言都小于 1 米,但攻击者可以使用信号强度明显更高的设备,在更远的距离达到所需的 RSSI 值。此外,远程触发漏洞需要攻击者能够通过蓝牙到达目标系统,但不需要双向通信。这意味着可以使用信号强度较高的远程设备在远距离触发漏洞,并且不依赖于本地控制器的信号强度。
[3.1] 攻击场景
我们需要满足一系列不同的条件才能触发漏洞。我们还有两个模块可能被滥用。为了将这些信息整合成更自然的格式,我创建了一个场景表,其中列举了四种不同的场景,这些场景会影响不同组件是否以及如何受到攻击。下表评估了bthserv和bthport是否直接受到攻击,即在系统上没有事先执行的情况下。
请注意,最后一列表示该场景是否允许攻击者反复尝试利用该漏洞,即使失败的尝试导致bthserv崩溃。该服务设置为在崩溃后立即重新启动,但达到易受攻击的功能所需的广告监视器并不总是在新进程中重新注册。
** 攻击者可以通过暴力破解或嗅探无线电数据来伪造设备的地址。此步骤是将广告数据转发到主机所必需的,因为被动扫描设置为仅允许来自白名单设备的广告到达主机。
*** 这可能是一个错误,因为它实际上意味着如果bthserv崩溃,Swift Pair 将停止运行,直到系统重新启动或蓝牙用户支持服务重新启动。
[4.0] 波奇
我在github上发布了 PoC 。它可以用于在所有四种情况下触发漏洞,你只需要一个可编程的蓝牙设备来运行代码。不幸的是,我没有设法利用这个漏洞,尽管我并没有太努力。最有吸引力的选择是通过 SwiftPair 实现零点击情况,但远程设备与bthserv的交互在没有任何身份验证的情况下非常有限,这意味着击败 ASLR、设置堆等将非常困难。这很遗憾,因为漏洞原语非常好,可以用于 LPE 漏洞利用,我们将在下一篇文章中看到。
https://github.com/ynwarcs/CVE-2023-24871/tree/main/rce
下面您可以找到每个场景的演示视频。这些视频与我发送给 Microsoft 的视频相同,它们展示了 PoC 在旧 W11 内部版本之一上的运行情况。质量有点差,但重新录制它们需要重新设置所有内容,我不想麻烦。
场景 1
场景 2
场景 3
场景 4
CVE-2023-24871——RCE
https://ynwarcs.github.io/x-cve-2023-24871-rce
原文始发于微信公众号(Ots安全):CVE-2023-24871——RCE
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论