Whisper Bully

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.

Resumen

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:

• Fuga de BDADDR sin parche — dirección de identidad permanente revelada a través de una conexión BLE simple, sin interacción GATT requerida, funciona en dispositivos completamente parcheados
• Omisión de autenticación SMP mediante ventana de reinicio — vinculación persistente establecida mediante SMP Just Works estándar durante la recuperación de la pila BT después de una inundación L2CAP, sin ningún intercambio GATT de Fast Pair

⚠️ 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

Etapas de Ataque

Etapa 1 — Extracción de BDADDR (Divulgación de Información sin Parche)

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:

1. Realiza un escaneo BLE activo (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 protocolo
2. Establece una conexión BLE simple mediante BleakClient.connect() — sin escrituras GATT de ningún tipo
3. Configura el agente de BlueZ a NoInputNoOutput en preparación para el Paso 4
4. Verifica si el servicio GATT de Fast Pair está presente en el objetivo — esta verificación es solo informativa; la herramienta continúa independientemente del resultado (línea 452 de wb.py)
5. Ejecuta bluetoothctl pair <rpa_addr> — intento de emparejamiento SMP Bluetooth estándar, no Fast Pair
6. Monitorea la salida estándar de bluetoothctl en busca de la salida Bonded: yes, que puede contener la dirección vinculada
7. Mecanismo de respaldo principal: Llama a bluetoothctl 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 2

Por 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:

• La extracción puede tener éxito incluso si el paso bluetoothctl pair falla o expira
• La verificación de presencia del servicio GATT de FP en el paso 4 no bloquea el ataque
• No aparece ninguna ventana de confirmación de PIN — NoInputNoOutput significa que no hay interacción del usuario en ninguno de los lados para Just Works

Etapa 2 — Inundación L2CAP (Modo de Ráfaga-Reconexión EMP)

Una 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:

• Los hilos se sincronizan después de cada ciclo de ráfaga para que la presión golpee al objetivo simultáneamente
• Efectivo hasta ~16 hilos en hardware típico; rendimientos decrecientes más allá de eso
• Se pueden usar múltiples adaptadores HCI simultáneamente para aumentar la presión

Etapa 3 — Secuestro mediante SMP Just Works Durante la Ventana de Reinicio (Omisión de Autenticación sin Parche)

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:

1. Envía una sonda L2CAP (l2flood -c -1 -t 2) para confirmar que el dispositivo no responde — busca no response from <addr>: id N en la salida
2. Una vez que se confirma el estado de no respuesta, ejecuta bluetoothctl connect <permanent_addr> en un bucle de reintentos
3. SMP negocia NoInputNoOutput / NoInputNoOutput → modelo de asociación Just Works → el vínculo se completa
4. bluetoothctl connect devuelve código de salida 0 en caso de éxito
5. El vínculo persiste después de que el ataque se detiene

Probabilidad de éxito según el estado del dispositivo:

Relación con CVE-2025-36911

⚠️ Advertencia Legal

Esta es una herramienta de investigación de denegación de servicio y acceso no autorizado.

Usar esta herramienta en dispositivos que no posea o sin autorización escrita explícita es un delito federal castigable con prisión y multas bajo la Ley de Fraude y Abuso Informático (18 U.S.C. § 1030) y estatutos equivalentes en otras jurisdicciones.

Solo puede usar esta herramienta en:

• Dispositivos que posea personalmente
• Dispositivos para los cuales tenga autorización escrita explícita del propietario para realizar pruebas de seguridad

Requisitos

• Linux (probado en Ubuntu 20.04+)
• Privilegios de root (requeridos para bluetoothctl y acceso BLE sin procesar)
• bluetoothctl / BlueZ instalado y funcional
• Python 3.7+
• Para Etapa 2/3: l2flood con soporte OpenMP — ver kovmir/l2flood

Instalación

Dependencias del sistema

Ubuntu / Debian:

sudo apt update
sudo apt install -y python3 python3-pip libdbus-1-dev libglib2.0-dev bluez

Fedora / RHEL / CentOS:

sudo dnf install -y python3 python3-pip dbus-devel glib2-devel bluez

Arch Linux:

sudo pacman -S python python-pip dbus glib bluez

Alpine Linux:

apk add --no-cache python3 py3-pip dbus-dev glib-dev bluez bluez-openrc

openSUSE:

sudo zypper install -y python3 python3-pip dbus-1-devel glib2-devel bluez

Void Linux:

sudo xbps-install -S python3 python3-pip dbus-devel glib-devel bluez

Clonar e instalar

git clone https://github.com/Ymsniper/Whisper_Bully.git
cd Whisper_Bully
pip3 install -r requirements.txt
# Requerido solo para Etapa 2/3:
make
sudo make install

Uso

Etapa 1: Extracción de BDADDR

# Detectar y extraer automáticamente todos los dispositivos Fast Pair cercanos
sudo python3 wb.py

# Escaneo de 20 segundos, guardar resultados
sudo python3 wb.py -s 20 -o targets.json

# Escaneo de 30 segundos, archivo de salida personalizado
sudo python3 wb.py -s 30 -o extracted.json

Nota: Si un dispositivo fue previamente conectado o emparejado por esta herramienta o manualmente, BlueZ ya conoce su dirección de identidad. Elimínelo primero para que la extracción se ejecute limpiamente:

root@kitploit:~

sudo bluetoothctl remove <address>

Etapa 2: Inundación L2CAP (Opcional)

Método 1 — Interactivo (prompt después de la extracción)

sudo python3 wb.py -s 20 -o targets.json
# Al finalizar: "Run aggressive L2CAP test... (yes/no)" → yes

Método 2 — Banderas (saltar prompts)

# Solo Etapa 1 + Etapa 2
sudo python3 wb.py -s 20 -o targets.json --aggressive

# Etapa 1 + Etapa 2 + Etapa 3
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack

# Con duración y número de hilos
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 8

Método 3 — Script de inundación independiente

# Inundar desde archivo de objetivos extraídos durante 120 segundos
sudo python3 aggressive_test.py -f targets.json -d 120 -t 4

# Inundar una dirección conocida única durante 60 segundos
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -d 60

# Inundar para siempre (Ctrl+C para detener)
sudo python3 aggressive_test.py AA:BB:CC:DD:EE:FF -f

Etapa 3: Secuestro (Opcional)

# Integrado — extraer, inundar, luego secuestrar
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120

# Secuestro manual independiente en dirección conocida
sudo python3 wb.py -H AA:BB:CC:DD:EE:FF

Ejecución Completa de Tres Etapas (Un Solo Comando)

sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -d 120 -t 4

Flujo de ejecución:

1. Escanear 20 segundos en busca de dispositivos Fast Pair
2. Extraer BDADDR permanente de cada objetivo
3. Inundar todos los objetivos durante 120 segundos usando 4 hilos
4. Monitorear el estado de no respuesta
5. Intentar secuestro en cada objetivo durante la ventana de recuperación
6. Guardar resultados en targets.json

Ataque Multi-Adaptador

# Terminal 1
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci0 -d 120 -t 4 &

# Terminal 2
sudo python3 wb.py -s 20 -o targets.json --aggressive --hijack -i hci1 -d 120 -t 4

Duplica la presión DoS y aumenta la probabilidad de éxito del secuestro durante la ventana de recuperación.

Banderas de Línea de Comandos

Detalles Técnicos

Etapa 1 — Por qué la Extracción Funciona sin Interacción GATT

El UUID de servicio FE2C de Fast Pair se usa solo como filtro de escaneo para identificar objetivos candidatos. Una vez que se establece una conexión BLE:

• La Capa de Enlace completa el handshake de conexión y dispara LL_CONNECTION_COMPLETE al host
• BlueZ procesa este evento y, si el dispositivo usa una Dirección Privada Resoluble, la resuelve contra su caché IRK o simplemente registra la dirección de identidad desde los parámetros de conexión
• La dirección de identidad se almacena en caché en la tabla interna de dispositivos de BlueZ
• bluetoothctl devices muestra tanto la RPA original como la dirección de identidad recién registrada — mismo nombre de dispositivo, diferente dirección
• La herramienta compara con la RPA original y devuelve la nueva entrada como el BDADDR permanente

La llamada bluetoothctl pair que se ejecuta concurrentemente puede tener éxito o no — el BDADDR típicamente ya está en la tabla para cuando el comando pair se completa o falla.

Etapa 2 — Modo EMP (l2flood -R)

Este l2flood modificado tiene dos modos dependiendo de la etapa prevista:

Bandera -R — Modo EMP (solo DoS, sin secuestro) Se usa cuando se ejecuta la Etapa 2 de forma independiente sin proceder a la Etapa 3. Ráfaga-reconexión silenciosa de "dispara y olvida" — todos los hilos sincronizan sus ciclos de conectar → ráfaga → cierre forzado para garantizar desmontajes ACL completos periódicos. No produce salida estándar durante la operación normal.

Modo normal (DoS + sonda de secuestro) Se usa cuando se prevé la Etapa 3. El modo normal fue mejorado para manejar reconexiones automáticamente y genera no response from <addr>: id N cuando el objetivo deja de responder — esta es la señal que wb.py monitorea para activar el intento de secuestro.

Etapa 3 — Por qué el Vínculo Persiste

El vínculo resultante no es una conexión transitoria — es un vínculo SMP completo almacenado por BlueZ:

• bluetoothctl info <addr> muestra Paired: yes, Bonded: yes, Trusted: no
• El vínculo sobrevive a ciclos de bluetoothctl power off/on
• El vínculo sobrevive al reinicio de la máquina atacante (almacenado en /var/lib/bluetooth/)
• El dispositivo acepta conexiones posteriores desde el adaptador atacante sin necesidad de re-emparejamiento

Limitaciones Conocidas

Etapa 1

• Requiere Linux con BlueZ / bluetoothctl
• El objetivo no debe estar ya en la tabla de dispositivos de BlueZ bajo la RPA (eliminar primero si es necesario)
• El cambio de dirección durante la ventana de conexión puede causar problemas de sincronización — re-ejecutar si la extracción falla

Etapa 2

• Requiere conocer la dirección permanente (desde Etapa 1 u otros medios)
• El objetivo debe estar encendido y dentro del alcance
• El dispositivo se recupera completamente cuando la inundación se detiene — sin efecto persistente

Etapa 3

• Requiere que el dispositivo entre en estado de no respuesta (dependencia de Etapa 2)
• El éxito depende del momento — el secuestro debe ocurrir durante la ventana de recuperación
• No funciona si el dispositivo se apaga durante la inundación

Solución de Problemas

No se encontraron dispositivos

• Verifique que bluetoothctl esté funcionando: sudo bluetoothctl list
• Aumente el tiempo de escaneo: -s 30

Conexión BLE fallida / extracción falla

• Elimine el dispositivo de BlueZ primero: sudo bluetoothctl remove <addr>
• Re-ejecute — el cambio de RPA puede causar problemas de sincronización

La inundación no tiene efecto

• Aumente el número de hilos: -t 16
• Use múltiples adaptadores simultáneamente
• Verifique que se está atacando la dirección permanente (no la RPA)

Permiso denegado

• Ejecute con sudo
• Asegúrese de que el usuario está en el grupo bluetooth o ejecute como root

Error de importación bleak

• Debian/Ubuntu: sudo apt install libdbus-1-dev libglib2.0-dev
• Fedora: sudo dnf install dbus-devel glib2-devel
• Arch: sudo pacman -S dbus glib

Errores de D-Bus

• sudo systemctl start dbus && sudo systemctl start bluetooth

Créditos

• @kovmir por l2flood
• KU Leuven COSIC por la investigación original de WhisperPair / CVE-2025-36911

Licencia

MIT. Consulte LICENSE para más detalles.

Descargo de responsabilidad

Esta herramienta es solo para pruebas de seguridad autorizadas e investigación defensiva. El acceso no autorizado a dispositivos Bluetooth es ilegal. Úsela solo en dispositivos que posea o para los cuales tenga permiso explícito por escrito para realizar pruebas. El autor no asume ninguna responsabilidad por el uso no autorizado o ilegal.