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.
Para ser completamente honesto, o único objetivo era reimplementar a prova de conceito em Rust para obter uma compreensão mais profunda dos detalhes desse exploit. É por isso que nesta primeira iteração, a arquitetura global foi inspirada na PoC em Python de Marc Newlin: Github "hi_my_name_is_keyboard". Em uma reformulação futura, poderia ser implementado de uma maneira mais Rustica.
Crates (= Bibliotecas Rust) usadas durante esta implementação:
[dependencies]
bluer = { version = "0.17.3", features = ["l2cap", "bluetoothd", "id", "rfcomm"] }
tokio = "1.42.0"
regex = "1.11.1"
clap = { version = "4.5.23", features = ["derive"] }
A dependência chave no meu projeto foi 'BlueR', uma API Rust construída sobre a biblioteca C original do BlueZ. Você pode conferir o trabalho deles aqui: GitHub BlueR. Também integrei Tokio para permitir o uso das funções async fornecidas pela biblioteca BlueR. Além disso, utilizei Clap, um analisador de argumentos de linha de comando, e Regex, uma crate que implementa expressões regulares em Rust, para validar entradas do usuário para o 'bt_addr' (Endereço Bluetooth).
Após observação da implementação de Marc Newlin, decomponha a arquitetura em vários passos para replicar a mesma funcionalidade:
--iface ou -i que representa a interface/adaptador Bluetooth a ser usado. Este argumento é opcional; se nada for especificado, tentará acessar um padrão.--target ou -t que é obrigatório e especifica o endereço Bluetooth do alvo.NoInputNoOutput para poder acessar o método de pareamento "Just Works" durante a conexão com o dispositivo alvo.0x002540 para se passar por um teclado.Tentei comentar meu código o máximo possível. Se você o examinar, reconhecerá facilmente todos esses passos. Para torná-lo mais elegante, o próximo passo seria torná-lo mais Rustico, ter uma terminação graciosa e adicionar várias outras funcionalidades, como a capacidade de analisar scripts de teclado (payloads preparados) ou ter uma interface gráfica. Mais uma vez, isso foi apenas para fins educacionais; não tenho certeza se trabalharia em outra iteração deste programa. Mas, novamente, contribuições são calorosamente bem-vindas. Se você tiver alguma dúvida, não hesite em perguntar.
Primeira coisa a notar: Esta ferramenta foi desenvolvida e testada no Ubuntu 24.04.
Para usar esta ferramenta, você precisa desabilitar o serviço HID padrão registrado pelo BlueZ, para que ele possa ser registrado novamente ao lançar o exploit. Siga estes passos:
/etc/systemd/system/bluetooth.target.wants/bluetooth.serviceExecStart=/usr/libexec/bluetooth/bluetoothd
Pela seguinte:
ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=inputsudo systemctl daemon-reload
sudo systemctl restart bluetoothAgora você simplesmente precisa puxar o projeto e executá-lo compilando com cargo build ou executando diretamente especificando os argumentos com:
cargo run -- -i [BT_INTERFACE] -t [BT_TARGET].
Captura 3: Interface de linha de comando do Rusty Injector.
Aqui está um exemplo:
cargo run -- -i hci0 -t AA:BB:CC:DD:EE:FF
Outra coisa a notar é que se você quiser modificar o código e usar a função "set_address" através do trait Configuration, você deve instalar a ferramenta bdaddr para poder usá-la:
# build bdaddr from the bluez source
cd ~/
git clone --depth=1 https://github.com/bluez/bluez.git
gcc -o bdaddr ~/bluez/tools/bdaddr.c ~/bluez/src/oui.c -I ~/bluez -lbluetooth
sudo cp bdaddr /usr/local/bin/
Por favor, note que se você não especificar nenhuma interface Bluetooth, ele tentará acessar uma padrão. E OBVIAMENTE, não se esqueça de conectar uma interface Bluetooth ao seu sistema Ubuntu.🙃
Acredito que cobri tudo — você está pronto para aproveitar ao máximo o Rusty Injector! Se você encontrar algum problema ou tiver comentários ou feedback, fique à vontade para abrir uma issue. Tenha uma experiência incrível e bons hacks! 🚀