Se exploradas, essas falhas podem permitir que invasores obtenham acesso não autorizado a informações confidenciais ou geralmente causem problemas
Alguns dias atrás Pesquisadores do EURECOM revelaram que eles tenham descobertoAs novas vulnerabilidades (já catalogado em CVE-2023-24023) no mecanismo de negociação de sessão Bluetooth, que afetar todas as implementações Bluetooth que suportam modos de conexão segura” e “Emparelhamento simples e seguro” que atende às especificações de Bluetooth 4.2 a 5.4
De acordo com o estudo EURECOM, Esses dois novos bugs foram aproveitados no mecanismo de derivação de chave de sessão Bluetooth junto com outros dois bugs para facilitar a derivação fraca de chaves de sessão e subsequentes ataques de força bruta para mascarar as vítimas.
“Espera-se que qualquer implementação BR/EDR compatível seja vulnerável a este ataque de estabelecimento de chave de sessão; “No entanto, o impacto pode ser limitado pela negação do acesso aos recursos do host de uma sessão degradada ou pela garantia de entropia de chave suficiente para causar a reutilização da chave de sessão com utilidade limitada para um invasor”.
Sobre BLUFFS (Bluetooth Forward e Future Secrecy)
É mencionado que as vulnerabilidades foram detectados durante uma análise arquitetural na especificação de estabelecimento de sessão Bluetooth (Forward and Future Secrecy), foram identificadas vulnerabilidades de combate, que neutralizam o comprometimento das chaves de sessão no caso de determinação de uma chave permanente. É crucial observar que as vulnerabilidades identificadas surgiram devido a falhas no padrão básico, e essas vulnerabilidades não se limitam a pilhas Bluetooth específicas e se manifestam em chips fabricados por diversos fornecedores.
O ataque funciona usando quatro vulnerabilidades arquitetônicas, incluindo as duas falhas mencionadas acima, ao especificar o processo de estabelecimento de sessão Bluetooth para obter uma chave de sessão fraca e, posteriormente, forçá-la com força bruta para falsificar vítimas arbitrárias.
Menciona-se que o processo de exploração do BLUFFS, é baseado em um atacante dentro do alcance Conexão Bluetooth de dois dispositivos vítimas pode capturar pacotes em texto simples, conhece o endereço Bluetooth da vítima, você pode criar pacotes e negociar uma chave de sessão fraca com o outro, propondo o menor valor de entropia de chave possível e usando um diversificador de chave de sessão constante.
O cenário de ataque assume que o atacante tem como alvo a sessão Bluetooth atual do dispositivo vítima e que pode reutilizar uma chave de sessão fraca para descriptografar mensagens "passadas e futuras".
Em relação ao bug, é relatado que o primeiro erro reside no fato de que, em um par Central-Periférico, o Bluetooth permite que a Central defina todos os valores de diversificação de chaves de sessão, permitindo assim que um invasor conduza unilateralmente a diversificação de chaves ao se passar por uma Central.
O segundo problema é que embora sejam utilizados números aleatórios na diversificação de chaves, não são utilizados nonces, o que significa que os números podem "ser reutilizados em sessões passadas, presentes e futuras sem violar o padrão", pelo que um atacante pode forçar as vítimas a obterem o mesma chave de sessão controlada pelo invasor em todas as sessões.
Como demonstração prática das vulnerabilidades, Seis novos métodos de ataque Bluetooth foram desenvolvidos, que foram chamados de ataques BLUFFS (Bluetooth Forward and Future Secrecy) e é mencionado que permitem falsificar a conexão Bluetooth.
Esses ataques foram classificados como
- A1: Falsificação de uma exchange LSC
- A2: periférico LSC falsificado
- A3: Vítimas do MitM LSC
- A4: Falsificar um SC Central
- A5: Periférico SC falsificado
- A6: Vítima de MitM SC
Cabe mencionar que Para bloquear vulnerabilidades, foram propostas alterações no padrão Bluetooth para expandir o protocolo LMP e alterar a lógica de uso de KDF (Key Derivation Function) ao gerar chaves no modo LSC.
Além disso, É recomendado que Implementações Bluetooth rejeitar conexões de nível de serviço em um link de banda base criptografado com intensidade de chave inferior a 7 octetos, que os dispositivos operem no “modo somente conexões seguras” para garantir força de chave suficiente e que o emparelhamento ocorra por meio do modo “conexões seguras” em oposição ao modo legado.
Finalmente, se você estiver interessado em saber mais sobre o assunto, você pode verificar os detalhes no link a seguir. Para os interessados no código dos métodos de ataque e em verificar as vulnerabilidades, podem consultar estes no GitHub.