BlueTrust, vulnerabilidad Bluetooth. Detalles técnicos

BlueTrust es una vulnerabilidad Bluetooth que permite obtener información sobre dispositivos y usuarios y trazar relaciones de confianza

BlueTrust es un mecanismo de descubrimiento de relaciones de confianza entre dispositivos Bluetooth descubierto por Tarlogic, que permite trazar redes de dispositivos y obtener información sobre su uso y sus usuarios.

En el anterior post sobre BlueTrust se presentó el recorrido de la investigación realizada por el equipo de Innovación de Tarlogic y la prueba de concepto que esta dio como resultado. En este artículo, continuamos detallando el funcionamiento de la vulnerabilidad Bluetooth y los pasos que han sido necesarios para implementarla.

BlueTrust se apoya sobre los descubrimientos realizados en las investigaciones de las vulnerabilidades BIAS y KNOB en Bluetooth. Como avanzábamos en el artículo BlueTrust, adiós a la privacidad en Bluetooth, la explotación de estas vulnerabilidades sólo es viable en determinados escenarios poco prácticos, pero desvelan deficiencias en la seguridad del estándar y como pueden ser aprovechadas.

BlueTrust utiliza la información disponible gracias a la capacidad de suplantación de dispositivos facilitada por las vulnerabilidades de BIAS y KNOB para averiguar qué dispositivos se encuentran enlazados, y así trazar «redes de confianza» entre dispositivos.

Por el camino, se han resuelto las dificultades encontradas en la implementación de las pruebas de concepto originales, automatizando el proceso y simplificando su uso. Estas herramientas pueden ser de ayuda para futuras investigaciones en el estándar Bluetooth, y están publicadas en el repositorio de código de Tarlogic.

El presente artículo muestra las herramientas desarrolladas para la investigación y se profundiza en el funcionamiento de la vulnerabilidad Bluetooth, pero primero, un breve repaso del funcionamiento de BIAS y KNOB y los escollos para su implementación.

1. BIAS y KNOB

BIAS y KNOB son dos de los ataques publicados acerca del estándar Bluetooth en los años 2019 y 2020 que más impacto han tenido en los medios especializados. Publicados por el equipo de Daniele Antonioli, ambos afectan al estándar de Bluetooth y, por tanto, a todos los dispositivos que lo implementan. Parte de nuestra investigación sobre Bluetooth se centró en la reproducción de ambas vulnerabilidades en entornos de laboratorio, descubriendo que su aplicación práctica es limitada y no suponen una amenaza en un entorno realista.

1.1. BIAS

BIAS afecta a la autenticación entre dos dispositivos Bluetooth, permitiendo a un usuario malicioso suplantar a un dispositivo frente a otro. Para ello, aprovecha la posibilidad de utilizar un método de autenticación poco seguro, conocido como Legacy Authentication. La autenticación de Bluetooth funciona en base a retos criptográficos: el dispositivo autenticador (Master) envía un número aleatorio al dispositivo esclavo que se desea autenticar, y este responde con el resultado de cifrar el número aleatorio con la clave compartida entre ambos. El método Legacy Authentication sólo exige que el dispositivo esclavo responda al reto de autenticación, y no espera respuesta de validación por parte del autenticador master, de forma que, si el usuario malicioso es el maestro o se hace pasar por este, puede fingir ser otro dispositivo y superar la autenticación a pesar de no conocer la clave compartida previamente en el emparejamiento.

En caso de que el usuario malicioso actúe como esclavo en la conexión, puede utilizar el mecanismo de cambio de rol antes de que se inicie la autenticación para convertirse en maestro de manera que invierte los roles y puede hacer uso de este fallo.

El mecanismo de cambio de rol permite que un maestro se convierta en esclavo de la comunicación o viceversa, y se introduce en Bluetooth para que los dispositivos que sólo tienen capacidad de operar como esclavos puedan iniciar conexiones. Tras establecer una conexión, el dispositivo iniciador se convierte por defecto en el maestro, pero si el dispositivo no tiene capacidad para operar como tal, puede enviar una solicitud de cambio de rol de maestro a esclavo. Si el otro dispositivo acepta la petición, se intercambian los roles y continúa la comunicación.

