BlueTrust, adiós a la privacidad en Bluetooth

BlueTrust es el nombre de una nueva técnica desarrollada por Tarlogic que permite descubrir las relaciones de confianza entre dispositivos Bluetooth con el objetivo de generar datos de interés sobre sus usuarios.

Continuamos con la serie de artículos de investigación realizados sobre la tecnología Bluetooth y los ataques existentes sobre este protocolo. Anteriormente se analizaron de forma teórica los ataques de BIAS y BLESA (introducción a los ataques de BIAS y BLESA); y KNOB y BLURtooth (los ataques KNOB y BLURtooth).

En este artículo se presenta cómo reproducir y poner en práctica los ataques de BIAS y KNOB. Como cabría esperar, el salto del mundo académico (y teórico) al mundo real (y práctico) no es inmediato ni sencillo. A lo largo del artículo se expondrán los principales problemas y obstáculos a los que se ha hecho frente y cómo se han sorteado.

Tras el estudio de los ataques Bluetooth y al análisis detallado realizado sobre el funcionamiento del estándar, se ha descubierto un problema de privacidad existente en el estándar, al que se le ha dado el nombre de BlueTrust.

Bluetooth es un estándar de comunicación para conexiones de corto alcance, generalmente entre dispositivos móviles y de bajo consumo, que se utiliza de forma habitual como alternativa de bajo consumo para redes de área personal (PAN).

BlueTrust y los fallos de seguridad del protocolo

Si bien es cierto que se ha intentado garantizar la seguridad del protocolo al máximo, a lo largo de los años han ido apareciendo nuevos ataques que han puesto de manifiesto fallos de seguridad a nivel de estándar y de implementación del protocolo.

El impacto de estos ataques es dispar ya que un problema de implementación está asociado a un fabricante o a un dispositivo concreto y, en muchos casos, se puede remediar con algún tipo de actualización. Por el contrario, las vulnerabilidades que afectan al estándar impactan sobre todos los dispositivos que trabajen con esa versión de Bluetooth por lo que su repercusión es más relevante y crítica.

Entre los ataques más recientes que afectan a la definición del estándar destacan de forma especial: BIAS y KNOB. Ambos han sido publicados por el equipo de Daniele Antonioli de la Escuela Politécnica Federal de Lausana. Si bien es cierto que la repercusión mediática de dichos ataques ha sido muy pronunciada, es bastante difícil encontrar noticias o registros de implementaciones reales de los mismos. ¿El motivo? La dificultad y el esfuerzo que requieren implementar correctamente los ataques en el mundo real.

En este artículo se presenta BlueTrust, el trabajo de implementación y de desarrollo de los ataques teóricos para llevarlos a un escenario práctico y las conclusiones que se pueden extraer tanto de los ataques implementados como del camino seguido hasta ponerlos en marcha.

Antes de entrar en materia con la descripción e implementación de los ataques, es necesario destacar algunas características de los protocolos de Bluetooth que la convierten en una tecnología particular, y hablar de los protocolos que es necesario conocer para entender la propuesta de BIAS y KNOB.

Bluetooth

Bluetooth cuenta con varias aproximaciones de selección de canal físico para realizar las comunicaciones entre dos dispositivos. Dos de las técnicas existentes son: Adaptive Frequency Hopping (saltos de frecuencia) y la división en Time Slots (bloques temporales). Con la primera técnica se segmenta la información de forma especial (cambiando de canal / frecuencia en el espectro). Con la segunda, se segmenta la información de forma temporal.

Con estas técnicas se amplía el ancho de banda de sus conexiones y evitar interferencias. Si bien es cierto que de forma intrínseca a estas técnicas se ofrece una capa de protección extra porque se dificulta en gran medida la escucha por un tercero de los mensajes transferidos y protegen contra la inyección de mensajes falsos en las comunicaciones, complican mucho la tarea de hacer investigaciones y ataques sobre Bluetooth.

A pesar de que existe la posibilidad de monitorizar todos los canales de Bluetooth simultáneamente, esto resulta en un coste demasiado elevado como para lograr ataques viables y replicables, y, además, requiere reconstruir las secuencias de mensajes intercambiados entre los extremos.

En general, Bluetooth es una tecnología compleja, con múltiples protocolos que interactúan entre sí, documentados en un estándar (Bluetooth Core Specification), de miles de páginas con el que cuesta aclararse: una importante barrera de entrada a la hora de evaluar la seguridad de la tecnología.

