Daniele Antonioli, investigador de segurança Bluetooth, que anteriormente desenvolveu técnicas de ataque BIAS, BLUR e KNOB, identificou duas novas vulnerabilidades (CVE-2023-24023) no mecanismo de negociação de sessões Bluetooth, que afetam todas as implementações de Bluetooth que suportam os modos de emparelhamento seguro 'Secure Connections' e 'Secure Simple Pairing', de acordo com as especificações Bluetooth Core 4.2-5.4. Como demonstração prática das vulnerabilidades identificadas, foram desenvolvidas 6 variantes de ataque, capazes de intervir na conexão entre dispositivos Bluetooth emparelhados anteriormente. O código com a implementação dos métodos de ataque e utilitários para verificar a presença de vulnerabilidades foi publicado no GitHub.
As vulnerabilidades foram descobertas durante a análise dos mecanismos descritos na norma para alcançar a segredo direto (Forward and Future Secrecy), que visam combater a comprometimento das chaves de sessão no caso da identificação de uma chave permanente (a comprometimento de uma das chaves permanentes não deve levar à decriptação de sessões previamente interceptadas ou futuras) e à reutilização das chaves de sessão (a chave de uma sessão não deve ser aplicada a outra sessão). As vulnerabilidades encontradas permitem contornar essa proteção e reutilizar uma chave de sessão não confiável em diferentes sessões. As vulnerabilidades são causadas por falhas na norma básica, não são específicas para pilhas Bluetooth individuais e se manifestam em chips de vários fabricantes.
Os métodos de ataque propostos implementam diferentes variantes de spoofing de conexões Bluetooth clássicas (LSC, Legacy Secure Connections baseadas em primitivos criptográficos obsoletos) e protegidas (SC, Secure Connections baseadas em ECDH e AES-CCM) entre o sistema e o dispositivo periférico, além de organizar ataques MITM para conexões nos modos LSC e SC. Supõe-se que todas as implementações de Bluetooth que atendem ao padrão estejam suscetíveis a várias formas do ataque BLUFFS. O funcionamento do método foi demonstrado em 18 dispositivos de empresas como Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell e Xiaomi.
As vulnerabilidades resumem-se à possibilidade de, sem violar o padrão, forçar a conexão a reverter para um modo antigo LSC e uma chave de sessão curta e não confiável (SK), por meio da especificação, no processo de negociação da conexão, da entropia mínima possível e ignorando o conteúdo da resposta com os parâmetros de autenticação (CR), o que resulta na geração de uma chave de sessão baseada em parâmetros de entrada constantes (a chave de sessão SK é calculada como KDF da chave constante (PK) e dos parâmetros acordados durante a sessão). Por exemplo, um atacante durante um ataque MITM pode substituir no processo de negociação da sessão os parâmetros 𝐴𝐶 e 𝑆𝐷 por valores nulos, e definir a entropia 𝑆𝐸 para 1, o que resultará na formação de uma chave de sessão 𝑆𝐾 com uma entropia real de 1 byte (o tamanho mínimo padrão da entropia é de 7 bytes (56 bits), que é comparável em nível de confiabilidade à ruptura de chaves DES).
Se, durante o processo de negociação da conexão, o atacante conseguir fazer com que uma chave mais curta seja utilizada, ele pode então, por meio de ataque de força bruta, determinar a chave constante (PK) usada para criptografia e conseguir decifrar o tráfego entre os dispositivos. Como em um ataque MITM é possível iniciar o uso da mesma chave de criptografia, se essa chave for decifrada, ela pode ser empregada para decifrar todas as sessões passadas e futuras interceptadas pelo atacante.
Para bloquear as vulnerabilidades, foi proposto pelo pesquisador fazer alterações no padrão que expandem o protocolo LMP e modificam a lógica de uso do KDF (Key Derivation Function) na formação de chaves no modo LSC. A alteração não compromete a compatibilidade reversa, mas resulta na inclusão de um comando LMP estendido e na necessidade de envio de 48 bytes adicionais. A organização Bluetooth SIG, responsável pelo desenvolvimento dos padrões Bluetooth, como medida de proteção, sugeriu rejeitar conexões em canais de comunicação criptografados com chaves de até 7 bytes. Implementações que sempre aplicam o nível Security Mode 4 Level 4 são recomendadas a rejeitar conexões com chaves de até 16 bytes.
Fonte: opennet.ru