BIAS explota la posibilidad inversa: que un esclavo se convierta en maestro. Este cambio de rol puede producirse en cualquier momento tras el inicio de la conexión, por lo que puede realizarse antes de la autenticación, para asegurar que se es el dispositivo maestro y no requerir ser autenticado.

Con esta combinación, el usuario siempre es maestro y nunca necesita autenticarse, por lo que puede hacerse pasar por otro dispositivo.

Sin embargo, tras la autenticación, los dispositivos Bluetooth modernos requieren cifrar las comunicaciones. BIAS se ocupa de evitar la autenticación, pero no aborda el cifrado o descifrado de los datos, por lo que no será capaz de continuar suplantando al dispositivo tras iniciar el cifrado de los datos.

1.2. KNOB

KNOB tiene como objetivo reducir el tamaño de la clave de cifrado para facilitar un ataque de fuerza bruta y así romper el cifrado entre dos dispositivos. Esto permite descifrar tráfico cifrado o, si se realiza en tiempo real y se combina con BIAS, intercambiar información cifrada fingiendo ser otro dispositivo estableciendo una comunicación valida.

La clave que se utiliza durante una sesión de cifrado es una clave temporal (Kc) derivada de la clave de enlace (KL) compartida por ambos dispositivos durante el proceso de emparejamiento, además de números aleatorios intercambiados durante el establecimiento de la conexión, datos del reloj de la comunicación y la dirección del dispositivo maestro.

Tras el cálculo de la clave temporal de cifrado (Kc), se puede negociar un tamaño de clave para disminuir la carga de trabajo durante el cifrado en dispositivos con poca capacidad de cómputo. Durante este proceso de negociación, cada dispositivo propone un tamaño para la clave hasta que ambos aceptan. En ese momento, la clave Kc original, de 128 bits (16 bytes), se acorta eliminando los bytes menos significativos sobrantes hasta el tamaño negociado.

La técnica de KNOB trata de intervenir en la negociación del tamaño de la clave para asegurar que la clave negociada es de pocos bytes. Una clave de tan sólo 1 byte, por ejemplo, es vulnerable a ataques de fuerza bruta con los que obtener la clave de cifrado.

La dificultad de esta vulnerabilidad reside en su implementación, ya que para modificar el tamaño de la clave negociada es necesario interferir en las comunicaciones entre dos dispositivos legítimos, lo que requiere, como mínimo, tener la capacidad de realizar sniffing e inyectar paquetes.

Hacer sniffing en BR/EDR tiene sus propias complicaciones ya que el protocolo Bluetooth utiliza un mecanismo denominado channel hopping, que consiste en transmitir cada paquete en una frecuencia diferente, esto se hace para mejorar la transmisión de datos en entornos con ruido, evitar interferencia y agrega una dificultar mayor a la hora de capturar e inyectar paquetes.

1.3. Combinando BIAS y KNOB

Otra posibilidad es combinar BIAS y KNOB: se suplanta a un dispositivo con BIAS, se inicia una conexión con otro dispositivo vinculado al primero evitando la autenticación y se utiliza KNOB para romper el cifrado. En este punto se podrían enviar y recibir mensajes cifrados como si fuese el dispositivo original.

En la práctica, este caso requiere de la captura de un mensaje cifrado, que se envía por uno de los dispositivos en el momento de la conexión, el descifrado del mensaje, la obtención de la clave y responder a la comunicación antes de que se produzca un cierre de la conexión por inactividad, algo que en el estándar Bluetooth se realiza en un intervalo de tiempo muy corto. Realizar todo el proceso antes de que se cierre la conexión por timeout, no es factible.

Por la dificultad supone el proceso de intervenir las comunicaciones, capturar un mensaje cifrado y descifrarlo en el momento, KNOB no es explotable en un escenario realista, tampoco en combinación con BIAS.

2. Superando los retos de BIAS y KNOB

Parte de la dificultad de puesta en práctica de un ataque que combine BIAS y de KNOB es la falta de herramientas, de forma que muchas de las tareas requieren un trabajo manual.