La primera división que se plantea en el estándar es la diferenciación entre Bluetooth BR/EDR (Basic Rate / Extended Data Rate) y BLE (Bluetooth Low Energy). La primera variante, conocida comercialmente como Bluetooth Classic, ocupa un ancho de banda mayor y consume más energía, motivo por el que se desarrolló BLE, que está adaptado a dispositivos más pequeños y de menor consumo. BIAS y KNOB afectan a los protocolos de Bluetooth BR/EDR o Classic.

La arquitectura de Bluetooth divide la pila de protocolos entre el huésped y el controlador.

• El huésped está conformado por el dispositivo que requiere la funcionalidad de Bluetooth, es decir el PC, teléfono móvil o auriculares, y gestiona las capas más altas de la pila Bluetooth, habitualmente implementadas como un controlador del sistema operativo del dispositivo. El controlador es el hardware directamente conectado a la antena bluetooth, que controla las capas más bajas de la pila.
• El controlador puede estar integrado en la electrónica del huésped o implementarse como un módulo aparte, y contiene en su firmware la implementación de Bluetooth BR/EDR, BLE o ambos.

Huésped y controlador se comunican a través del protocolo HCI (Host-Controller Interface), que es el que permite al huésped, programado por su usuario, indicar al controlador qué procedimientos ejecutar. Los mensajes HCI limitan las acciones que se pueden llevar a cabo desde el huésped y el grado de control que tiene un programador Bluetooth.

Por otro lado, entre los diferentes protocolos de la pila de Bluetooth BR/EDR, LMP es el protocolo de control, que establece conexiones entre dispositivos, negocia las claves de seguridad y ejecuta los procedimientos de autenticación, así como los cambios en el cifrado de una conexión. LMP forma parte de Bluetooth BR/EDR (BLE utiliza otros protocolos) y se encuentra implementado en el controlador, por lo que, en general, el usuario del huésped no tiene control sobre él.

Estos dos protocolos son los que controlas los procesos que tienen como objetivo los ataques BIAS y KNOB, por lo que dónde se localiza cada uno afecta a la implementación de los ataques.

BIAS y KNOB

Del estudio del estado del arte de la seguridad de Bluetooth, destacan BIAS y KNOB. Se tratan de vulnerabilidades enfocadas en el estándar Bluetooth y que no buscan fallos en implementaciones dependientes de fabricantes. Este enfoque les da un impacto destacable, convirtiéndolas en objetos de estudio interesantes.

La vulnerabilidad de BIAS propone un método para saltarse el proceso de autenticación de una conexión Bluetooth. En combinación con esta vulnerabilidad, KNOB propone un método para reducir la seguridad del cifrado de una conexión y romper la clave de cifrado de una conexión en tiempo de ejecución.

Ambas técnicas, usadas de forma conjunta, presentan un panorama complicado para la tecnología porque inicialmente prometen la posibilidad de romper todas las comunicaciones Bluetooth. Sin embargo, y como cabría de esperar, la realidad es más compleja…

A pesar de que las vulnerabilidades atacan la especificación de Bluetooth, debido a que ambas modifican el flujo de datos del protocolo LMP, se hace necesario modificar el firmware del controlador de Bluetooth para poder llevar a cabo pruebas de concepto. En concreto, en ambas publicaciones se hace uso de un mecanismo no documentado y propietario del fabricante de un adaptador para descargar modificaciones en el firmware original, convirtiendo las pruebas de concepto en dependientes de un fabricante concreto.

Superadas las barreras de entrada de estudiar el estándar para entender las vulnerabilidades en profundidad y adquirir el hardware adecuado en el periodo de escasez de componentes electrónicos que lleva afectando al sector ya al menos dos años, las pruebas realizadas reflejan otras complejidades más profundas…

Aunque las pruebas de concepto demuestran que se tratan de ataques factibles, solo son factibles en situaciones controladas y diseñadas para ser vulnerables. Los ataques descritos parecen no tener una aplicación en escenarios del mundo real en los que realizar un ataque resulta extremadamente más complejo.

Un ejemplo de esto se trata en la prueba de concepto de KNOB, donde se habla de interceptar el tráfico, modificar un valor en un paquete en texto plano para reducir la entropía de las claves de cifrado e inyectarlo en la comunicación.

Este escenario presenta un gran problema debido al diseño de Bluetooth, donde cada paquete se transmite en un canal diferente, dificultando su escucha. A este problema debemos añadir la dificultad de realizar un ataque de jamming selectivo a ese paquete para que el receptor no lo reciba de manera correcta, por no hablar de la posibilidad de inyectar un nuevo paquete en un canal distinto, con el nuevo valor modificado.

Para superar estas dificultades, la prueba de concepto de KNOB modifica el firmware de una de las víctimas, convirtiéndola también en atacante. Esto prueba que el ataque sería teóricamente posible, pero pone manifiesto la necesidad de tener control sobre la víctima antes de realizar el ataque.

