La seguridad Bluetooth y BLE es uno de los puntos ciegos más frecuentes en el ecosistema conectado. Cerraduras inteligentes, pulseras de actividad, auriculares, sensores industriales, bombas de insulina y marcapasos comparten una radio de corto alcance que, en muchos casos, se diseñó priorizando el consumo y la comodidad de emparejamiento por encima de la resistencia a un atacante activo. El resultado es una superficie de ataque que rara vez se audita y que un adversario con una antena de cinco euros puede escuchar desde la acera de enfrente.
Este artículo es una inmersión técnica en la seguridad Bluetooth, complementaria a nuestra visión general de la ciberseguridad IoT y OT. Repasamos las dos pilas del estándar, los ataques históricos (BlueBorne, KNOB, BIAS), el sniffing y el spoofing específicos de BLE, el riesgo en wearables y dispositivos médicos, y las medidas de emparejamiento seguro, defensa y detección de una auditoría profesional.
Bluetooth Classic y BLE: dos pilas, dos modelos de amenaza
Bajo la marca Bluetooth conviven dos tecnologías con diseños distintos. Bluetooth Classic (BR/EDR) es la pila orientada a flujos continuos (audio, transferencia de archivos) y usa salto de frecuencia sobre 79 canales. Bluetooth Low Energy (BLE), introducido en la versión 4.0, se optimizó para dispositivos a batería que transmiten pequeñas ráfagas: usa 40 canales (3 de anuncio y 37 de datos) y expone su funcionalidad mediante el perfil GATT (Generic Attribute Profile), una jerarquía de servicios y características que un cliente puede leer, escribir o suscribir.
Esa diferencia arquitectónica define el modelo de amenaza. En BR/EDR el problema histórico ha sido la negociación de claves y la autenticación del enlace. En BLE es doble: los paquetes de anuncio se emiten en claro y de forma predecible (facilitando el rastreo), y el emparejamiento heredado (legacy pairing) admite modos sin protección real frente a un intermediario. Comprender qué pila usa cada dispositivo es el primer paso, igual que conviene distinguir bien los conceptos que explicamos en qué es la seguridad OT/ICS.
Ataques históricos contra Bluetooth Classic
BlueBorne (2017)
Descubierto por Armis, BlueBorne es un conjunto de ocho vulnerabilidades (entre ellas CVE-2017-0781, CVE-2017-0785, CVE-2017-1000251 y CVE-2017-14315) que afectaban a las pilas Bluetooth de Android, Linux, Windows e iOS. Su gravedad fue excepcional por un motivo: no requería emparejamiento previo ni interacción de la víctima. Bastaba con que el Bluetooth estuviera activado y alcanzable para lograr ejecución remota de código o fuga de información. Fue la prueba de que la propia pila de protocolo, y no solo la aplicación, es un objetivo de primer orden.
KNOB (2019)
El ataque KNOB (Key Negotiation Of Bluetooth), catalogado como CVE-2019-9506, explota una debilidad de diseño en la negociación de entropía de la clave de cifrado de BR/EDR. Un atacante en el medio puede forzar que la clave negociada tenga tan solo 1 byte de entropía, un espacio que se rompe por fuerza bruta en tiempo real. Como la reducción ocurre antes de aplicar el cifrado, muchos dispositivos la aceptaban sin alertar al usuario.
BIAS (2020)
BIAS (Bluetooth Impersonation AttackS), identificado como CVE-2020-10135, ataca el procedimiento de autenticación de BR/EDR. Permite suplantar a un dispositivo previamente emparejado sin conocer la clave de enlace de larga duración, aprovechando debilidades en la autenticación heredada y en el cambio de rol maestro-esclavo. Combinado con KNOB, un adversario puede establecerse como intermediario legítimo entre dos equipos que ya confiaban el uno en el otro. A esta familia se sumó BLURtooth (CVE-2020-15802), que abusa de la derivación de claves entre transportes (CTKD) en dispositivos de modo dual.
Ataques específicos contra BLE: sniffing y spoofing
Sniffing del tráfico
Capturar tráfico BLE es sorprendentemente accesible. Con un dongle Nordic nRF52840 y el complemento nRF Sniffer for Bluetooth LE, un Ubertooth One o la herramienta abierta Sniffle de NCC Group (sobre placas Texas Instruments CC26x2), un atacante puede seguir el salto de canales de una conexión y volcar el intercambio a Wireshark, que incluye disectores BLE nativos. Si la conexión emplea emparejamiento heredado, herramientas como crackle recuperan la clave temporal (TK) y descifran toda la sesión de forma pasiva. Los mismos utilitarios (hcitool, gatttool, bettercap) enumeran servicios y características GATT sin autenticación en la mayoría de dispositivos de consumo.
Spoofing y ataques de intermediario
El siguiente escalón es el intermediario activo. Frameworks como GATTacker, BtleJuice y Mirage clonan los anuncios de un periférico legítimo, se colocan entre el dispositivo y su aplicación móvil, y retransmiten o modifican las lecturas y escrituras GATT en tiempo real. Un caso recurrente es la cerradura cuyo comando de apertura viaja sin cifrado de aplicación: capturado una vez, se reproduce (replay) a voluntad. El ataque BLESA (Bluetooth Low Energy Spoofing Attack) llevó esto a la reconexión: muchas pilas (BlueZ, Fluoride, clientes iOS) no exigían reautenticación al reconectar, de modo que un periférico suplantado podía inyectar datos falsos a un cliente que creía hablar con un dispositivo conocido.
Wearables y dispositivos médicos: cuando el riesgo es físico
El impacto deja de ser abstracto en dispositivos que tocan el cuerpo o el proceso. La familia SweynTooth (2020), que afectó a los SoC BLE de fabricantes como Cypress, NXP y Texas Instruments, provocaba caídas, bloqueos o elusión de la seguridad en productos que iban desde pulseras de actividad hasta bombas de insulina, lo que llevó a la FDA a emitir avisos específicos. En paralelo, BleedingTooth (CVE-2020-12351 y asociadas) demostró ejecución de código en el kernel de Linux a través de la pila BlueZ, relevante para gateways IoT y equipamiento clínico.
En wearables, el riesgo es doble: el rastreo mediante direcciones MAC estáticas que permiten seguir a una persona por su pulsera, y la exposición de datos biométricos sin cifrado de aplicación. Estos dispositivos entran cada vez más en entornos regulados por NIS2 y el CRA, de modo que la seguridad de su radio pasa de ser un detalle de producto a una obligación de cumplimiento.
Emparejamiento seguro y defensa en profundidad
La buena noticia es que el estándar ofrece defensas robustas cuando se implementan bien. Estas son las medidas irrenunciables.
Exigir LE Secure Connections
Desde Bluetooth 4.2, LE Secure Connections sustituye el emparejamiento heredado por un intercambio de claves ECDH sobre la curva P-256, lo que elimina el ataque del escucha pasivo que hace viable a crackle. Toda especificación de producto sensible debería prohibir el fallback a legacy pairing.
Elegir el modelo de asociación correcto
Los modelos de asociación (Just Works, Passkey Entry, Numeric Comparison y Out Of Band) no ofrecen la misma protección. Just Works no autentica al otro extremo y es vulnerable a un intermediario activo, por lo que no debe usarse en cerraduras, dispositivos médicos ni controles de acceso. Para esos casos se impone Numeric Comparison o Passkey Entry, que protegen frente a MITM si el dispositivo tiene pantalla o teclado.
Cifrado de aplicación y privacidad
El cifrado del enlace no basta. Añadir cifrado de capa de aplicación (autenticando cada comando con una clave provisionada de fábrica y un nonce) neutraliza el replay aunque el atacante rompa el enlace. Para el rastreo, activar la privacidad LE con direcciones privadas resolubles (RPA) rotadas mediante una IRK impide seguir al dispositivo por su MAC. Y como control básico: desactivar la radio cuando no se usa, minimizar el anuncio y mantener el firmware al día, ya que la mayoría de estos ataques se corrigieron en actualizaciones que casi nunca llegan al dispositivo desplegado.
Detección y auditoría de la superficie Bluetooth
Auditar Bluetooth sigue la misma filosofía que aplicamos al pentesting industrial y auditoría OT/ICS: empezar de forma pasiva y escalar con control. La fase pasiva es un barrido de reconocimiento (bettercap, hcitool lescan, nRF Connect) que inventaria los dispositivos que anuncian, sus servicios GATT y su modelo de emparejamiento. Después se captura tráfico con nRF Sniffer o Sniffle para verificar si la conexión usa Secure Connections o legacy, y solo entonces, con acuerdo explícito y sobre un dispositivo de prueba, se ejecutan pruebas activas de spoofing, replay o manipulación de características GATT. El objetivo no es tumbar el dispositivo, sino demostrar qué puede hacer un atacante realista y priorizar la remediación por riesgo, con el mismo rigor que en entornos SCADA.
Preguntas frecuentes
¿Es seguro dejar el Bluetooth activado en el móvil?
En un teléfono moderno y actualizado el riesgo cotidiano es bajo, porque ataques como BlueBorne se corrigieron hace años. El problema real es el dispositivo que no se parchea: cerraduras, sensores o equipamiento médico que siguen ejecutando pilas vulnerables. Conviene desactivar la radio cuando no se usa y mantener actualizado todo el ecosistema conectado.
¿Qué diferencia hay entre Bluetooth Classic y BLE en cuanto a seguridad?
Bluetooth Classic (BR/EDR) ha sufrido sobre todo ataques a la negociación de claves y la autenticación del enlace (KNOB, BIAS). BLE añade problemas propios: anuncios en claro que facilitan el rastreo, un perfil GATT enumerable sin autenticación y un emparejamiento heredado que un escucha pasivo puede descifrar. Los vectores no son intercambiables.
¿Se puede espiar una pulsera o una cerradura BLE desde lejos?
Con equipamiento asequible (un dongle nRF52840, un Ubertooth o una placa compatible con Sniffle) se captura tráfico BLE a decenas de metros con la antena adecuada. Si el dispositivo usa emparejamiento heredado o no cifra sus comandos a nivel de aplicación, ese tráfico se descifra o se reproduce. Es lo que valida una auditoría antes de que lo haga un atacante.
¿Qué estándar regula la seguridad Bluetooth?
La referencia técnica principal es la guía NIST SP 800-121 Rev 2 (Guide to Bluetooth Security), junto con la especificación Bluetooth Core del SIG, que define LE Secure Connections y los modelos de asociación. Para dispositivos vendidos en la Unión Europea, el Reglamento de Ciberresiliencia (CRA) y la Directiva NIS2 añaden requisitos de seguridad por diseño y gestión de vulnerabilidades.
¿Cómo empiezo a proteger un producto con Bluetooth?
El primer paso es inventariar qué pila y qué modelo de emparejamiento usa cada dispositivo. Después se exige LE Secure Connections, se prohíbe Just Works para funciones sensibles, se añade cifrado de capa de aplicación contra el replay y se activa la privacidad LE contra el rastreo. Una auditoría de radio confirma que esas medidas resisten a un atacante real.
Recursos relacionados
- Ciberseguridad IoT y OT: amenazas críticas en 2026
- Qué es la seguridad OT/ICS
- Seguridad SCADA: amenazas y buenas prácticas
- Pentesting industrial y auditoría OT/ICS
- Flipper Zero: qué es y riesgos de seguridad
Seguridad Bluetooth y auditoría IoT con Secra
Secra evalúa la superficie Bluetooth y BLE de tus productos con la misma sensibilidad operativa que en OT: reconocimiento pasivo, inventario de servicios GATT y modelos de emparejamiento, verificación de LE Secure Connections y demostración del impacto real antes de la remediación priorizada.
Si diseñas o despliegas cerraduras, wearables, sensores o equipamiento médico con radio Bluetooth y necesitas validar su seguridad, conoce nuestra auditoría de seguridad IoT/OT o contacta con nuestro equipo para una conversación inicial sin compromiso.
Sobre el autor
Equipo de Secra Solutions
Ethical hackers certificados OSCP, OSEP, OSWE, CRTO, CRTL y CARTE, con más de 7 años de experiencia en ciberseguridad ofensiva. Autores de los CVE-2025-40652 y CVE-2023-3512.