A continuación, se explica y comparten algunos de los avances, mejoras y automatizaciones realizadas que pueden ser de ayuda a otros investigadores para combinar BIAS y KNOB y abrir nuevas líneas de investigación.

2.1. La placa de desarrollo de Bluetooth: Cypress CYW920819EVB-02

Uno de los problemas encontrados durante la investigación es la falta de herramientas y controladores Bluetooth con los que trabajar. Incluso en aquellos casos en los que se encuentran herramientas, muchas de ellas no están mantenidas o no son compatibles con otras versiones de bibliotecas o software que sí han avanzado.

Un ejemplo de este problema es la falta de soporte para el uso de la tarjeta Cypress CYW920819EVB-02 usada en las investigaciones de BIAS y KNOB. Aunque se usa originalmente en esas investigaciones, no existe documentación para su uso de manera Plug and Play, por ello, durante esta investigación se han elaborado scripts de soporte que permiten que el kernel de Linux detecte automáticamente esta tarjeta y le asociase el driver adecuado.

Más concretamente, se han creado reglas de udev y targets de systemd para la detección y lanzamiento del servicio correspondiente, que, además, sirve como base para dar soporte a más dispositivos con problemas similares. El código se encuentra en el repositorio de GitHub Bluetooth Attach Service, de Tarlogic.

2.2. Disección de mensajes HCI Broadcom con Wireshark

Una vez se consigue un funcionamiento adecuado de la tarjeta usada para las pruebas de concepto de BIAS y KNOB, se hizo evidente la falta de herramientas para la depuración y análisis de lo que sucede durante la ejecución. Más concretamente, no existía una solución funcional que permitiese capturar y estudiar las comunicaciones que estaban teniendo lugar durante la ejecución de pruebas.

Bluetooth divide la implementación de su pila de protocolos entre un dispositivo host, generalmente el sistema operativo de un PC o un móvil, y un dispositivo controlador, un módulo electrónico separado del hardware del host y que implementa las capas más bajas del estándar

El controlador de la placa CYW920819EVB-02 permite activar una función de depuración propietaria del fabricante, Broadcom, que envía hacia el host los mensajes de bajo nivel recibidos y enviados. Estos mensajes de depuración se reciben en el host a través del protocolo HCI, que es el protocolo de comunicación entre el host y el controlador Bluetooth.

Por otro lado, una de las soluciones más extendidas para el análisis de protocolos es Wireshark. Se ha implementado un diseccionador de paquetes para Wireshark con la capacidad para analizar los paquetes HCI de mensajes de depuración de Broadcom, que contienen los mensajes de bajo nivel. Capturar el tráfico de bajo nivel es de gran utilidad para depurar y analizar el comportamiento del adaptador Bluetooth, entre estos mensajes forman parte del protocolo LMP, el protocolo que controla el estado de los enlaces Bluetooth BR/EDR y que implementa las funciones de seguridad como la autenticación y el cifrado.

El código para realizar la disección de estos paquetes se encuentra en el repositorio de Wireshark, en el servidor GitLab de Tarlogic.

2.3. Envío y recepción de mensajes HCI

Contando con la posibilidad de usar el hardware de manera consistente y con una herramienta que permite evaluar y depurar lo que está sucediendo en las capas más bajas del protocolo Bluetooth, el siguiente reto durante la investigación se concentró en torno a la posibilidad de enviar y recibir mensajes de manera programática.

Para lograr el envío y recepción de mensajes, se ha modificado el framework Scapy, esta librería permite la creación de paquetes de diferentes protocolos para su recepción y envio. Scapy ya cuenta con soporte para el envío y recepción de algunos mensajes Bluetooth pero no tiene soporte para interactuar con las capas más bajas de Bluetooth BR/EDR. En concreto, implementa sólo algunos mensajes de HCI, por lo que se ha extendido la biblioteca de mensajes disponibles.

Entre los mensajes añadidos, se incluyen muchos pertenecientes al estándar, como es el caso de los implicados en el descubrimiento BR/EDR o inquiry. Además, se ha implementado el código necesario para añadir mensajes propios de fabricante (vendor specific) y algunos de los mensajes propios de Broadcom, que permiten la manipulación de los controladores de esta marca.

