Riesgos de ciberseguridad en dispositivos Bluetooth de baja energía (BLE)

Autores: Ramakrishnan Lakshminaryanan y Jasper Nota

Los dispositivos con conexión Bluetooth Low Energy (BLE) son comunes hoy en día. Sin embargo, su uso puede resultar inseguro. Esto ocurre cuando BLE se implementa de forma insegura. Para demostrar el riesgo para la ciberseguridad de este tipo de dispositivos, hemos elegido un aparato médico que los consumidores pueden pedir en varias tiendas web conocidas.

Nota: Antes de publicar este artículo, se hicieron múltiples intentos para informar al fabricante de equipos originales (OEM) sobre las vulnerabilidades descubiertas y las consecuencias que conllevan. Lamentablemente, no se recibió ninguna respuesta del OEM. Bureau Veritas Cybersecurity ha decidido publicar este artículo para aumentar la awareness sobre seguridad entre fabricantes y usuarios.

Múltiples problemas de seguridad

A lo largo de la breve investigación realizada se observaron múltiples problemas de seguridad. A efectos de este artículo, sólo se revelarán los riesgos relacionados con la funcionalidad BLE.

El dispositivo médico

El dispositivo bajo prueba (DUT) es un aparato con certificación médica que permite a los usuarios aliviar el dolor, relajar o fortalecer los músculos a través de electrodos. Este dispositivo puede controlarse mediante la aplicación Android asociada (v4.3.15 en el momento de probar este dispositivo).

Toda la funcionalidad depende de la intensidad fijada por el dispositivo central o periférico. En función del valor de intensidad [mín = 0; máx = 60], la vibración puede sentirse en el cuerpo a través de los parches de electrodos. Dependiendo de la parte del cuerpo en la que se peguen los parches de electrodos, existen una serie de programas de entrenamiento, relajación y recuperación, respectivamente.

Las pruebas comenzaron pegando los parches en los brazos o las piernas. La observación (mientras se realizaban las pruebas en el brazo) fue que cuando el valor de intensidad superaba 25, el brazo experimentaba sacudidas violentas. La intensidad controlaba el movimiento del brazo, lo que dificultaba la resistencia a ese movimiento. Estas vibraciones pueden convertirse en sacudidas graves a intensidades más elevadas o durante cambios bruscos de intensidad.

Servicios y características

Se inició un descubrimiento BLE para identificar la dirección de control de acceso al medio (MAC) asociada al DUT. Una vez identificados, se pudieron enumerar los servicios y características, que son objetos anidados responsables de la gestión de los datos transmitidos:

Observe cómo varios manejadores tienen la propiedad WRITE indicada para el DUT. Esto significa que esos manejadores aceptan datos entrantes del dispositivo central, que en este caso es el teléfono móvil.

De los asideros indicados con acceso de escritura, había varios interesantes, que se enumeran a continuación:

(1) Asa 0007 - Bandera de privacidad periférica

Esta bandera está explícitamente relacionada con la función de privacidad del dispositivo periférico. En otras palabras, es la bandera que determina si el dispositivo periférico soporta la privacidad - activada o desactivada. Probar si este manejador puede ser sobrescrito/desactivado sería una de las cosas interesantes para un atacante.

(2) Handle 000b - Dirección de reconexión

Este manejador contiene información relacionada con la dirección que se utilizará cuando se vuelva a conectar a un dispositivo privado. Dado que este manejador también es un punto de interés desde la perspectiva de un atacante, queríamos verificar si se puede sobrescribir.

(3) Asas 0010, 0011, 0012, 0013 - Relacionadas con las intensidades de vibración

Estas asas contienen valores de intensidad de vibración y, de nuevo, serían asas interesantes de sobrescribir para un atacante.

Como puede verse en la figura anterior, el indicador de privacidad periférica [asa 0007] fue sobrescrito. Por tanto, se concluye que puede desactivarse y activarse. Del mismo modo, el campo "Dirección de reconexión [Mango 000b]" también pudo sobrescribirse, como se muestra en la figura abajo indicada. Las figuras relacionadas con la sobreescritura de los valores de intensidad de vibración se muestran en la siguiente sección de este artículo.

Existen múltiples métodos para analizar el tráfico BLE entre dispositivos, utilizando diversas herramientas de hardware y software.

Uno de los primeros que consideramos fue capturar pasivamente el tráfico BLE utilizando el Ubertooth One y analizar después los paquetes con Wireshark. A continuación se muestra una captura de pantalla que muestra una captura de paquetes utilizando Wireshark. Se pudo examinar la información relacionada con el valor de intensidad de la vibración, el tipo de protocolo que se estaba utilizando y la información de las asas:

En la captura de pantalla anterior, puede verse que los paquetes capturados utilizan el protocolo ATT. ATT, también conocido como protocolo Attribute, forma parte de la pila BLE, que define estrictamente cómo deben representarse los datos en una base de datos de un servidor BLE, y también define la forma en que los datos pueden leerse o escribirse.

Otro enfoque para analizar las comunicaciones BLE consiste en utilizar la técnica de snooping HCI en un teléfono móvil Android rooteado. Básicamente, un dispositivo Android rooteado es un dispositivo modificado que permite al usuario el acceso de superusuario. Proceso por el que un usuario rompe una serie de limitaciones preestablecidas por el fabricante del dispositivo para obtener un control total sobre el sistema operativo. De este modo, se eleva a privilegios de administrador. Una vez establecido el emparejamiento/comunicación BLE, se pueden extraer los registros snoop del dispositivo rooteado para analizar los paquetes capturados.

