深入探究 CVE-2025-36911 及 Google Fast Pair 生态系统中的安全漏洞
Google Fast Pair 旨在让蓝牙配对变得无缝：轻触通知即可连接。但当这种无缝体验变成安全负担时会发生什么？WhisperPair-PoC-Tool 是一款安全研究工具，它揭示了影响数百万蓝牙配件的两类关键漏洞：未授权配对绕过和 Find My Device 网络追踪利用。
本文详细介绍了 WhisperPair-PoC-Tool 的技术内部原理、它所利用的协议缺陷，以及这对蓝牙配件生态系统意味着什么。
Google Fast Pair 规范明确声明：
“如果可选的公钥字段存在：若设备未处于配对模式，则忽略写入并退出。”
这是关键的安全关卡。设备应仅在用户明确将设备置于配对模式（通常通过按住按钮）时，才对基于密钥的配对请求做出响应。这确保了用户意图，因此你无法在别人佩戴耳机时与其配对。
问题所在： 许多制造商完全跳过了这一检查。无论配对模式状态如何，它们都会处理配对请求，从而允许：
Google 的 Find My Device 网络 (FMDN) 允许通过众包的 Android 设备网络追踪蓝牙配件。这需要一个账户密钥，一个 16 字节的对称密钥，用于将设备链接到 Google 账户。
问题所在： 账户密钥特征通常接受写入操作而无需身份验证：
在深入探讨利用之前，让我们先了解合法的 Fast Pair 流程：
┌─────────────────────────────────────────────────────────────┐
│ BLE 广播 │
├─────────────────────────────────────────────────────────────┤
│ 服务 UUID: 0xFE2C (Fast Pair) │
│ 服务数据： │
│ [配对模式] → 3 字节：仅 Model ID │
│ [非配对模式] → 4+ 字节：0x00 + Account Key Filter │
└─────────────────────────────────────────────────────────────┘
广播格式揭示了配对状态：
Seeker (手机) Provider (配件)
│ │
│───── GATT 连接 ──────────────────────────────>│
│ │
│───── 发现服务 ───────────────────────────────>│
│<──── 服务: 0xFE2C ────────────────────────────│
│ │
│───── 启用通知 (0xFE2C1234) ──────────────────>│
│ │
│───── 写入基于密钥的配对请求 ──────────────────>│
│ [16 字节加密块] │
│ [64 字节 ECDH 公钥] (可选) │
│ │
│ ┌────────────────────────────────────┐ │
│ │ 安全检查： │ │
│ │ 如果存在公钥 且 │ │
│ │ 设备未处于配对模式： │ │
│ │ → 忽略并退出 │ │
│ │ 否则： │ │
│ │ → 处理请求 │ │
│ └────────────────────────────────────┘ │
│ │
│<──── 通知：加密响应 ──────────────────────────│
│ [Provider 的 BR/EDR 地址] │
│ │
│═══════ Bluetooth Classic 配对 ═══════════════>│
当设备完全跳过“安全检查”框时，漏洞就出现了。
WhisperPair-PoC-Tool 是一款基于 Bleak BLE 库的 Python 安全研究工具。它分为多个阶段运行：
┌────────────────────────────────────────────────────────────────┐
│ WhisperPair-PoC-Tool │
├────────────────────────────────────────────────────────────────┤
│ CLI 层 │
│ ├── 参数解析 (--target-name, --scan-duration) │
│ ├── TargetPolicy 构造 │
│ └── REPL 初始化 │
├────────────────────────────────────────────────────────────────┤
│ 发现引擎 │
│ ├── 通过 Bleak 进行 BLE 扫描 │
│ ├── 广播解析 │
│ ├── 协议检测 (Fast Pair, FMDN, Swift Pair) │
│ └── 设备指纹识别 (Model ID, OUI 查找) │
├────────────────────────────────────────────────────────────────┤
│ 检测引擎 │
│ ├── FastPairCheckEngine (被动广播分析) │
│ ├── FastPairBypass (主动 CVE-2025-36911 测试) │
│ ├── FindHubCheckEngine (账户密钥状态检测) │
│ └── RiskScorer (复合漏洞评估) │
├────────────────────────────────────────────────────────────────┤
│ 连接管理器 │
│ ├── GATT 连接及 MTU 协商 │
│ ├── 服务/特征发现 │
│ ├── 读/写/通知操作 │
│ └── 错误处理与重试逻辑 │
├────────────────────────────────────────────────────────────────┤
│ 利用模块 │
│ ├── ring_device() - 触发定位声音 │
│ ├── set_account_key() - 写入账户密钥 │
│ └── 响应解析 (BR/EDR 地址提取) │
└────────────────────────────────────────────────────────────────┘
discovery.py)扫描器使用 Bleak 的检测回调来捕获 BLE 广播：
async def _detection_callback(
self, device: BLEDevice, advertisement_data: AdvertisementData
) -> None:
"""处理每个检测到的 BLE 广播。"""
discovered = DiscoveredDevice(
address=device.address,
name=device.name or advertisement_data.local_name,
rssi=advertisement_data.rssi,
advertisement=self._convert_advertisement(advertisement_data),
first_seen=datetime.now(UTC),
last_seen=datetime.now(UTC),
)
self._devices[device.address] = discovered
对于每个设备，该工具提取：
0xFE2C、FMDN 0xFD44 等）0x00E0、Apple 0x004C）fastpair.py)通过分析设备的广播来确定配对模式：
def _analyze_service_data(self, evidence: FastPairEvidence) -> None:
"""分析 Fast Pair 服务数据以推断配对模式。"""
data = evidence.service_data_bytes
# 3 字节 = 仅 Model ID = 配对模式（可发现）
if len(data) == 3:
evidence.inferred_pairing_mode = PairingModeState.IN_PAIRING_MODE
return
# 4+ 字节且版本为 0x00 = 非配对模式
if data[0] == 0x00:
akd_byte = data[1]
akd_type = akd_byte & 0x0F # 低 4 位
# 类型 0x00 = 显示 UI，类型 0x02 = 隐藏 UI
# 两者都表示未处于配对模式
evidence.inferred_pairing_mode = PairingModeState.NOT_IN_PAIRING_MODE
这一点至关重要：如果确定某个设备未处于配对模式，但它仍然响应配对请求，则存在漏洞。
fastpair_attack.py)核心漏洞测试发送基于密钥的配对请求并监视响应：