Otro de los retos es interactuar con un dispositivo Bluetooth de manera exclusiva sin que otros servicios del sistema operativo y la pila de host (BlueZ en este caso) tomen control de la comunicación e interrumpan la ejecución de las pruebas. Para evitarlo se ha implementado el Bluetooth User Socket en Scapy: un tipo de sockets para Bluetooth, soportado por sistemas Linux, que permiten un uso exclusivo.

Por otro lado, el envío y recepción de mensajes LMP se implementa en el firmware del controlador, por lo que está fuera del alcance del host. Sin embargo, en el caso de los controladores Broadcom, los mensajes LMP son reenviados al host en forma de mensajes de depuración. Para capturar estos mensajes programáticamente, desde Scapy, es necesario un tipo adicional de socket: Bluetooth Monitor Socket. Se ha añadido soporte para este tipo de sockets en la extensión al framework de Scapy, lo que permite capturar y analizar mensajes LMP.

Ambos tipos de sockets, Bluetooth User Sockets y Bluetooth Monitor Sockets, son soportados por sistemas con kernel Linux a través de la función socket. La implementación realizada para Scapy hace mucho más accesible su utilización en Python y facilita la implementación de herramientas.

Todas las modificaciones de Scapy están disponibles en el fork de Scapy en el Github de Tarlogic.

3. BlueTrust, vulnerabilidad Bluetooth

Tras todo el conocimiento adquirido durante el proceso de investigación y replicación de vulnerabilidades bluetooth se ha desarrollado la vulnerabilidad BlueTrust, empleando el estándar de modo no previsto. Bluetrust reutiliza parte del desarrollo de BIAS y lo aplica al descubrimiento de relaciones de emparejamiento (bonding) entre dispositivos Bluetooth.

Los dispositivos Bluetooth que se han emparejado entre sí comparten una clave de enlace que utilizan durante la autenticación, el cifrado y otras funciones de seguridad. Se puede evidenciar el emparejamiento entre dispositivos comprobando que ambos comparten una clave, sin acceder físicamente al dispositivo ni extraer la información de su firmware.

Esto es lo que se logra explotando la vulnerabilidad BlueTrust que afecta al estándar, que permite obtener relaciones entre dispositivos Bluetooth, poniendo en entredicho la máxima de privacidad con la cual está pensado Bluetooth.

Explotar con éxito BlueTrust requiere cuatro fases:

1. Descubrimiento de dispositivos.
2. Creación de perfiles.
3. Suplantación de dispositivos.
4. Detección de emparejamiento.

3.1. Descubrimiento de dispositivos

El primer paso consiste en la detección de los dispositivos. Esto se realiza mediante el procedimiento documentado en el estándar de Bluetooth y puede realizarse siguiendo el método activo, propio de Bluetooth BR/EDR, o el método pasivo, propio de Bluetooth LE.

El proceso de descubrimiento consiste en activar el modo inquiry del controlador y recibir las respuestas de los dispositivos cercanos, utilizando para ello las modificaciones realizadas a Scapy. En el modo inquiry, el controlador envía solicitudes de descubrimiento y espera a que lleguen respuestas. Los dispositivos descubribles responden a las solicitudes con mensajes que incluyen, entre otra información, la dirección y la clase del dispositivo. Si en los mensajes de respuesta recibidos no se encuentra el nombre de un dispositivo, se solicita explícitamente.

3.2. Creación de perfiles

El ataque de BIAS permite suplantar la identidad de un dispositivo Bluetooth, pero esta identidad está compuesta por diferentes y no todos aparecen en los mensajes de descubrimiento del dispositivo. En concreto, para suplantar la identidad de un dispositivo, son necesarios los siguientes datos:

