sobre o ataque (Key Negotiation Of Bluetooth), permitindo a interceptação e substituição de informações no tráfego Bluetooth criptografado. Com a capacidade de bloquear a transmissão direta de pacotes durante o processo de negociação de conexão entre dispositivos Bluetooth, o atacante pode forçar a utilização de chaves com apenas 1 byte de entropia para a sessão, possibilitando a aplicação do método de força bruta para determinar a chave de criptografia.
O problema é causado por falhas (CVE-2019-9506) na especificação Bluetooth BR/EDR Core 5.1 e versões anteriores, que permitem o uso de chaves de criptografia muito curtas e não impedem a interferência do atacante durante a fase de negociação de conexão, permitindo a reodnicação para chaves inseguras semelhantes (substituição de pacotes por um atacante não autenticado é possível). O ataque pode ser realizado durante a negociação de conexão dos dispositivos (sessões já estabelecidas não podem ser atacadas) e é eficaz apenas para conexões nos modos BR/EDR (Bluetooth Basic Rate/Enhanced Data Rate), se ambos os dispositivos forem vulneráveis. Em caso de sucesso na quebra da chave, o invasor pode decifrar dados transmitidos e executar a substituição no tráfego de texto cifrado sem que a vítima perceba.
Ao estabelecer uma conexão entre dois controladores Bluetooth A e B, o controlador A, após a autenticação por meio da chave de link (link key), pode sugerir o uso de uma chave de criptografia (encryption key) de 16 bytes de entropia, e o controlador B pode aceitar esse valor ou indicar um valor menor, caso não consiga formar uma chave do tamanho proposto. Em resposta, o controlador A pode aceitar a proposta e ativar o canal de comunicação criptografado. Neste estágio da negociação, a criptografia não é aplicada, portanto o atacante tem a oportunidade de interferir na troca de dados entre os controladores e substituir o pacote com o tamanho de entropia proposto. Como o tamanho aceitável da chave varia de 1 a 16 bytes, o segundo controlador aceitará esse valor e enviará sua confirmação com um tamanho equivalente.
Para reproduzir a vulnerabilidade em condições de laboratório (a atividade do invasor foi emulada em um dos dispositivos), foi proposto
para realizar um ataque.
Para um ataque real, o atacante deve estar na faixa de recepção dos dispositivos-alvo e ser capaz de bloquear temporariamente o sinal de cada dispositivo, o que pode ser implementado através da manipulação do sinal ou da interferência reativa.
A organização Bluetooth SIG, responsável pelo desenvolvimento dos padrões Bluetooth, realizou a correção da especificação número 11838, na qual foram propostas medidas para os fabricantes bloquearem a vulnerabilidade (o tamanho mínimo da chave de criptografia foi aumentado de 1 para 7). O problema em as pilhas Bluetooth e firmwares Bluetooth que atendem ao padrão, incluindo produtos , Broadcom, , , , Qualcomm, Linux, , e (de 14 chips testados, todos se mostraram vulneráveis). No stack Bluetooth do kernel Linux uma correção que permite alterar o tamanho mínimo da chave de criptografia.
Fonte: opennet.ru