Cómo hemos llegado a BlueTrust

BIAS y KNOB presentan dificultades en su implementación que los convierten en ataques poco prácticos para su uso en contextos realistas de auditoría. Sin embargo, por el camino en Tarlogic Security se han identificado modificaciones a los procesos de autenticación de Bluetooth BR/EDR que pueden ser utilizadas en otro contexto: la recopilación de inteligencia a través de Bluetooth. Y es en ese camino en el que ha surgido la técnica BlueTrust.

En un proceso de conexión normal, ejecutado en el firmware del controlador, no se llega a iniciar el proceso de autenticación si no existe una clave de enlace compartida entre los dispositivos, además de que lo habitual es utilizar el procedimiento de autenticación más seguro posible, con autenticación mutua.

Gracias a la prueba de concepto desarrollada para BIAS, se puede adelantar la fase de autenticación y llegar a ejecutarla a pesar de no disponer de una clave de enlace. La PoC de Daniele también modifica el firmware del controlador para utilizar siempre el procedimiento de autenticación clásica como dispositivo maestro, no requiriendo autenticarse ante el dispositivo esclavo.

Utilizando este procedimiento, junto con otros propios del funcionamiento de Bluetooth, se propone descubrir información de emparejamiento de los dispositivos Bluetooth cercanos enviando una petición de autenticación y observando la respuesta.

Un dispositivo con una clave de enlace para el dispositivo suplantado responderá con normalidad a una petición de autenticación, mientras que un dispositivo que no tenga una clave asociada al dispositivo suplantado responderá negativamente o no enviará ningún mensaje de respuesta.

La propuesta se puede extender para trazar las relaciones de emparejamiento de los dispositivos al alcance e inferir información útil sobre sus usuarios, como sus patrones de uso de dispositivos Bluetooth.

Con la metodología descrita, se ha desarrollado una prueba de concepto a llamada BluetTrust. Esta prueba de concepto ha permitido adquirir un conocimiento profundo del funcionamiento de muchas herramientas Bluetooth, así como el desarrollo de bibliotecas que permitirán realizar futuras investigaciones con un menor coste de desarrollo.

La prueba de concepto de BlueTrust incorpora funciones de escaneo de dispositivos cercanos, creación de perfiles automáticamente y suplantación de dispositivos con perfil, además del descubrimiento de emparejamiento entre dispositivos.

Conclusiones sobre BlueTrust

Bluetooth se trata de una tecnología compleja. Esto, en conjunción con una documentación extensa, convierten esta tecnología en una candidata a ser segura por oscurantismo. Las barreras de entrada al estudio de la seguridad de Bluetooth hacen que no se trate de un objetivo asequible y la convierten en poco atractiva ya que es demasiado amplia como para ser estudiada en conjunto.

Estos factores, además de dificultar su estudio, dan lugar a una falta de herramientas con un nivel de consolidación y madurez suficiente como para aportar claridad a posibles investigadores e interesados en la seguridad de Bluetooth. Prueba de ello se puede ver en las pruebas de concepto utilizadas para demostrar las distintas vulnerabilidades de la tecnología, donde comúnmente se usan mecanismos no documentados propios de los fabricantes de hardware Bluetooth.

Superadas estas barreras de entrada, siguen existiendo gran parte del estándar por explorar en busca de mejoras de seguridad. Existen nichos incluso dentro de las áreas exploradas donde todavía no se aprecian sinergias entre ataques y nuevos enfoques de vulnerabilidades existentes.

BlueTrust es un ejemplo de continuación de vulnerabilidades existentes. Supone un trabajo de mejora de herramientas existentes y de documentación de trabajo previo. Este esfuerzo da lugar a nuevas posibilidades no contempladas anteriormente y facilita la investigación futura.

Esta nueva prueba de concepto nos permite descubrir que dispositivos Bluetooth están interconectados, lo cual tiene aplicaciones muy diversas desde la monitorización de espacios seguros para la detección de intrusiones en redes, la detección y localización de dispositivos asociados a una persona, la recopilación de datos sobre hábitos de consumo…

Además de estas utilidades y aplicaciones, BlueTrust pavimenta una línea de investigación y aporta herramientas para continuar con el análisis de la seguridad Bluetooth, donde todavía existe mucho espacio por explorar. En Tarlogic Security tenemos además la intención de que estas investigaciones den como resultado funcionalidades que integraremos en nuestro producto Acrylic Bluetooth LE Analyzer de cara al futuro.

Nota del editor

El logo y nombre de esta vulnerabilidad han sido generados por una IA.