Daniele Antonioli, pesquisadora de segurança Bluetooth que desenvolveu anteriormente as técnicas de ataque BIAS, BLUR e KNOB, identificou duas novas vulnerabilidades (CVE-2023-24023) no mecanismo de negociação de sessão Bluetooth, afetando todas as implementações Bluetooth que suportam modos de conexões seguras. "Secure Simple Pairing", em conformidade com as especificações Bluetooth Core 4.2-5.4. Como demonstração da aplicação prática das vulnerabilidades identificadas, foram desenvolvidas 6 opções de ataque que nos permitem entrar na conexão entre dispositivos Bluetooth previamente emparelhados. O código com a implementação de métodos de ataque e utilitários para verificação de vulnerabilidades está publicado no GitHub.
As vulnerabilidades foram identificadas durante a análise dos mecanismos descritos na norma para obtenção de sigilo direto (Forward and Future Secrecy), que neutralizam o comprometimento das chaves de sessão no caso de determinação de uma chave permanente (comprometer uma das chaves permanentes não deve levar à descriptografia de sessões previamente interceptadas ou futuras) e reutilização de chaves de sessão (uma chave de uma sessão não deve ser aplicável a outra sessão). As vulnerabilidades encontradas permitem contornar a proteção especificada e reutilizar uma chave de sessão não confiável em sessões diferentes. As vulnerabilidades são causadas por falhas no padrão básico, não são específicas de pilhas Bluetooth individuais e aparecem em chips de diferentes fabricantes.
Os métodos de ataque propostos implementam diferentes opções para organizar a falsificação de conexões Bluetooth clássicas (LSC, Legacy Secure Connections baseadas em primitivas criptográficas desatualizadas) e seguras (SC, Secure Connections baseadas em ECDH e AES-CCM) entre o sistema e um dispositivo periférico, como bem como organizar conexões MITM, ataques para conexões nos modos LSC e SC. Supõe-se que todas as implementações Bluetooth que cumprem o padrão são suscetíveis a alguma variante do ataque BLUFFS. O método foi demonstrado em 18 dispositivos de empresas como Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell e Xiaomi.
A essência das vulnerabilidades se resume à capacidade, sem violar o padrão, de forçar uma conexão a usar o antigo modo LSC e uma chave de sessão curta (SK) não confiável, especificando a entropia mínima possível durante o processo de negociação da conexão e ignorando o conteúdo da resposta com parâmetros de autenticação (CR), o que leva à geração de uma chave de sessão baseada em parâmetros de entrada permanentes (a chave de sessão SK é calculada como o KDF a partir da chave permanente (PK) e parâmetros acordados durante a sessão) . Por exemplo, durante um ataque MITM, um invasor pode substituir os parâmetros 𝐴𝐶 e 𝑆𝐷 por valores zero durante o processo de negociação da sessão e definir a entropia 𝑆𝐸 como 1, o que levará à formação de uma chave de sessão 𝑆𝐾 com uma entropia real de 1 byte (o tamanho mínimo de entropia padrão é 7 bytes (56 bits), que é comparável em confiabilidade à seleção de chave DES).
Se o invasor conseguir usar uma chave mais curta durante a negociação da conexão, ele poderá usar força bruta para determinar a chave permanente (PK) usada para criptografia e conseguir a descriptografia do tráfego entre dispositivos. Como um ataque MITM pode desencadear o uso da mesma chave de criptografia, se essa chave for encontrada, ela poderá ser usada para descriptografar todas as sessões passadas e futuras interceptadas pelo invasor.
Para bloquear vulnerabilidades, o pesquisador propôs fazer alterações no padrão que expandam o protocolo LMP e alterem a lógica de utilização do KDF (Key Derivation Function) na geração de chaves no modo LSC. A alteração não quebra a compatibilidade com versões anteriores, mas faz com que o comando LMP estendido seja habilitado e 48 bytes adicionais sejam enviados. O Bluetooth SIG, responsável pelo desenvolvimento dos padrões Bluetooth, propôs rejeitar conexões através de um canal de comunicação criptografado com chaves de até 7 bytes como medida de segurança. As implementações que sempre usam o Modo de Segurança 4 Nível 4 são incentivadas a rejeitar conexões com chaves de até 16 bytes.
Fonte: opennet.ru