Vulnerabilidade do Bluetooth permite que invasores espionem conexões criptografadas

Vulnerabilidade do Bluetooth permite que invasores espionem conexões criptografadas de mais de um bilhão de dispositivos habilitados para Bluetooth, incluindo smartphones, laptops, dispositivos IoT inteligentes e dispositivos industriais, considerados vulneráveis ​​a uma falha de alta gravidade que poderia permitir que os invasores espionem os dados transmitidos entre os dois dispositivos.

A vulnerabilidade, atribuída como CVE-2019-9506 , reside na maneira como “protocolo de negociação de chave de criptografia” permite que dois dispositivos Bluetooth BR / EDR escolham um valor de entropia para chaves de criptografia durante o pareamento para proteger sua conexão.

Segundo o The Hacker News, o ataque é chamado de Key Negotiation of Bluetooth (KNOB) e a vulnerabilidade pode permitir que atacantes remotos próximos de dispositivos interceptem, monitorem ou manipulem o tráfego criptografado de Bluetooth entre dois dispositivos emparelhados.

O Bluetooth BR/EDR (taxa básica / taxa de dados aprimorada, também conhecido como “Bluetooth Classic”) é um padrão de tecnologia sem fio que foi projetado para uma conexão sem fio contínua relativamente de curto alcance, como transmitir áudio para fones de ouvido ou alto-falantes portáteis.

Do ponto de vista de segurança, a especificação principal do protocolo Bluetooth BR/EDR suporta chaves de criptografia com entropia entre 1 e 16 bytes / octetos, onde o valor mais alto significa mais segurança.

No entanto, os pesquisadores descobriram que a negociação de entropia, que os dispositivos executam sobre o Link Manager Protocol (LMP), não é criptografada nem autenticada, e pode ser sequestrada ou manipulada no ar.

Como funciona a vulnerabilidade de negociação de chave Bluetooth BR/EDR do Bluetooth?

O The Hacker News explica que a vulnerabilidade, recém-descoberta do Bluetooth, pode permitir que um invasor remoto induza dois dispositivos direcionados a aceitar uma chave de criptografia com apenas 1 byte (8 bits) de entropia, facilitando a força bruta das chaves de criptografia negociadas.

O processo de negociação do comprimento da chave de criptografia no Bluetooth BR / EDR Core v5.1 e versões anteriores é vulnerável à injeção de pacotes por um invasor adjacente não autenticado que pode resultar na divulgação de informações e / ou na escalação de privilégios. Isso pode ser conseguido usando um ataque chamado de Negociação de Chave de Bluetooth (KNOB), que ocorre quando terceiros força duas ou mais vítimas a concordar com uma chave de criptografia com apenas um byte de entropia. Depois que a entropia é reduzida, o invasor pode forçar a chave de criptografia com força bruta e usá-la para descriptografar as comunicações.

Por exemplo, suponha que haja dois controladores tentando estabelecer uma conexão: Alice e Bob. Depois de autenticar a chave de link, Alice propõe que ela e Bob usem 16 bytes de entropia. Esse número, N, pode estar entre 1 e 16 bytes Bob pode aceitar, rejeitar e interromper a negociação ou propor um valor menor “, explica um comunicado publicado pelo Centro de Coordenação CERT.

Bob pode querer propor um valor N menor porque ele (o controlador) não suporta a maior quantidade de bytes proposta por Alice. Depois de propor uma quantidade menor, Alice pode aceitá-lo e solicitar a ativação da criptografia da camada de link com Bob, que Bob pode aceitar. ” 

No entanto, ao explorar a vulnerabilidade relatada, “um invasor, Charlie, pode forçar Alice e Bob a usar um N menor, interceptando a solicitação de proposta de Alice para Bob e alterando N.”

Uma vez descriptografado, o invasor pode capturar passivamente as mensagens criptografadas transmitidas pelo tráfego do Bluetooth, descriptografar o texto cifrado e injetar texto cifrado válido válido, tudo em tempo real e furtivo.

Além disso, também é importante observar que, para um ataque ser bem-sucedido:

  • ambos os dispositivos Bluetooth devem estar estabelecendo uma conexão BR/EDR,
  • ambos os dispositivos Bluetooth devem estar vulneráveis ​​a essa falha,
  • o invasor deve ser capaz de bloquear as transmissões diretas entre os dispositivos durante o pareamento e
  • o ataque deve ser realizado durante a negociação ou renegociação de uma conexão de dispositivo emparelhada; as sessões existentes não podem ser atacadas.

Além disso, o comunicado oficial divulgado pelo Bluetooth.com também diz: “Como nem todas as especificações Bluetooth exigem um comprimento mínimo de chave de criptografia, é possível que alguns fornecedores tenham desenvolvido produtos Bluetooth em que o comprimento da chave de criptografia usada em um BR/EDR a conexão possa ser definida por um dispositivo atacante até um único octeto “.

Impacto

Um invasor adjacente não autenticado pode forçar dois dispositivos Bluetooth a usarem apenas 1 byte de entropia. Isso tornaria mais fácil para um invasor a força bruta, pois reduz o número total de chaves possíveis de tentar e daria a eles a capacidade de descriptografar todo o tráfego entre os dispositivos durante essa sessão.

Solução

 

Fornecedores afetados / Atualizações de software / SO e patches

Os fornecedores de host e controlador do Bluetooth devem consultar a “Expedited Errata Correction 11838” do Bluetooth SIG para obter orientação sobre a atualização de seus produtos. 

Essa vulnerabilidade foi descoberta por uma equipe de pesquisadores, incluindo Daniele Antonioli, do SUTD, Dr. Nils Ole Tippenhauer, do CISPA, e o Prof. Kasper Rasmussen, da Universidade de Oxford.

Avaliamos o ataque KNOB em mais de 14 chips Bluetooth de diferentes fornecedores, como Intel, Broadcom, Apple e Qualcomm. Todos os chips aceitam 1 byte de entropia, exceto o chip W1 da Apple que aceita (pelo menos) 7 bytes de entropia, “, disseram os pesquisadores em um artigo detalhado [ PDF ] divulgado ontem.


Para atenuar o ataque KNOB, os mantenedores das especificações Bluetooth recomendam fortemente os fabricantes de dispositivos e fornecedores de software a impor um comprimento mínimo de chave de criptografia de 7 octetos para conexões BR/EDR.

Para corrigir essa vulnerabilidade, vários fornecedores afetados já começaram a lançar atualizações de segurança para seus sistemas operacionais, firmware e software, incluindo:

Fonte: Carnegie Mellon University &  The Hacker News 

Veja também:

Sobre mindsecblog 2399 Artigos
Blog patrocinado por MindSec Segurança e Tecnologia da Informação Ltda.

3 Trackbacks / Pingbacks

  1. CLOUD  SECURITY  Por onde Começar?
  2. Risco de Segurança na nuvem é igual ou menor que on-premisses
  3. Hardening: porquê, como planejar e qual o padrão recomendado!

Deixe sua opinião!