Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas

Hace pocos días investigadores de EURECOM dieron a conocer que han descubierto dos nuevas vulnerabilidades (ya catalogada bajo CVE-2023-24023) en el mecanismo de negociación de sesiones de Bluetooth, que afectan a todas las implementaciones de Bluetooth que admiten modos de conexiones seguras» y «Emparejamiento simple y seguro» que cumple con las especificaciones en Bluetooth 4.2 a 5.4

Según el estudio de EURECOM, se han aprovechado estos dos fallos novedosos en el mecanismo de derivación de claves de sesión de Bluetooth junto con otros dos errores para facilitar una derivación débil de claves de sesión y posteriores ataques de fuerza bruta para enmascarar a las víctimas.

«Se espera que cualquier implementación BR/EDR conforme sea vulnerable a este ataque al establecimiento de la clave de sesión; sin embargo, el impacto puede verse limitado al rechazar el acceso a los recursos del host desde una sesión degradada o al garantizar suficiente entropía de clave para hacer que la clave de sesión se reutilice utilidad limitada para un atacante.»

Sobre BLUFFS (Bluetooth Forward and Future Secrecy)

Se menciona que las vulnerabilidades fueron detectadas durante un análisis de la arquitectura en la especificación del establecimiento de sesión Bluetooth (Forward and Future Secrecy), se identificaron vulnerabilidades que contrarrestan, que contrarrestan el compromiso de las claves de sesión en el caso de determinar una clave permanente. Es crucial destacar que las vulnerabilidades identificadas surgieron debido a fallas en el estándar base, además de que estas vulnerabilidades no están limitadas a pilas Bluetooth particulares y se manifiestan en chips fabricados por diversos proveedores.

El ataque funciona utilizando cuatro vulnerabilidades arquitectónicas, incluidas las dos fallas antes mencionadas, en la especificación del proceso de establecimiento de sesión de Bluetooth para obtener una clave de sesión débil y, posteriormente, aplicar fuerza bruta para falsificar a víctimas arbitrarias.

Se menciona que el proceso de explotación de BLUFFS, se basa en que un atacante dentro del alcance de Bluetooth de dos dispositivos de la víctima puede capturar paquetes en texto plano, conoce la dirección de Bluetooth de la víctima, puede crear paquetes y negociar una clave de sesión débil con el otro, proponiendo el valor de entropía de clave más bajo posible y utilizando un diversificador de clave de sesión constante.

El escenario de ataque supone que el atacante tiene como objetivo la sesión Bluetooth actual del dispositivo víctima y que puede reutilizar una clave de sesión débil para descifrar mensajes «pasados ​​y futuros».

Sobre el fallo, se informa que el primer error reside en el hecho de que, en un par Central-Periférico, Bluetooth permite que la Central establezca todos los valores de diversificación de claves de sesión, permitiendo así que un atacante impulse unilateralmente la diversificación de claves al hacerse pasar por una Central.

El segundo problema, es que si bien se utilizan números aleatorios en la diversificación de claves, no se utilizan nonces, lo que significa que los números pueden «reutilizarse en sesiones pasadas, presentes y futuras sin violar el estándar», por lo que un atacante puede obligar a las víctimas a obtener la misma clave de sesión controlada por el atacante en todas las sesiones.

Como demostración práctica de las vulnerabilidades, se han desarrollado seis nuevos métodos de ataque Bluetooth, que se denominaron ataques BLUFFS (Bluetooth Forward and Future Secrecy) y se menciona que estos permiten suplantar la conexión Bluetooth.

Estos ataques se han categorizado como

• A1: Falsificación de una central LSC
• A2: falsificación de un periférico LSC
• A3: Víctimas de MitM LSC
• A4: Falsificar una SC Central
• A5: Falsificación de un periférico SC
• A6: Víctima de MitM SC

Cabe mencionar que para poder bloquear las vulnerabilidades, se han propuesto cambios en el estándar Bluetooth para que se amplíe el protocolo LMP y se cambien la lógica de uso de KDF (Key Derivation Function) al generar claves en modo LSC.

Además de ello, se recomienda que las implementaciones de Bluetooth rechacen las conexiones de nivel de servicio en un enlace de banda base cifrado con intensidades de clave inferiores a 7 octetos, que los dispositivos funcionen en «Modo solo conexiones seguras» para garantizar una intensidad de clave suficiente y que el emparejamiento se realice a través de «Conexiones seguras» modo a diferencia del modo heredado.

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace. Para los interesados código de los métodos de ataque y para comprobar las vulnerabilidades, pueden consultar estos en GitHub.