Daniele Antonioli, investigador de seguridad de Bluetooth que anteriormente desarrolló las técnicas de ataque BIAS, BLUR y KNOB, ha identificado dos nuevas vulnerabilidades (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 Seguro", cumpliendo con las especificaciones Bluetooth Core 4.2-5.4. Como demostración de la aplicación práctica de las vulnerabilidades identificadas, se han desarrollado 6 opciones de ataque que nos permiten introducirnos en la conexión entre dispositivos Bluetooth previamente emparejados. El código con la implementación de métodos de ataque y utilidades para comprobar vulnerabilidades se publica en GitHub.
Las vulnerabilidades fueron identificadas durante el análisis de los mecanismos descritos en el estándar para lograr el secreto hacia adelante (Forward and Future Secrecy), que contrarrestan el compromiso de las claves de sesión en el caso de determinar una clave permanente (comprometer una de las claves permanentes no debería conducir al descifrado de sesiones previamente interceptadas o futuras) y reutilización de claves de sesión (una clave de una sesión no debe ser aplicable a otra sesión). Las vulnerabilidades encontradas permiten eludir la protección especificada y reutilizar una clave de sesión no confiable en diferentes sesiones. Las vulnerabilidades son causadas por fallas en el estándar base, no son específicas de pilas Bluetooth individuales y aparecen en chips de diferentes fabricantes.
Los métodos de ataque propuestos implementan diferentes opciones para organizar la 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 un dispositivo periférico, como así como organizar conexiones MITM, ataques para conexiones en modos LSC y SC. Se supone que todas las implementaciones de Bluetooth que cumplen con el estándar son susceptibles a alguna variante del ataque BLUFFS. El método se demostró en 18 dispositivos de empresas como Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell y Xiaomi.
La esencia de las vulnerabilidades se reduce a la capacidad, sin violar el estándar, de forzar una conexión a utilizar el antiguo modo LSC y una clave de sesión corta (SK) no confiable, especificando la mínima entropía posible durante el proceso de negociación de la conexión e ignorando la contenido de la respuesta con parámetros de autenticación (CR), lo que conduce a la generación de una clave de sesión basada en parámetros de entrada permanentes (la clave de sesión SK se calcula como el KDF a partir de la clave permanente (PK) y los parámetros acordados durante la sesión) . Por ejemplo, durante un ataque MITM, un atacante puede reemplazar los parámetros 𝐴𝐶 y 𝑆𝐷 con valores cero durante el proceso de negociación de la sesión y establecer la entropía 𝑆𝐸 en 1, lo que conducirá a la formación de una clave de sesión 𝑆𝐾 con un valor real. entropía de 1 byte (el tamaño de entropía mínimo estándar es de 7 bytes (56 bits), que es comparable en confiabilidad a la selección de clave DES).
Si el atacante logró utilizar una clave más corta durante la negociación de la conexión, entonces puede usar la fuerza bruta para determinar la clave permanente (PK) utilizada para el cifrado y lograr el descifrado del tráfico entre dispositivos. Dado que un ataque MITM puede desencadenar el uso de la misma clave de cifrado, si se encuentra esta clave, se puede utilizar para descifrar todas las sesiones pasadas y futuras interceptadas por el atacante.
Para bloquear las vulnerabilidades, el investigador propuso realizar cambios en el estándar que amplíen el protocolo LMP y cambien la lógica de uso de KDF (Key Derivation Function) al generar claves en modo LSC. El cambio no rompe la compatibilidad con versiones anteriores, pero hace que se habilite el comando LMP extendido y se envíen 48 bytes adicionales. El Bluetooth SIG, responsable del desarrollo de los estándares Bluetooth, ha propuesto rechazar las conexiones a través de un canal de comunicación cifrado con claves de hasta 7 bytes de tamaño como medida de seguridad. Se recomienda que las implementaciones que siempre utilizan el Modo de seguridad 4 Nivel 4 rechacen conexiones con claves de hasta 16 bytes de tamaño.
Fuente: opennet.ru