xg3nesis/rustyinjectorImplementação em Rust da prova de conceito de injeção de teclas de Marc Newlin (CVE-2023-45866).
⚠️ Aviso: Apenas para Fins de Pesquisa e Educacionais
Este projeto é uma Prova de Conceito (PoC) demonstrando injeção de teclas Bluetooth, reimplementada em Rust. Destina-se estritamente a fins educacionais e de pesquisa em segurança.
Ao baixar, clonar ou utilizar este código, você concorda em usá-lo de forma responsável e em conformidade com todas as leis e regulamentos aplicáveis.
Bem-vindo ao Rusty Injector — uma implementação em Rust inspirada na PoC de injeção de teclas Bluetooth de Marc Newlin, vinculada às CVE-2023-45866, CVE-2024-21306 e CVE-2024-0230.
Atualmente, este repositório implementa apenas a CVE-2023-45866, que explora vulnerabilidades de injeção de teclas no BlueZ no sistema operacional Linux.
Abaixo está uma captura de tela da descrição do NIST, incluindo a pontuação CVSS:
Captura 1: Descrição NIST da CVE-2023-45866.
As outras CVEs, CVE-2024-21306 e CVE-2024-0230, não estão planejadas para implementação por mim, mas contribuições são calorosamente bem-vindas.
Antes de entrar em detalhes, encorajo você a assistir à apresentação de Marc Newlin na conferência NullCon 2024, pois ela oferece uma explicação clara e completa dessas vulnerabilidades: Hi, My Name Is keyboard por Marc Newlin..
Também disponibilizei um vídeo que populariza essa vulnerabilidade. Você o encontrará aqui: How a Simple Bluetooth Hack Can Hijack Your Device - Hi, my name is keyboard.
📌 Se você notar pontos faltantes, áreas que poderiam ser melhor simplificadas ou possíveis erros na explicação abaixo, sinta-se à vontade para modificá-la e enviar um merge request. Ficarei feliz em revisar suas contribuições e incorporá-las ao repositório.
Como cobrimos apenas a vulnerabilidade CVE-2023-45866 para sistemas operacionais Linux, explicaremos apenas o processo para alcançar essa exploração específica direcionada à biblioteca BlueZ.
Primeiramente, você deve entender que essa vulnerabilidade é explorável apenas em Bluetooth BR/EDR porque tem como alvo o perfil HID sobre essa tecnologia. Você pode saber que a implementação arquitetural do Bluetooth é dividida em múltiplas camadas, como o modelo OSI para o protocolo Ethernet, e como você pode observar em nosso esquema abaixo.
Diagrama 1: Pilha Bluetooth BR/EDR (Basic Rate - Enhanced Data Rate) simplificada. A camada mais inferior da pilha representa a camada física com uma antena dedicada, e o nível mais alto representa o nível de aplicação ou o que às vezes podemos designar como sistema operacional. Quando dois dispositivos desejam se comunicar, eles passam por essas diferentes camadas: de cima para baixo para pacotes de saída e de baixo para cima para pacotes Bluetooth de entrada.
Após o processo de inquiry, quando os dispositivos determinam que desejam estabelecer uma conexão, eles prosseguem para o processo de pareamento. Esse processo permite a autenticação mútua entre os dispositivos e o estabelecimento de uma chave de criptografia, que é então usada para proteger a comunicação.
A especificação Bluetooth oferece diferentes níveis de autenticação e segurança. Dependendo do mecanismo utilizado para autenticação, o nível de segurança da comunicação pode variar. Os dispositivos podem autenticar com base nos periféricos de entrada e saída que possuem, um conceito chamado de modelos de associação. Você provavelmente já encontrou isso ao parear dois dispositivos — como ser solicitado a inserir um código PIN exibido no outro dispositivo.
Existem quatro modelos de associação de pareamento, determinados pelas capacidades de E/S (Entrada/Saída) dos dispositivos:
Abaixo está uma tabela mostrando qual modelo de associação é usado com base nas capacidades dos nossos dispositivos IoT.
Diagrama 2: Tabela ilustrando modelos de associação Bluetooth BR/EDR inspirada na Bluetooth Core Specification v5.3 - 2.3.5.1 Selecting key generation method Table 2.8: Mapping of IO capabilities to key generation method (página 1573). Para mais informações sobre modos de segurança e modelos de associação, confira este interessante post do blog da Thyrasec: Bluetooth Security: Classic & BLE!
Tenho certeza de que você está intrigado com o método 'Just Works', que é exatamente onde nossa vulnerabilidade reside. Aqui está o problema: este método estabelece o pareamento sem exigir confirmação ou interação do usuário, não deixando nenhuma maneira de verificar a autenticidade do dispositivo de pareamento. Em sistemas Linux, a pilha BlueZ, por padrão, aceitava solicitações de pareamento de dispositivos classificados como NoInputNoOutput (para permitir compatibilidade retroativa). Uma escolha de design verdadeiramente "maravilhosa", você não concorda?
Captura 2: Atualização da configuração padrão do BlueZ para habilitar a segurança Bluetooth e corrigir a CVE-2023-45866.
Após parear com o dispositivo alvo, nosso sistema estabelece uma conexão com o Service Discovery Protocol (SDP) através da porta 1 da camada L2CAP. Conforme mostrado no Diagrama 1, a camada L2CAP serve como um intermediário entre as camadas de serviço inferiores e superiores, fornecendo segmentação, multiplexação e remontagem de pacotes de dados. Através da conexão SDP, identificamos todos os serviços disponíveis no dispositivo alvo e nos conectamos ao serviço Human Interface Profile (HID). O perfil HID, usado pelos sistemas operacionais para processar entradas de teclados e mouses Bluetooth, opera através das portas 17 (HID Control) e 19 (HID Interrupt) da camada L2CAP. Para acessar o perfil HID, nenhuma autenticação é necessária e qualquer dispositivo conectado às portas 17 e 19 da L2CAP é reconhecido como um dispositivo HID.
Um atacante pode personificar os serviços e a classe de dispositivo de um teclado Bluetooth sem fio, explorar o modelo de associação 'Just Works' especificando uma capacidade 'NoInputNoOutput' e injetar teclas não autorizadas no dispositivo alvo.
