Prueba de concepto de las vulnerabilidades Sweyntooth de Bluetooth Low Energy (BLE).
Este repositorio es parte del resultado de una investigación del ASSET Research Group.
SweynTooth comprende una familia de 18 vulnerabilidades en diferentes kits de desarrollo de software (SDK) de Bluetooth Low Energy (BLE) de seis grandes fabricantes de sistemas en un chip (SoC). Las vulnerabilidades exponen fallos en implementaciones específicas de SoC BLE que permiten a un atacante dentro del alcance de radio provocar bloqueos (deadlocks), caídas (crashes) y desbordamientos de búfer o omitir por completo la seguridad, dependiendo de las circunstancias. (Actualización) También hemos incluido un script de prueba para verificar dispositivos contra la variante BLE KNOB.
Puedes consultar más información sobre las vulnerabilidades, los parches disponibles y los dispositivos afectados en el sitio de divulgación de SweynTooth del ASSET Research Group.
Fitbit, August Smart Lock, Eve Energy, CubiTag y otros dispositivos "inteligentes" están afectados.
Este PoC utiliza librerías bien mantenidas como Scapy y Colorama. El armado y desglose de paquetes BLE se realiza mediante capas de protocolo Scapy personalizadas (bluetooth4LE y bluetooth.py). Hay una fusión en progreso para incluir nuestras adiciones en el repositorio principal de Scapy.
Primero, debes asegurarte de tener Python2.7 en tu sistema y los paquetes de Python indicados en el archivo requirements.txt.
Si estás usando Ubuntu, ejecuta lo siguiente:
sudo apt-get install python2.7
sudo pip install -r requirements.txt
En segundo lugar, SweynTooth utiliza el Nordic nRF52840 Dongle para enviar/recibir paquetes de capa de enlace sin procesar hacia y desde el periférico vulnerable a través del aire. Es necesario flashear el firmware del controlador en la placa antes de iniciar los scripts de Python 2.7.
El binario de nuestro código de firmware está en el archivo nRF52_driver_firmware.zip. Necesitas instalar la herramienta nrfutil para flashear el firmware en la placa. Recuerda poner el nRF52840 en modo DFU antes de flashear (reinicia el dongle USB mientras esté conectado a tu PC presionando el pequeño botón de reinicio).
Puedes ejecutar los siguientes comandos para instalar las dependencias de Python y flashear el firmware:
python -m pip install nrfutil pyserial pycryptodome
nrfutil dfu usb-serial -p COM_PORT -pkg nRF52_driver_firmware.zip
Los scripts funcionan en Linux o Windows. Solo necesitas cambiar el parámetro COM_PORT para que coincida con el nombre del puerto nRF52840.
Si el método de flasheo anterior no funcionó, también puedes flashear el firmware utilizando la nRF Connect App for Desktop, que ofrece una interfaz agradable para flashear el firmware hex (nRF52_driver_firmware.hex).
Después de instalar los requisitos, puedes ejecutar un script de exploit mediante el siguiente comando:
python Telink_key_size_overflow.py COM7 A4:C1:38:D8:AD:A9
El primer argumento es el nombre del puerto serie (generalmente /dev/ttyACM0 en Linux) y el segundo es la dirección del dispositivo BLE vulnerable. Puedes usar cualquier escáner BLE o la nRF Connect App para descubrir dicha dirección.
Tomando como ejemplo la vulnerabilidad de desbordamiento de tamaño de clave (Key Size Overflow), el script proporciona la siguiente salida si el dispositivo vulnerable se cuelga después de la caída:
Si deseas usar SweynTooth a través de una imagen Docker para evitar instalar dependencias de Python, puedes usar el script auxiliar docker.sh para compilar y ejecutar la instancia de Docker, o descargar la imagen Docker precompilada (enlace) disponible en la página de versiones. El uso de docker.sh se describe a continuación.
--------- HELP -------------
sudo ./docker run <script_name> <serial_port> <ble_target_address> - Inicia cualquier script de sweyntooth por su nombre (<script_name>)
sudo ./docker build - Compila el contenedor Docker
sudo ./docker build release - Compila el contenedor Docker y crea una imagen comprimida para la versión
sudo ./docker shell - Inicia el shell del contenedor Docker
---------- EXAMPLE ----------
./docker.sh run extras/Microchip_and_others_non_compliant_connection.py /dev/ttyACM0 f0:f8:f2:da:09:63
Cada script de exploit corresponde a una falla. La siguiente tabla resumen muestra la correspondencia entre la vulnerabilidad y un script para explotarla en los SoC afectados.
Generalmente, los productos que utilizan los SoC afectados emplean un temporizador de vigilancia (watchdog) para reiniciar automáticamente el SoC BLE en caso de que ocurra una falla, por lo que no todos los productos pueden quedar bloqueados. No obstante, debería ser posible obtener alguna indicación visual o auditiva del producto si este se cae y se reinicia.
La vulnerabilidad más crítica de SweynTooth es la Instalación de LTK cero, que permite a un atacante omitir por completo el último procedimiento de emparejamiento de Bluetooth (conexiones seguras) al forzar un procedimiento de configuración de cifrado con un LTK relleno de ceros. Para probar tu dispositivo contra esta vulnerabilidad, el dispositivo debe aceptar o admitir conexiones seguras como método de emparejamiento. Puedes ejecutar el PoC de la siguiente manera:
python Telink_zero_ltk_installation.py COM7 A4:C1:38:D8:AD:A9
Ten en cuenta que los argumentos COM7 y A4:C1:38:D8:AD:A9 son diferentes según tu configuración. Si el dispositivo es vulnerable, el PoC muestra lo siguiente:
El script de bloqueo LLID limpia el campo LLID al enviar solicitudes de versión o solicitudes de emparejamiento de manera alternativa en cada reconexión con el periférico. Esto se hace para desencadenar la vulnerabilidad tanto en los SoC vulnerables de NXP como en los de Cypress. Al ejecutar el script contra el KW41Z vulnerable, la pila queda bloqueada y debería enviar paquetes de capa de enlace fuera de orden. El script intenta detectar cuándo la pila está bloqueada y muestra lo siguiente para dispositivos KW41Z vulnerables:
Los dispositivos Cypress vulnerables generalmente deshabilitan las transmisiones (advertisements) después del ataque. Por lo tanto, deberías ver un mensaje de error que indique que se ha detectado una caída. Al probar este script contra un Fitbit Inspire vulnerable, el reloj inteligente o se cae inmediatamente o deshabilita temporalmente sus transmisiones. Los ataques intermitentes contra este dispositivo deberían causar un mal funcionamiento permanente del BLE, lo que requiere que el usuario reinicie manualmente el Fitbit Inspire.
Si bien KNOB afectó principalmente a dispositivos Bluetooth Classic debido a que el tamaño de la clave se reducía a 1 byte, aún es posible reducir la entropía de la clave de los dispositivos Bluetooth Low Energy a 7 bytes (tamaño de clave mínimo conforme) durante el procedimiento de emparejamiento SMP. La implicación de esta reducción de entropía BLE conforme se discutió en "Low Entropy Key Negotiation Attacks on Bluetooth and Bluetooth Low Energy" por Antonioli, Daniele et. al.
Hemos puesto a disposición un script simple para verificar qué tamaños de clave son aceptados por un dispositivo periférico BLE. Puedes ejecutar el probador de BLE KNOB de la siguiente manera:
# Windows
python extras\knob_tester_ble.py COM6 a4:c1:38:d8:ad:a9
# Linux
python extras/knob_tester_ble.py /dev/ttyACM0 a4:c1:38:d8:ad:a9
No olvides cambiar COM6 y a4:c1:38:d8:ad:a9 a otros valores según el puerto serie del dongle nRF52 (generalmente /dev/ttyACM0 en Linux) y la dirección del dispositivo BLE bajo prueba. Si la herramienta detecta que el periférico acepta tamaños de clave distintos de 16 bytes, los listará como se muestra a continuación:
La carpeta captures contiene algunas capturas de muestra de cada vulnerabilidad. También hemos añadido algunos casos de incumplimiento detectados en algunos SoC.
La carpeta extras contiene algunos scripts adicionales relacionados con incumplimientos y algunas variantes de SweynTooth. Consulta la tabla de scripts extra en extras/README.md para obtener más información.
Esta investigación fue parcialmente apoyada por Keysight Technologies.
| Vulnerabilidad | CVE(s) | Fabricante | Archivo de script |
|---|