Ataques al Link Manager Protocol de Bluetooth con BrakTooth

La tercera entrega de las vulnerabilidades Bluetooth se centra en los ataques de denegación de servicio y ejecución de código en BrakTooth

En esta tercera entrega se presenta una de las publicaciones más recientes acerca de la seguridad en Bluetooth, que afecta al protocolo LMP (Link Manager Protocol): BrakTooth. Como cierre, presentamos las conclusiones extraídas del estudio realizado.

BrakTooth: Causando estragos en el Bluetooth Link Manager

BrakTooth es el nombre de una familia de vulnerabilidades publicada por el grupo de investigación ASSET Research Group de la universidad de tecnología y diseño de Singapur (SUTD, Singapore University of Technology and Design). El estudio original se publicó el 31 de agosto de 2021 y la última actualización se produjo el 8 de noviembre, fecha de publicación de la prueba de concepto.

La familia está compuesta por un total de 16 vulnerabilidades y 6 comportamientos anómalos que afectan a la implementación de la pila de protocolos de Bluetooth Classic (BR/EDR) en 13 SoCs (System on Chip) diferentes de 11 proveedores ampliamente utilizados en la industria.

Entre las vulnerabilidades figuran diferentes denegaciones de servicio (Denegación de Servicio, DoS por sus siglas en inglés) y una ejecución arbitraria de código (ACE, Arbitrary Code Execution) y en ningún caso se requiere emparejamiento (pairing) o autenticación con el dispositivo. Les han sido asignados hasta el momento 25 CVEs y se espera la asignación de 2 más por parte de Intel.

Escenario de ataque

El escenario es el mismo para todos los ataques: se utiliza el kit de desarrollo ESP-WROVER-KIT de Espressif Systems (1), que contiene el SoC ESP32 con un firmware modificado ad-hoc, y un PC (2) conectado a la placa por puerto serie, desde el que se ejecutan los ataques hacia el objetivo.

Tipos de vulnerabilidades

Siguiendo la nomenclatura V1-V16, las vulnerabilidades son clasificadas en función del tipo de impacto que producen en el dispositivo: fallos (crashes) y bloqueos (deadlocks). Los fallos se producen a causa de desbordamientos de buffer o del montículo (heap), violaciones de segmento u otro tipo de errores fatales.

Los bloqueos, por otro lado, llevan al dispositivo a un estado en el que las funcionalidades Bluetooth no están disponibles. Esto se logra, por ejemplo, forzando la desactivación del proceso de page scan, por el que un dispositivo esclavo espera y responde a un dispositivo maestro para iniciar una conexión, o deshabilitando por completo Bluetooth a través de una vulnerabilidad de ejecución arbitraria de código.

Vulnerabilidad ACE

La vulnerabilidad V1 (Feature Pages Execution) es la más relevante del estudio, ya que se trata de una ejecución arbitraria de código en el SoC ESP32 de Espressif Systems, utilizado ampliamente en dispositivos IoT y wearables.

Debido a una falta de comprobación de límites en la biblioteca Bluetooth del SoC al recibir un paquete LMP_feature_response_ext, un atacante puede sobrescribir datos más allá de la tabla Extended Features Table, a la que van destinados los datos del mensaje. En concreto, los datos en el campo Extended Features del paquete se escribirán en el offset marcado por el campo Features Page.

El equipo de investigación ha descubierto que en el offset 0x62 se almacenan callbacks de funciones que serán referenciadas durante la actividad normal del dispositivo. Por lo que, conociendo las funciones disponibles y sus posiciones, estas pueden ser invocadas.

Y de esa forma ejecutar, por ejemplo, un borrado de los datos de usuario almacenados en la NVRAM (función nvs_flash_erase), la desactivación de las funcionalidades WiFi (función disable_wifi_agc) o la desactivación de Bluetooth (función esp_bt_controller_disable). Incluso, si se conocen las direcciones de las funciones para manejar los actuadores conectados por GPIO, estas también podrían ser ejecutadas.

Además de la ejecución de código y la desactivación de funciones, un atacante puede sobrescribir datos hasta producir un fallo en el dispositivo.

Algunas vulnerabilidades DoS

Como ejemplo de vulnerabilidades DoS, pueden citarse V15 y V16, que afectan a los SoCs Intel AX200 y Qualcomm WCN3990, integrados en PCs portátiles y smartphones.

En el caso de V15 (Invalid Timing Accuracy), un error en la liberación de recursos al recibir una respuesta LMP_timing_acc_response malformada produce que los dispositivos afectados sean vulnerables al agotamiento de recursos.

Tras varios envíos del paquete malformado y reconexiones con direcciones Bluetooth diferentes, el dispositivo se vuelve inestable y puede producirse un fallo, en el caso del WCN3990, o la desconexión de los dispositivos Bluetooth conectados previamente, en el caso del AX200.

V16 (Paging Scan Disable), por su parte, permite desactivar el proceso de page scan del esclavo ejecutando un bucle de envío de un paquete LMP_timing_acc_request malformado y reconexión con la misma dirección. Al desactivar el page scan, el dispositivo esclavo no admite conexiones hasta que el usuario lo reinicie para restablecer la conectividad.

Además, los altavoces Xiaomi MDZ-36-DB, los cascos JBL TUNE500BT, así como el módulo XY-WRBT y otros dispositivos de Zhuhai Jieli Technology han resultado vulnerables a fallos y bloqueos producidos mediante paquetes sobredimensionados (V5, LMP Auto Rate Overflow), paquetes truncados (V8, Truncated LMP Accepted), inicios de procedimientos fuera de orden (V9, Invalid Setup Complete) e inundaciones de paquetes (V4, Feature Response Flooding).

Estado actual y PoC

