Recientemente se dio a conocer información importante sobre un nuevo ataque llamado KNOB (Key Negotiation Of Bluetooth), que le permite a un atacante poder organizar la intercepción y la sustitución de la información en el tráfico cifrado de Bluetooth.
Al tener la capacidad de bloquear la transmisión directa de paquetes en el proceso de negociación de la conexión de dispositivos Bluetooth, el atacante puede lograr el uso de claves que contienen solo 1 byte de entropía para la sesión, lo que le permite poder utilizar el método de fuerza bruta para determinar la clave de cifrado.
Sobre KNOB
Daniele Antonioli de SUTD, el Dr. Nils Tippenhauer de CISPA y el profesor Kasper Rasmussen de la Universidad de Oxford descubrieron esta nueva vulnerabilidad de KNOB y afecta a dispositivos Bluetooth BR / EDR, también conocidos como Bluetooth Classic, utilizando las versiones de especificación 1.0 – 5.1.
Los investigadores informaron la vulnerabilidad a los miembros de ICASI, Microsoft, Apple, Intel, Cisco y Amazon, quienes emitieron una divulgación coordinada de la vulnerabilidad.
El problema (CVE-2019-9506) es causado por fallas en la especificación Bluetooth BR / EDR Core 5.1 y versiones anteriores que permiten el uso de claves de cifrado que son demasiado cortas y no evitan que un atacante interfiera con el paso de negociación de conexión para revertir a esas claves poco confiables (los paquetes pueden ser sustituidos por un atacante no autenticado ).
Se puede realizar un ataque al momento de negociar la conexión de un dispositivo (las sesiones ya establecidas no se pueden atacar) y es efectivo solo para conexiones en los modos BR / EDR (Velocidad básica de Bluetooth / Velocidad de datos mejorada) si ambos dispositivos son vulnerables.
Si la clave se selecciona con éxito, el atacante puede descifrar los datos transmitidos y silenciosamente de la víctima realizar una sustitución de texto cifrado arbitrario en el tráfico.
¿Como funciona el ataque?
Para reproducir la vulnerabilidad en el laboratorio (la actividad del atacante se emitió en uno de los dispositivos), se propuso un kit de herramientas prototipo para llevar a cabo el ataque.
Para un ataque real, el atacante debe estar en la zona de recepción de los dispositivos de las víctimas y tener la capacidad de bloquear brevemente la señal de cada dispositivo, que se propone implementar mediante la manipulación de la señal o la interferencia reactiva.
Explotar esta vulnerabilidad no es una tarea fácil, ya que requiere que se establezcan condiciones específicas. Esto incluye:
- Ambos dispositivos deben ser Bluetooth BR/EDR.
- Un atacante necesitaría estar dentro del alcance de los dispositivos mientras establecen una conexión.
- «El dispositivo atacante necesitaría interceptar, manipular y retransmitir mensajes de negociación de longitud de clave entre los dos dispositivos y al mismo tiempo bloquear las transmisiones de ambos, todo dentro de una ventana de tiempo estrecha».
- La clave de cifrado necesitaría ser acortada con éxito y luego forzada a descifrar la clave de descifrado.
- El atacante necesitaría repetir este ataque cada vez que los dispositivos se emparejaran.
Al establecer una conexión entre dos controladores Bluetooth A y B, el controlador A, después de la autenticación con una clave de canal (clave de enlace), puede ofrecer utilizar 16 bytes de entropía para la clave de cifrado, y el controlador B puede aceptar este valor o especificar un valor inferior, en si no es posible generar una clave del tamaño propuesto.
En respuesta, el controlador A puede aceptar la respuesta y activar el canal de comunicación encriptado.
Como el tamaño de clave permitido varía de 1 a 16 bytes, el segundo controlador aceptará este valor y enviará su confirmación con una indicación de un tamaño similar.
La organización Bluetooth SIG responsable del desarrollo de los estándares de Bluetooth ha publicado una actualización de la especificación con el número 11838, en la que los fabricantes han propuesto medidas para bloquear la vulnerabilidad (el tamaño mínimo de la clave de cifrado se ha incrementado de 1 a 7).
Para el Kernel de Linux se propuso en el kernel stack una solución que le permite cambiar el tamaño mínimo de una clave de cifrado.