RustyInjector

⚠️ *Descargo de responsabilidad: Solo para fines de investigación y educativos
Este proyecto es una Prueba de Concepto (PoC) que demuestra la inyección de pulsaciones de teclado por Bluetooth, reimplementada en Rust. Está destinado estrictamente a fines educativos y de investigación en seguridad.

• No utilice este código para comprometer sistemas sin autorización explícita.
• Cualquier uso no autorizado, ilegal o poco ético de este proyecto está estrictamente prohibido.
• El autor no asume ninguna responsabilidad por el mal uso o los daños causados por este código.

Al descargar, clonar o utilizar este código, usted acepta usarlo de manera responsable y de conformidad con todas las leyes y regulaciones aplicables.

🦀 Rusty Injector !

Bienvenido a Rusty Injector: una implementación en Rust inspirada en la PoC de inyección de pulsaciones de teclado por Bluetooth de Marc Newlin, vinculada a CVE-2023-45866, CVE-2024-21306 y CVE-2024-0230.

Actualmente, este repositorio solo implementa CVE-2023-45866, que explota vulnerabilidades de inyección de pulsaciones de teclado en BlueZ en el sistema operativo Linux.

A continuación se muestra una captura de pantalla de la descripción del NIST, incluida la puntuación CVSS :

Captura 1 : Descripción NIST de CVE-2023-45866.

Los otros CVEs, CVE-2024-21306 y CVE-2024-0230, no están planificados para ser implementados por mí, pero las contribuciones son bienvenidas.

1. ¿Cómo funciona ?

Antes de entrar en detalles, te animo a ver la presentación de Marc Newlin en la conferencia NullCon 2024, ya que ofrece una explicación clara y exhaustiva de estas vulnerabilidades: Hola, mi nombre es teclado, por Marc Newlin..
También he puesto a disposición un video que divulga esta vulnerabilidad. Lo encontrarás aquí: Cómo un simple hack de Bluetooth puede secuestrar tu dispositivo - Hola, mi nombre es teclado.

📌 Si observas algún punto que falte, áreas que podrían simplificarse mejor o posibles errores en la explicación a continuación, no dudes en modificarlo y enviar una solicitud de fusión (merge request). Me encantará revisar tus contribuciones e incorporarlas al repositorio.

Como solo hemos cubierto la vulnerabilidad CVE-2023-45866, correspondiente a sistemas operativos Linux, solo explicaremos el proceso para lograr esta explotación específica dirigida a la librería BlueZ.

En primer lugar, debes entender que esta vulnerabilidad solo es explotable en Bluetooth BR/EDR porque ataca el perfil HID que se encuentra sobre esta tecnología. Quizás sepas que la implementación arquitectónica de Bluetooth está dividida en múltiples capas, como el modelo OSI para el protocolo Ethernet, y como puedes observar en nuestro esquema a continuación.

Diagrama 1 : Pila simplificada de Bluetooth BR/EDR (Basic Rate - Enhanced Data Rate). La capa más baja de la pila representa la capa física con una antena dedicada, y el nivel más alto corresponde al nivel de aplicación o lo que a veces podemos designar como sistema operativo. Cuando dos dispositivos quieren comunicarse entre sí, atraviesan estas diferentes capas: de arriba hacia abajo para los paquetes salientes y de abajo hacia arriba para los paquetes Bluetooth entrantes.

Después del proceso de descubrimiento (inquiry), una vez que los dispositivos determinan que quieren establecer una conexión, proceden al proceso de emparejamiento. Este proceso permite la autenticación mutua entre los dispositivos y el establecimiento de una clave de cifrado, que luego se utiliza para asegurar la comunicación.

La especificación Bluetooth ofrece diferentes niveles de autenticación y seguridad. Dependiendo del mecanismo utilizado para la autenticación, el nivel de seguridad de la comunicación puede variar. Los dispositivos pueden autenticarse según los periféricos de entrada y salida que posean, un concepto conocido como modelos de asociación. Probablemente te hayas encontrado con esto al emparejar dos dispositivos, como cuando se te pide introducir un PIN mostrado en el otro dispositivo.