Junto a la publicación de la investigación, se programó un calendario para la publicación de las pruebas de concepto o PoCs con la implementación de los ataques con una fecha límite del 8 de noviembre de 2021. A partir de entonces, las PoCs se encuentran disponibles en el github de Matheus Garbelini, del equipo de investigación.

Hasta la fecha, y con las pruebas de concepto liberadas, cinco de las empresas han producido un parche para cada una las vulnerabilidades que les afectan, cinco han producido parches sólo para parte de las vulnerabilidades o están en proceso de producirlos y en un caso, el de Texas Instruments, no se ha anunciado ningún plan de producción de parches, aunque sí se ha confirmado la reproducción de los problemas.

Además, otras tres empresas, Samsung, Mediatek y Airoha, han contactado con los investigadores indicando que algunos de sus productos se han visto afectados por las vulnerabilidades y ya han producido los correspondientes parches.

Para más información, se puede consultar la web del grupo de investigación ASSET Research Group, donde también se encuentran enlaces al paper y las pruebas de concepto.

Conclusiones e implicaciones de los ataques

En la tabla inferior se presenta a modo de resumen el resultado esperado de cada uno de los ataques escritos en el artículo:

Ataque	Resultado
BIAS	Man-in-the-middle.
BLESA	Suplantación de atributos.
KNOB	Escuchar las comunicaciones (eavesdropping).
BLURtooth	Secuestro del canal de comunicaciones. Man-in-the-middle.
Braktooth	Ejecución de código arbitrario y denegación de servicio

Si bien es cierto que los ataques Bluetooth presentados son reales y están en vigor actualmente, implementarlos es complicado ya que en numerosas ocasiones requiere tener un control profundo sobre la pila de Bluetooth.

De hecho en la mayoría de las PoC analizadas han modificado partes del kernel para poder demostrar la viabilidad de los ataques. Por otro lado, el grupo de trabajo de Bluetooth (Bluetooth SIG) ha ido parcheando la mayoría de las vulnerabilidades con las nuevas versiones de Bluetooth.

Dejando de lado la viabilidad de los ataques y a modo de conclusión, vamos a analizar el impacto real y las implicaciones de los mismos.

En lo referente a los ataques que consiguen un man-in-the-middle (BIAS, BLURtooth), las implicaciones pueden ser muy graves dependiendo del tipo de dispositivo que se esté vulnerando. Por ejemplo, si se ataca un teclado Bluetooth se podrían recuperar credenciales de distintos servicios suponiendo una brecha de seguridad muy alta.

Si por el contrario se vulneran unos cascos inalámbricos, se podría obtener información privilegiada de una conversación telefónica. A modo de tercer ejemplo, si se vulnera un smartwatch, se podría tener acceso a todas las comunicaciones que se intercambian entre el móvil y el reloj (salvo que estén cifradas y se descifren posteriormente en el reloj desde la capa de aplicación).

Implicaciones diferentes

En lo referente a KNOB, BLESA y BLURtooth las implicaciones son un poco diferentes (y quizás son menos críticas dependiendo del caso de uso).

En el caso de KNOB, al forzar la entropía a 1B se pueden reconstruir las comunicaciones de forma análoga al MitM aunque sin interactuar con el dispositivo. No obstante, KNOB precisa de un retardo para poder descifrar la clave, cosa que en el resto de ataques no es necesario.

En lo referente a BLESA, al suplantar atributos se puede forzar a que un dispositivo ejecute ciertas acciones o se desconecte del sistema. Por ejemplo, se puede falsear el nivel de batería de un sistema para que el dispositivo se apague o deje de comunicarse para reducir el consumo de energía.

En lo relativo a BLURtooth, adicionalmente a lo comentado anteriormente con el MitM, este ataque secuestra el canal de comunicaciones, lo que puede ser muy útil para dejar inutilizado un dispositivo durante un tiempo determinado.

Por lo que respecta a Braktooth, además de los dispositivos estudiados, se estima que los SoCs vulnerables son utilizados por más de 1.400 dispositivos que podrían sufrir los mismos problemas, aunque aspectos como el diseño del producto podrían mitigarlos, según hagan uso de las funcionalidades del SoC.

También se debe tener en cuenta que algunos de los dispositivos sólo permiten una única conexión simultánea, lo que impediría la ejecución de un ataque mientras otro dispositivo se encuentre conectado. Por otro lado, a pesar de la liberación de algunos de los parches, depende de los fabricantes de productos finales aplicarlos, por lo que es esperable encontrar en el mercado dispositivos aún vulnerables.

La mayor parte de las vulnerabilidades de Braktooth producen denegaciones de servicio, que pueden ser aprovechadas por un atacante para, al mismo tiempo que desactiva un dispositivo legítimo, suplantarlo con uno falso y comunicarse con el dispositivo maestro. Además, la vulnerabilidad V1 (Feature Pages Execution) puede tener consecuencias imprevistas, más allá de la desactivación de funcionalidades o la corrupción de memoria, debido a la ejecución arbitraria de código.

Para finalizar, es importante recordar que Bluetooth es una tecnología de corto alcance por lo que para realizar este tipo de ataques es necesario estar cerca de la víctima o comprometer un dispositivo con Bluetooth cercano al sistema que se desea vulnerar.

La cercanía es un buen mecanismo para entornos industriales o domésticos pero no por ello debemos confiarnos, hay que tener mucho cuidado con el uso que le damos a Bluetooth (en qué situaciones lo utilizamos, qué datos se intercambian, ver si son sensibles dichos datos…) para evitarnos sustos en el futuro.

Referencias

● ASSET Research Group, Singapore University of Technology and Design: BRAKTOOTH: Causing Havoc on Bluetooth Link Manager”, https://asset-group.github.io/disclosures/braktooth/

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.