Daniele Antonioli, un investigador de seguridade Bluetooth que desenvolveu previamente as técnicas de ataque BIAS, BLUR e KNOB, identificou dúas novas vulnerabilidades (CVE-2023-24023) no mecanismo de negociación de sesións de Bluetooth, que afectan a todas as implementacións de Bluetooth que admiten os modos de conexións seguras. " e "Secure Simple Pairing", cumpre coas especificacións Bluetooth Core 4.2-5.4. Como demostración da aplicación práctica das vulnerabilidades identificadas, desenvolvéronse 6 opcións de ataque que nos permiten conectarnos entre dispositivos Bluetooth previamente emparejados. O código coa implementación de métodos de ataque e utilidades para comprobar vulnerabilidades publícanse en GitHub.
As vulnerabilidades foron identificadas durante a análise dos mecanismos descritos na norma para conseguir o segredo directo (Forward and Future Secrecy), que contrarrestan o compromiso das claves de sesión no caso de determinar unha clave permanente (comprometer unha das claves permanentes non debe levar ao descifrado de sesións interceptadas previamente ou futuras) e reutilización das claves de sesión (unha chave dunha sesión non debería ser aplicable a outra sesión). As vulnerabilidades atopadas permiten ignorar a protección especificada e reutilizar unha clave de sesión pouco fiable en diferentes sesións. As vulnerabilidades son causadas por fallos no estándar base, non son específicas de pilas Bluetooth individuais e aparecen en chips de diferentes fabricantes.
Os métodos de ataque propostos implementan diferentes opcións para organizar o spoofing de conexións Bluetooth clásicas (LSC, Legacy Secure Connections baseadas en primitivas criptográficas obsoletas) e seguras (SC, Secure Connections baseadas en ECDH e AES-CCM) entre o sistema e un dispositivo periférico, como así como organizar conexións MITM.ataques para conexións en modos LSC e SC. Suponse que todas as implementacións de Bluetooth que cumpran co estándar son susceptibles a algunha variante do ataque BLUFFS. O método demostrouse en 18 dispositivos de empresas como Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell e Xiaomi.
A esencia das vulnerabilidades redúcese na capacidade, sen violar o estándar, de forzar unha conexión a usar o antigo modo LSC e unha clave de sesión curta (SK) pouco fiable, especificando a entropía mínima posible durante o proceso de negociación da conexión e ignorando o contido da resposta con parámetros de autenticación (CR), o que leva á xeración dunha clave de sesión baseada en parámetros de entrada permanentes (a clave de sesión SK calcúlase como o KDF a partir da clave permanente (PK) e os parámetros acordados durante a sesión) . Por exemplo, durante un ataque MITM, un atacante pode substituír os parámetros 𝐴𝐶 e 𝑆𝐷 con valores cero durante o proceso de negociación da sesión, e establecer a entropía 𝑆𝐸 en 1, o que levará á formación dunha clave de sesión 𝑆𝐾 cunha entropía real de 1 byte (o tamaño de entropía mínimo estándar é de 7 bytes (56 bits), que é comparable en fiabilidade á selección da clave DES).
Se o atacante conseguiu utilizar unha clave máis curta durante a negociación da conexión, pode usar a forza bruta para determinar a clave permanente (PK) utilizada para o cifrado e lograr o descifrado do tráfico entre dispositivos. Dado que un ataque MITM pode desencadear o uso da mesma clave de cifrado, se se atopa esta clave, pódese usar para descifrar todas as sesións pasadas e futuras interceptadas polo atacante.
Para bloquear vulnerabilidades, o investigador propuxo facer cambios no estándar que amplían o protocolo LMP e cambian a lóxica de usar KDF (Key Derivation Function) cando se xeran claves en modo LSC. O cambio non rompe a compatibilidade cara atrás, pero fai que se active o comando LMP estendido e se envíen 48 bytes adicionais. O Bluetooth SIG, que se encarga de desenvolver os estándares Bluetooth, propuxo rexeitar as conexións a través dunha canle de comunicación cifrada con claves de ata 7 bytes de tamaño como medida de seguridade. Recoméndase ás implementacións que usan sempre o Modo de seguranza 4 Nivel 4 a rexeitar conexións con claves de ata 16 bytes de tamaño.
Fonte: opennet.ru