Los métodos mencionados anteriormente consistían principalmente en husmear de forma pasiva la comunicación BLE para recopilar información sobre el proceso de emparejamiento, el tipo de protocolos establecidos, la dirección MAC del DUT, los diferentes manejadores, etc.

Para interactuar activamente con los diferentes manejadores, se utilizó la herramienta Bettercap, en combinación con un dongle Bluetooth. Los resultados de este enfoque se presentan anteriormente en este artículo.

Secuestro de la comunicación

Una vez analizada la comunicación entre la central y el dispositivo periférico, se intentó establecer una posición de hombre en el medio (MiTM).

La captura de pantalla siguiente muestra cómo se secuestró con éxito una conexión BLE legítima entre el dispositivo móvil y el DUT. Esto significa que el dispositivo central es ahora la máquina atacante en lugar del teléfono móvil:

Cuando el secuestro BLE está en curso, hay indicaciones en la pantalla del móvil y en el panel frontal del DUT de que se está produciendo un comportamiento no regulado.

Indicación 1: El DUT está encendido; no hay ningún programa de entrenamiento activo en la aplicación Android. Normalmente, si un usuario abandona el entrenamiento, el DUT debería apagarse al cabo de unos segundos (Comportamiento regular). Por lo tanto, es imposible que el dispositivo esté en estado ON cuando la aplicación no ejecuta ningún programa, a menos que se mantenga ON por una conexión BLE activa desde otro dispositivo Central. Esto demuestra que la aplicación Android ya no controla el dispositivo, sino que el atacante tiene ahora el control del dispositivo.

Indicación 2: El DUT está encendido; la aplicación Android intenta volver a conectarse al DUT, pero falla con un mensaje que dice que el usuario necesita encender el DUT. Sin embargo, el DUT ya está encendido y el atacante está ejecutando un programa de entrenamiento activo.

Así, las indicaciones anteriores transmiten que el atacante establece una posición MiTM.

Una vez establecida una posición MiTM, se pudo observar la comunicación entre el teléfono móvil y el DUT en formato HEX.

Se observó que, para un mismo valor de intensidad de vibración, había dos formatos de datos HEX en los paquetes BLE capturados:

1. Datos del dispositivo periférico al dispositivo central -> Formato de datos 1 o DF1.
2. Datos del dispositivo central al dispositivo periférico -> Formato de datos 2 o DF2.

Por ejemplo, consideremos el valor de intensidad de vibración 31.
Para el mismo valor, se observaron dos formatos de datos diferentes a lo largo de las pruebas.

El DF1 para el valor 31 se capturó como se muestra a continuación:
Datos LL: 06 1b 17 00 04 00 1b 12 00 4e 4f 54 49 46 59 20 73 74 72 65 6e 67 74 68 20 33 31 0d 0a

DF2 para el valor 31 se capturó como se muestra a continuación:
Datos LL: 02 10 0c 00 04 00 52 55 00 3e 73 74 72 20 33 31 0d 0a
Datos LL: 0a 0f 0b 00 04 00 1b 55 00 73 74 72 3d 33 31 0d 0a

Ambos formatos indican que la fuerza o intensidad de la vibración en los parches de electrodos debe ser 31.

El porcentaje de éxito fue mayor con DF2, al intentar sobrescribir el manejador que contiene el valor de la intensidad de la vibración. Esto tendría sentido, ya que el dispositivo atacante es el nuevo dispositivo central tras secuestrar la conexión BLE y, por tanto, DF2 funcionaría en ese caso. Sin embargo, se produjeron algunos escenarios interesantes basados en el planteamiento anterior -

1. Al estar en un valor de intensidad o fuerza más alto, y sobrescribir el manejador 0x12 con un valor más bajo funcionó, ya que hubo un cambio notable en la intensidad de la vibración, que se podía sentir en la parte del cuerpo donde están pegados los parches de electrodos [mano/pierna]. Sin embargo, volvió al valor original al cabo de un tiempo.
   
2. Aunque estar en un valor de intensidad o fuerza inferior y sobrescribir el mango 0x12 con un valor superior también funcionó, sólo duró un tiempo muy pequeño antes de que volviera al valor original. Además, esto ocurría cuando el delta/diferencia entre el valor original y el valor sobrescrito era pequeño.
3. Mientras que estar en un valor más bajo de intensidad o fuerza, y sobrescribir la manija 0x12 con un valor más alto con un delta/diferencia grande de la intensidad original, no causó ninguna diferencia visible en la vibración en el cuerpo. Como pensamiento en voz alta, esto podría deberse a algún valor delta umbral establecido en el DUT. No entramos en esa parte de la experimentación, ya que el secuestro de la comunicación BLE era nuestro objetivo y alcance.

Los siguientes datos HEX fueron enviados al dispositivo:

Después de sobrescribir el manejador 0x12, el cambio de intensidad de la vibración podía sentirse en la parte del cuerpo a la que estaban fijados los electrodos. Esto demuestra que un atacante tiene pleno control sobre la intensidad fijada para los electrodos.

Conclusión

Hemos demostrado cómo un atacante podría abusar de las comunicaciones BLE cuando los vendedores implementan BLE de forma insegura, lo que podría causar graves daños a los usuarios finales.

Muchos otros dispositivos inteligentes del mercado siguen teniendo una implementación insegura de Bluetooth Low Energy (BLE). ¿Pertenece usted al sector de los dispositivos inteligentes basados en BLE? Le aconsejamos encarecidamente que evalúe sus productos tanto desde el punto de vista funcional como de la seguridad.