ymsniper/whisper_bullyExtracción de BDADDR Bluetooth en tres etapas, DoS y secuestro en dispositivos Fast Pair; primitivas no parcheadas fuera del alcance de CVE-2025-36911 (no se necesita Ubertooth)
Extracción de BDADDR Bluetooth, Denegación de Servicio y Herramienta de Investigación de Secuestro
© 2026 @Ymsniper — Solo para investigación de seguridad autorizada.
Whisper Bully es una herramienta de investigación de seguridad Bluetooth de tres etapas que apunta a dispositivos que anuncian Google Fast Pair (UUID de servicio fe2c). Demuestra dos primitivas de ataque sin parche que están fuera del alcance del parche de firmware CVE-2025-36911:
⚠️ Esta herramienta NO implementa el protocolo Whisper Pair (Fast Pair GATT). Nunca escribe en la característica de Emparejamiento Basado en Clave (UUID 1236) ni en la característica de Clave de Cuenta (UUID 1238). La superficie de ataque descrita aquí es independiente y no está cubierta por el parche de verificación de modo de emparejamiento CVE-2025-36911.
https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11
Causa raíz: Cuando se establece una conexión BLE, la pila de host BlueZ de Linux procesa el evento LL_CONNECTION_COMPLETE y resuelve la Dirección Privada Resoluble (RPA) del dispositivo a su dirección de Identidad permanente, almacenándola en caché en la tabla de dispositivos de BlueZ. Esto ocurre a nivel de Capa de Enlace / HCI, antes de cualquier interacción con el servicio GATT. No hay protocolo Fast Pair involucrado.
Lo que realmente hace el código:
BleakScanner) en busca de dispositivos que anuncien el UUID de servicio Fast Pair fe2c — usado solo para identificación del objetivo, sin interacción con el protocoloBleakClient.connect() — sin escrituras GATT de ningún tipoNoInputNoOutput en preparación para el Paso 4wb.py)bluetoothctl pair <rpa_addr> — intento de emparejamiento SMP Bluetooth estándar, no Fast Pairbluetoothctl en busca de la salida Bonded: yes, que puede contener la dirección vinculadabluetoothctl devices y compara con la RPA inicial — cualquier entrada con el mismo nombre de dispositivo pero una dirección diferente es la Dirección de Identidad permanente, filtrada por BlueZ en el paso 2Por qué el parche no soluciona esto:
La corrección de firmware CVE-2025-36911 agrega una verificación de modo de emparejamiento al manejador de la característica de Emparejamiento Basado en Clave GATT de Fast Pair en el accesorio. Esta herramienta nunca escribe en esa característica. La fuga de dirección de identidad ocurre en el host Linux del atacante a través del propio caché de dispositivos de BlueZ — completamente fuera del firmware del accesorio.
Notas clave de comportamiento:
bluetoothctl pair falla o expiraNoInputNoOutput significa que no hay interacción del usuario en ninguno de los lados para Just WorksUna vez que se conoce la dirección permanente, opcionalmente se ejecuta una denegación de servicio L2CAP sostenida utilizando una versión modificada de l2flood.
Se utilizan dos modos en la herramienta:
Bandera -R — Modo EMP (inundación de Etapa 2)
Ráfaga-reconexión silenciosa de "dispara y olvida". Todos los hilos sincronizan sus ciclos de conectar → ráfaga → cierre forzado para que el objetivo reciba desmontajes ACL completos periódicos en lugar de una reorganización escalonada de canales L2CAP que pueda absorber. Utiliza SO_LINGER {1,0} para un desmontaje RST inmediato en cada cierre. No produce salida estándar durante la operación normal — los errores de conexión se suprimen a stderr y solo se imprimen periódicamente.
Modo normal (sonda de secuestro de Etapa 3)
Se utiliza sin -R para sondear si el objetivo todavía está respondiendo. Este modo también fue mejorado — ahora maneja reconexiones automáticamente y genera no response from <addr>: id N cuando el objetivo deja de responder, que es lo que wb.py monitorea para activar el secuestro.
Resultado: El dispositivo objetivo se vuelve no receptivo a intentos de conexión normales mientras la inundación está activa. El dispositivo se recupera por completo cuando el ataque se detiene — sin daño permanente.
Comportamiento de múltiples hilos:
Causa raíz: La inundación L2CAP sostenida provoca que la pila Bluetooth del dispositivo objetivo se bloquee o reinicie. Durante la ventana de recuperación — antes de que el servicio GATT de Fast Pair se haya vuelto a registrar y antes de que el Administrador de Seguridad se haya reinicializado por completo — el dispositivo acepta un vínculo SMP Just Works estándar desde NoInputNoOutput sin requerir el intercambio GATT de Fast Pair que normalmente bloquearía el vínculo. El vínculo resultante es persistente: sobrevive a reinicios del adaptador BT y muestra Paired: yes / Bonded: yes en bluetoothctl info.
Por qué esto es un hallazgo separado de CVE-2025-36911:
El parche CVE-2025-36911 aplica una verificación de modo de emparejamiento en el manejador de la característica de Emparejamiento Basado en Clave GATT de FP. La Etapa 3 nunca toca esa característica. El vínculo se establece a nivel SMP durante una ventana donde el servidor GATT de FP no se ha reinicializado, por lo que la puerta de seguridad de Fast Pair nunca se alcanza. Un dispositivo completamente parcheado sigue siendo vulnerable a esto porque el parche no tiene visibilidad sobre la capa SMP durante la recuperación de la pila.
Lo que realmente hace el código:
l2flood -c -1 -t 2) para confirmar que el dispositivo no responde — busca no response from <addr>: id N en la salidabluetoothctl connect <permanent_addr> en un bucle de reintentosNoInputNoOutput / NoInputNoOutput → modelo de asociación Just Works → el vínculo se completabluetoothctl connect devuelve código de salida 0 en caso de éxitoProbabilidad de éxito según el estado del dispositivo:
| Estado del Dispositivo | Resultado Esperado |
|---|---|
| Activamente bajo inundación / sin respuesta | Mayor éxito — pila en estado degradado durante la recuperación |
| Recuperándose de la inundación | Alto éxito — ventana temporal de reinicialización de SM |
| Totalmente recuperado | Menor éxito — seguridad normal restaurada |
| Apagado | Falla |