• Nombre (BT name): nombre del dispositivo.
• Dirección (BT address): dirección MAC.
• Clase (device class): es el tipo de dispositivo según la clasificación de Bluetooth SIG.
• Versión LMP (LMP version): versión del protocolo LMP, que se corresponde con la versión soportada del estándar Bluetooth.
• ID de fabricante (company ID): identificador del fabricante del controlador.
• Subversión LMP (LMP subversión): valor específico del fabricante, que suele corresponderse con la versión del firmware del controlador.
• Características LMP (LMP features): bitfield que indica qué partes del estándar están soportadas por el controlador.
• Capacidades de entrada y salida (IO capabilities): valor que identifica los controles de entrada y salida del dispositivo: si tiene pantalla, teclado o botones.
• Requisitos de autenticación (Authentication requirements): indica las protecciones exigidas durante la autenticación entre dispositivos, incluyendo protección contra MitM, que consiste en requerir el uso de Secure Authetication.

Este conjunto de datos es llamado un perfil de dispositivo y contiene todo lo necesario para suplantarlo frente a otros hasta alcanzar la fase de cifrado. Aparte del nombre, la dirección y la clase, el resto de los datos son intercambiados durante el inicio de una conexión o de un emparejamiento.

Para realizar la obtención de la mayoría de los datos y evitar que el usuario sea notificado, se envían mensajes HCI con la biblioteca de Scapy, en una secuencia de inicio de conexión, solicitud de datos y cierre de conexión. Realizando el intento de conexión de esta forma, los sistemas operativos de los dispositivos no notifican al usuario de que se ha iniciado un intento de conexión.

Sin embargo, hay mensajes que no pueden ser capturados con un proceso tan simple. En concreto, las capacidades de entrada y salida (IO capabilities) sólo se intercambian durante el emparejamiento de dos dispositivos y no se pueden capturar con una conexión normal, sino que es necesario forzar un emparejamiento.

El controlador Bluetooth inicia un emparejamiento cuando, durante una autenticación, el host no conoce una clave de enlace para el dispositivo remoto.

En Linux, la pila de Bluetooth BlueZ permite interactuar con las claves almacenadas mediante la API mgmt-api, y la herramienta btmgmt. Por tanto, para obtener las capacidades de entrada y salida y completar el perfil del dispositivo es necesario eliminar cualquier clave almacenada correspondiente con el dispositivo, enviar una solicitud de conexión y de autenticación y capturar el mensaje con la información de IO Capabilities. Una vez capturado el mensaje, se termina la conexión abruptamente, lo que impide que se notifique al usuario.

3.3. Suplantación de dispositivos

Con el perfil completo, se puede suplantar la identidad del dispositivo utilizando la placa Cypress CYW920819EVB-02.

Los datos identificativos de un dispositivo se almacenan en la memoria del controlador, por lo que será necesario modificar esta memoria. Los mensajes HCI propios del fabricante Broadcom permiten hacer justo esto, sobrescribir los datos del perfil en la memoria del controlador.

A partir de este momento, cuando un dispositivo solicite el nombre, la placa Cypress contestará con el nombre del dispositivo suplantado, y lo mismo con el resto de los parámetros de identidad.

Sin embargo, si la placa Cypress trata de iniciar una conexión con otro dispositivo en este momento, se puede encontrar que el host propio cierra la conexión antes de tiempo. Esto se debe a que la pila de protocolos del host, BlueZ, no encuentra una clave correspondiente al dispositivo remoto, y, en consecuencia, corta la conexión.

Para evitarlo, antes de cada conexión, se añade mediante btmgmt una clave generada de forma aleatoria, que, aun no siendo válida, permite que BlueZ continue hasta la fase de autenticación.

3.4. Detección de emparejamiento

Con la capacidad de escanear el entorno y suplantar dispositivos, se puede proceder al último paso, que consiste en detectar si alguno de los dispositivos descubiertos está emparejado con el dispositivo suplantado. Esto significa que en algún momento ambos dispositivos han estado conectados y por lo tanto han generado una clave compartida, la almacenan para autenticarse mutuamente, es decir, han estado conectados en el pasado.

Durante la autenticación, un dispositivo remoto puede reaccionar de dos maneras durante el intercambio de retos:

• Con un mensaje LMP sres de respuesta al reto, calculado con la clave de enlace.
• Rechazando el reto, mediante un mensaje LMP not accepted, que corta la conexión, o dejando de enviar mensajes.

En el primer caso, se evidencia que el dispositivo conoce la clave compartida, ya que la necesita para calcular la respuesta al reto, y en el segundo caso, que no la conoce.

