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.