sobre el ataque (Key Negotiation Of Bluetooth), que permite interceptar y sustituir información en el tráfico cifrado de Bluetooth. Al poder bloquear la transmisión directa de paquetes durante la negociación de la conexión entre dispositivos Bluetooth, un atacante puede forzar el uso de claves que contienen solo 1 byte de entropía para la sesión, lo que permite aplicar un método de fuerza bruta para determinar la clave de cifrado.
El problema es causado por fallos (CVE-2019-9506) en la especificación Bluetooth BR/EDR Core 5.1 y versiones anteriores, que permiten el uso de claves de cifrado demasiado cortas y no impiden la intervención de un atacante durante la etapa de negociación de la conexión para retroceder a estas claves poco confiables (la sustitución de paquetes es posible por un atacante no autenticado). El ataque puede llevarse a cabo en el momento de la negociación de la conexión de dispositivos (sesiones ya establecidas no pueden ser atacadas) y es eficaz solo para conexiones en los modos BR/EDR (Bluetooth Tasa Básica/Tasa de Datos Mejorada), si ambos dispositivos son susceptibles a la vulnerabilidad. En el caso de un emparejamiento exitoso de la clave, el atacante puede descifrar datos transmitidos y, sin que la víctima se dé cuenta, realizar una sustitución en el tráfico de cualquier texto cifrado.
Al establecer una conexión entre dos controladores Bluetooth A y B, el controlador A, después de la autenticación por clave de enlace (link key), puede ofrecer utilizar para la clave de cifrado (encryption key) 16 bytes de entropía, y el controlador B puede aceptar este valor o indicar un valor menor si no tiene la capacidad de formar una clave del tamaño propuesto. En respuesta, el controlador A puede aceptar la oferta de respuesta y activar el canal de comunicación cifrado. En esta etapa de negociación, no se aplica cifrado, por lo que un atacante tiene la oportunidad de interferir en el intercambio de datos entre los controladores y sustituir el paquete con el tamaño de entropía propuesto. Dado que el tamaño aceptable de la clave varía de 1 a 16 bytes, el segundo controlador aceptará este valor y enviará su confirmación con un tamaño equivalente.
Para reproducir la vulnerabilidad en condiciones de laboratorio (la actividad del atacante fue simulada en uno de los dispositivos) se ha propuesto
para llevar a cabo un ataque.
Para un ataque real, el atacante debe estar en el rango de recepción de los dispositivos de las víctimas y tener la capacidad de bloquear brevemente la señal de cada dispositivo, lo que se sugiere lograr mediante la manipulación de la señal o el apagado reactivo.
La organización Bluetooth SIG, responsable del desarrollo de los estándares Bluetooth, ajustó la especificación con el número 11838, en la que se proponen medidas para que los fabricantes bloqueen la vulnerabilidad (el tamaño mínimo de la clave de cifrado se ha incrementado de 1 a 7). El problema en los pilas Bluetooth y los firmware de chips Bluetooth que cumplen con el estándar, incluidos productos , Broadcom, , , , Qualcomm, Linux, , y (de 14 chips probados, todos resultaron vulnerables). En la pila Bluetooth del núcleo de Linux una corrección que permite cambiar el tamaño mínimo de la clave de cifrado.
Fuente: opennet.ru