Esta diferencia permite distinguir si el dispositivo autenticado conoce o no al autenticador. Durante la interacción no se ha llegado a completar una conexión, y tampoco una autenticación, por lo que el usuario del dispositivo no recibe una notificación.

Los mensajes clave que distinguen si un dispositivo responde correctamente al reto de autenticación o no se intercambian en capa LMP, y no en capa HCI, por lo que el host no recibe la información directamente y es necesario utilizar los sockets modo monitor.

Estos sockets permiten observar todos los mensajes del host y recibir mensajes de depuración. Estos mensajes de depuración son definidos por el fabricante del controlador y, en el caso de Broadcom y de la placa Cypress CYW920819EVB-02, contienen los paquetes LMP observados sólo por el controlador Bluetooth. Activando la función de depuración de la placa, con un mensaje HCI específico, y con Sockets monitor, se pueden capturar los mensajes LMP necesarios para detectar el emparejamiento entre dispositivos.

El ciclo descubrimiento – perfilado – suplantación – detección de emparejamiento se puede repetir automáticamente para todos los dispositivos identificados, generando un grafo de relación de los dispositivos conocidos entre sí.

4. Casos de uso de BlueTrust

BlueTrust permite diferentes usos, como la recolección de información personal, que puede ser útil en ejercicios de phishing, pero existen usos más específicos en escenarios que representan nuevas oportunidades de investigación.

4.1. Investigación forense

En el escenario de una investigación forense en la que se encuentran dispositivos Bluetooth, BlueTrust puede ser de utilidad para tomar como evidencia qué dispositivos han estado conectados entre sí.

Esto es especialmente útil en casos en los que no sea posible interactuar normalmente con el dispositivo durante la investigación, por ejemplo, un teléfono móvil que se encuentra bloqueado, pero el Bluetooth se encuentre activa o pueda ser activada externamente.

En este escenario, obtener las relaciones de un dispositivo con el entorno puede servir para recabar pruebas sobre:

• Localización: las conexiones Bluetooth son de corto alcance, por lo que el dispositivo investigado debe haber estado a poca distancia de los dispositivos con los que se haya conectado.
• Relación con otras personas: que dos dispositivos de propietarios diferentes estén emparejados y se hayan conectado indica que sus propietarios han estado en contacto, o al menos sus dispositivos.
• Ampliación de líneas de investigación: los dispositivos con los que el dispositivo investigado esté relacionado pueden contener información adicional que sirva de evidencia durante la investigación. Por ejemplo: el historial de ubicaciones de un teléfono móvil puede servir como evidencia de la ubicación del propietario de unos auriculares Bluetooth relacionados con el teléfono.

4.2. Red Team

Durante un ejercicio de Red Team, el descubrimiento de dispositivos vulnerables que pueden ser utilizados como pivote o punto de acceso a una infraestructura, esta información es muy útil durante la fase de reconocimiento y, en un escenario con dispositivos Bluetooth, distinguir los dispositivos relevantes puede ser un reto y nos amplia la superficie de explotació.

En este caso, BlueTrust puede ser utilizado para distinguir las relaciones entre dispositivos y seleccionar aquellos que pueden ser utilizados como pivote con mayor éxito. Especialmente en ejercicios dirigidos, en los que sólo son relevantes un conjunto limitado de recursos, Bluetrust puede ayudar a perfilar la superficie de ataque de una manera más efectiva y ágil.

La investigación de la seguridad de Bluetooth, incluyendo BIAS y KNOB, ha permitido el desarrollo y publicación de herramientas que simplifican la investigación con dispositivos bluetooth y la hacen más accesible. La publicación de estas herramientas puede abrir la exploración para el descubrimiento de nuevas vulnerabilidades y aplicaciones de las tecnologías Bluetooth.

BlueTrust se apoya sobre la investigación para crear un nuevo mecanismo que permite obtener información de dispositivos Bluetooth y sus usuarios. Permite trazar redes de relaciones entre dispositivos y estas pueden utilizarse, entre otros usos, como método de relacionar diferentes dispositivos en una investigación forense o para incrementar la superficie de ataque en un ejercicio de Red Team.