Daniele Antonioli, investigador de seguridad de Bluetooth, que anteriormente desarrolló técnicas de ataque como BIAS, BLUR y KNOB, ha descubierto dos nuevas vulnerabilidades (CVE-2023-24023) en el mecanismo de emparejamiento de sesiones de Bluetooth, que afectan a todas las implementaciones de Bluetooth que admiten los modos de emparejamiento seguro 'Secure Connections' y 'Secure Simple Pairing', conforme a las especificaciones de Bluetooth Core 4.2-5.4. Como demostración de las vulnerabilidades identificadas, se han desarrollado 6 variantes de ataque que permiten interrumpir la conexión entre dispositivos Bluetooth emparejados anteriormente. El código que implementa los métodos de ataque y las herramientas para verificar la existencia de vulnerabilidades se han publicado en GitHub.
Las vulnerabilidades se identificaron durante el análisis de los mecanismos descritos en el estándar para lograr la secreto directo (Forward and Future Secrecy), que contrarrestan la compromisión de las claves de sesión en caso de que se identifique una clave permanente (la compromisión de una de las claves permanentes no debe llevar a la descifrado de sesiones que se hayan interceptado previamente o futuras) y la reutilización de claves de sesión (la clave de una sesión no debe ser aplicable a otra sesión). Las vulnerabilidades encontradas permiten eludir esta protección y reutilizar una clave de sesión no confiable en diferentes sesiones. Estas vulnerabilidades son causadas por deficiencias en el estándar base, no son específicas de pilas Bluetooth individuales, y se manifiestan en chips de varios fabricantes.
Los métodos de ataque propuestos implementan diferentes variantes de organización de suplantación de conexiones Bluetooth clásicas (LSC, Legacy Secure Connections basadas en primitivas criptográficas obsoletas) y seguras (SC, Secure Connections basadas en ECDH y AES-CCM) entre el sistema y el dispositivo periférico, así como la organización de ataques MITM para conexiones en modos LSC y SC. Se supone que todas las implementaciones de Bluetooth que cumplen con el estándar son susceptibles a uno u otro tipo de ataque BLUFFS. La efectividad del método se ha demostrado en 18 dispositivos de empresas como Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell y Xiaomi.
La esencia de las vulnerabilidades radica en la posibilidad de revertir forzosamente la conexión al uso de un modo antiguo de LSC y una clave de sesión (SK) corta y poco fiable, sin violar el estándar, a través de la especificación en el proceso de negociación de conexión de la entropía mínima posible e ignorando el contenido de la respuesta con los parámetros de autenticación (CR), lo que lleva a la generación de una clave de sesión basada en parámetros de entrada constantes (la clave de sesión SK se calcula como KDF de una clave constante (PK) y parámetros acordados durante la sesión). Por ejemplo, un atacante durante un ataque MITM puede reemplazar en el proceso de negociación de la sesión los parámetros 𝐴𝐶 y 𝑆𝐷 por valores nulos, y establecer la entropía 𝑆𝐸 en 1, lo que resultará en la formación de una clave de sesión 𝑆𝐾 con una entropía real de 1 byte (el tamaño mínimo de entropía estándar es de 7 bytes (56 bits), que es comparable en confiabilidad a la búsqueda de claves DES).
Si el atacante ha logrado implementar el uso de una clave más corta durante la negociación de la conexión, puede entonces, mediante fuerza bruta, determinar la clave constante (PK) utilizada para la cifrado y conseguir descifrar el tráfico entre los dispositivos. Dado que en un ataque MITM se puede iniciar el uso de la misma clave de cifrado, si esta clave es adivinada, se puede utilizar también para descifrar todas las sesiones pasadas y futuras interceptadas por el atacante.
Para bloquear las vulnerabilidades, se ha propuesto por parte de los investigadores que se realicen cambios en el estándar que amplíen el protocolo LMP y modifiquen la lógica del uso de KDF (Función de Derivación de Clave) al formar claves en el modo LSC. Este cambio no interrumpe la compatibilidad hacia atrás, pero lleva a la inclusión de un comando LMP ampliado y a la necesidad de enviar 48 bytes adicionales. La organización Bluetooth SIG, encargada de desarrollar los estándares Bluetooth, ha propuesto como medida de protección rechazar conexiones a través de canales de comunicación cifrados con claves de hasta 7 bytes. Se recomienda a las implementaciones que siempre aplican el nivel Security Mode 4 Level 4, rechazar conexiones con claves de hasta 16 bytes.
Fuente: opennet.ru