Hay cuatro modelos de asociación de emparejamiento, determinados por las capacidades de E/S (Entrada/Salida) de los dispositivos:

• Just Works (No autenticado)
• Numeric Comparison (Autenticado)
• Passkey Entry (Autenticado)
• Out of Band (Autenticado) – Depende de otra tecnología para facilitar el proceso de emparejamiento.

A continuación se muestra una tabla que indica qué modelo de asociación se utiliza según las capacidades de nuestros dispositivos IoT.

Diagrama 2 : Tabla que ilustra los modelos de asociación de Bluetooth BR/EDR inspirada en la Bluetooth Core Specification v5.3 - 2.3.5.1 Selección del método de generación de claves, Tabla 2.8 : Mapeo de las capacidades de E/S al método de generación de claves (página 1573). Para obtener más información sobre los modos de seguridad y los modelos de asociación, consulta esta interesante publicación de blog de Thyrasec: Bluetooth Security : Classic & BLE !

Estoy seguro de que te intriga el método 'Just Works', que es precisamente donde reside nuestra vulnerabilidad. Este es el problema: este método establece el emparejamiento sin requerir confirmación ni interacción del usuario, sin dejar forma de verificar la autenticidad del dispositivo que se empareja. En los sistemas Linux, la pila BlueZ, por defecto, aceptaba solicitudes de emparejamiento entrantes de dispositivos clasificados como NoInputNoOutput (para permitir la compatibilidad hacia atrás). Una elección de diseño realmente "maravillosa", ¿no crees?

Captura 2 : Actualización de la configuración por defecto de blueZ para habilitar la seguridad de Bluetooth y parchear CVE-2023-45866.

Después de emparejarse con el dispositivo objetivo, nuestro sistema establece una conexión con el Protocolo de Descubrimiento de Servicios (SDP) a través del puerto 1 de la capa L2CAP. Como se muestra en el Diagrama 1, la capa L2CAP actúa como intermediario entre las capas de servicio inferiores y superiores, proporcionando segmentación, multiplexación y reensamblaje de paquetes de datos. A través de la conexión SDP, identificamos todos los servicios disponibles en el dispositivo objetivo y nos conectamos al servicio de Perfil de Interfaz Humana (HID). El perfil HID, utilizado por los sistemas operativos para procesar la entrada de teclados y ratones Bluetooth, opera a través de los puertos 17 (Control HID) y 19 (Interrupción HID) de la capa L2CAP. Para acceder al perfil HID, no se requiere autenticación y cualquier dispositivo conectado a los puertos 17 y 19 de L2CAP es reconocido como un dispositivo HID.

Un atacante puede suplantar los servicios y la clase de dispositivo de un teclado inalámbrico Bluetooth, explotar el modelo de asociación 'Just Works' especificando una capacidad 'NoInputNoOutput', e inyectar pulsaciones de teclado no autorizadas en el dispositivo objetivo.

2. ¿Cómo se implementó ?

Para ser completamente honesto, el único objetivo era reimplementar la prueba de concepto en Rust para obtener una comprensión más profunda de los detalles de este exploit. Por eso, en esta primera iteración, la arquitectura global se inspiró en el PoC en Python de Marc Newlin: GitHub "hi_my_name_is_keyboard". En una futura reelaboración, podría implementarse de una manera más 'rusty' (idiomática de Rust).

Crates (= Bibliotecas de Rust) utilizadas durante esta implementación :

