Alguns dias atrás, Pesquisadores da Escola Politécnica Federal de Lausanne lançado que eles identificaram vulnerabilidades em métodos de combinação dispositivos que atendem ao padrão Bluetooth Clássico (Bluetooth BR / EDR).
A vulnerabilidade tem o codinome BIAS e o problema permite que o invasor organize a conexão de seu dispositivo falso em vez do dispositivo de um usuário conectado anteriormente e passar com sucesso o procedimento de autenticação sem saber a chave de canal (chave de link) gerada durante o emparelhamento inicial dos dispositivos e permitindo sem repetir o procedimento de confirmação manual em cada conexão.
A essência do método é que quando você conecta para dispositivos que suportam o modo Conexões seguras, o atacante anuncia a ausência desse modo e reverte para um método de autenticação desatualizado (modo "herdado"). No modo "legado", o invasor inicia a mudança de função mestre-escravo e, apresentando seu dispositivo como "mestre", assume o procedimento de autenticação. Em seguida, o invasor envia uma notificação sobre a conclusão bem-sucedida da autenticação, mesmo sem ter uma chave de canal, e o dispositivo se autentica para o outro lado.
O Bluetooth Spoofing Attack (BIAS) pode ser executado de duas maneiras diferentes, dependendo de qual método de emparelhamento simples seguro (Legacy Secure Connections ou Secure Connections) foi usado anteriormente para estabelecer uma conexão entre dois dispositivos. Se o procedimento de emparelhamento foi concluído usando o método Conexões Seguras, o invasor pode alegar que é o dispositivo remoto emparelhado anteriormente que não oferece mais suporte a conexões seguras, reduzindo a segurança da autenticação.
Depois disso, o invasor pode conseguir usar uma chave de criptografia muito curta, contendo apenas 1 byte de entropia e aplicar o ataque KNOB desenvolvido anteriormente pelos mesmos pesquisadores para estabelecer uma conexão Bluetooth criptografada sob o disfarce de um dispositivo legítimo (se o dispositivo tiver proteção contra ataques KNOB e o tamanho da chave não puder ser reduzido, o invasor não será capaz de estabelecer um canal de comunicação criptografado, mas continuará a ser autenticado no host).
Para uma exploração bem-sucedida de vulnerabilidade, o dispositivo do invasor precisa estar ao alcance do dispositivo Bluetooth vulnerável e do invasor você deve determinar o endereço do dispositivo remoto ao qual a conexão foi feita anteriormente.
Os pesquisadores publicaram um kit de ferramentas de protótipo implementando o método de ataque proposto e demonstraram como falsificar a conexão de um smartphone Pixel 2 emparelhado anteriormente usando um laptop Linux e uma placa Bluetooth CYW920819.
O método BIAS pode ser executado pelos seguintes motivos: o estabelecimento de uma conexão segura Bluetooth não é criptografada e a seleção do método de pareamento de conexão segura não se aplica a um pareamento já estabelecido; o estabelecimento de uma conexão segura de Conexões Seguras Legadas sim não requer autenticação mútua, um dispositivo Bluetooth pode realizar uma mudança de função a qualquer momento após a pesquisa de banda base, e os dispositivos que foram emparelhados com Conexões Seguras podem usar Conexões Seguras Legadas ao estabelecer uma conexão segura.
O problema é causado por um defeito de memória e se manifesta em várias pilhas de Bluetooth e o firmware dos chips Bluetooth, incluindo Intel, Broadcom, Cypress Semiconductor, Qualcomm, Apple e Samsung Tokens usados em smartphones, laptops, computadores de placa única e periféricos de vários fabricantes.
Pesquisadores testaram 30 dispositivos (Apple iPhone / iPad / MacBook, Samsung Galaxy, LG, Motorola, Philips, Google Pixel / Nexus, Nokia, Lenovo ThinkPad, HP ProBook, Raspberry Pi 3B +, etc.), que usam 28 chips diferentes e fabricantes notificados sobre a vulnerabilidade dezembro passado. Ainda não foi detalhado qual dos fabricantes lançou atualizações de firmware com a solução.
Diante disso, a organização Bluetooth SIG responsável pelo desenvolvimento de padrões Bluetooth anunciou o desenvolvimento de uma atualização para a especificação Bluetooth Core. A nova edição define claramente os casos em que uma troca de função mestre-escravo é permitida, há um requisito obrigatório para autenticação mútua ao reverter para o modo 'legado' e é recomendado verificar o tipo de criptografia para evitar uma diminuição na conexão Nível de proteção.
fonte: https://www.kb.cert.org