[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"] }

La dependencia clave en mi proyecto fue 'BlueR', una API de Rust construida sobre la librería C original de BlueZ. Puedes ver su trabajo aquí: GitHub BlueR. También integré Tokio para habilitar el uso de las funciones async proporcionadas por la librería BlueR. Además, utilicé Clap, un analizador de argumentos de línea de comandos, y Regex, un crate que implementa expresiones regulares en Rust, para validar las entradas del usuario para 'bt_addr' (Dirección Bluetooth).

Después de observar la implementación de Marc Newlin, descompuse la arquitectura en varios pasos para replicar la misma funcionalidad:

1. Analizar los argumentos del usuario que se utilizan para obtener:
   • --iface o -i, que representa la interfaz/adaptador Bluetooth a utilizar. Este argumento es opcional; si no se especifica, intentará alcanzar uno por defecto.
   • --target o -t, que es obligatorio y especifica la dirección Bluetooth del objetivo.
2. Desplegar un agente Bluetooth con capacidades NoInputNoOutput para poder acceder al método de emparejamiento 'Just Works' durante la conexión con el dispositivo objetivo.
3. Registrar un perfil con los servicios de teclado HID y registrar la clase 0x002540 para suplantar un teclado.
4. Crear todos los enums y funciones para convertir nuestras entradas en los bytes HID correctos que se enviarán en los paquetes HID.
5. Lanzar conexiones a los puertos correctos en la capa L2CAP (Puerto 1 - SDP, Puerto 17 - Control HID y Puerto 19 - Interrupción HID) e inyectar pulsaciones de teclado ilegítimas.

He intentado comentar mi código tanto como sea posible. Si lo revisas, reconocerás fácilmente todos estos pasos. Para hacerlo más elegante, el siguiente paso sería hacerlo más 'rusty', tener una terminación ordenada y añadir varias otras funcionalidades como la capacidad de analizar scripts de teclado (payloads preparados) o tener una interfaz gráfica de usuario. Una vez más, esto fue solo con fines educativos; no estoy seguro de trabajar en otra iteración de este programa. Pero, de nuevo, las contribuciones son bienvenidas. Si tienes alguna pregunta, no dudes en preguntar.

3. ¿Cómo se usa ?

Primera cosa a tener en cuenta: esta herramienta fue desarrollada y probada en Ubuntu 24.04.

Para usar esta herramienta, debes deshabilitar el servicio HID predeterminado registrado por BlueZ, para que pueda volver a registrarse al lanzar el exploit. Sigue estos pasos:

• Edita el archivo de configuración /etc/systemd/system/bluetooth.target.wants/bluetooth.service
• Modifica la línea : ExecStart=/usr/libexec/bluetooth/bluetoothd Por la siguiente : ExecStart=/usr/libexec/bluetooth/bluetoothd --noplugin=input
• Después de modificar el archivo, necesitas recargar la configuración de systemd y reiniciar el servicio Bluetooth para aplicar los cambios. sudo systemctl daemon-reload sudo systemctl restart bluetooth

Ahora simplemente necesitas clonar el proyecto y ejecutarlo compilándolo con cargo build o ejecutándolo directamente especificando los argumentos con: cargo run -- -i [BT_INTERFACE] -t [BT_TARGET].

Captura 3 : Interfaz de línea de comandos de Rusty Injector.

Aquí tienes un ejemplo: cargo run -- -i hci0 -t AA:BB:CC:DD:EE:FF

Otra cosa a tener en cuenta es que si quieres modificar el código y hacer uso de la función "set_address" a través del trait Configuration, debes instalar la herramienta bdaddr para poder usarla:

# 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/

Ten en cuenta que si no especificas ninguna interfaz Bluetooth, intentará alcanzar una por defecto. Y OBVIAMENTE, no olvides conectar una interfaz Bluetooth a tu sistema operativo Ubuntu.🙃

Creo que he cubierto todo: ¡ya estás listo para aprovechar al máximo Rusty Injector! Si encuentras algún problema o tienes comentarios o sugerencias, no dudes en abrir un issue. ¡Que tengas una experiencia increíble y feliz hacking! 🚀