Bluetooth KNOB y BLURtooth, segunda entrega de los ciberataques Bluetooth

La segunda entrega de los ciberataques Bluetooth se centra en dos amenazas a esta tecnología que han ido cobrando fuerza a lo largo de los últimos tiempos: Bluetooth KNOB y BLURtooth

En esta segunda entrega de los ciberataques Bluetooth se presentan los ataques KNOB y BLURtooth, descubiertos por los investigadores Daniele Antonioli (KNOB, BLURtooth), Nils Ole Tippenhauer (KNOB, BLURtooth), Kasper Rasmussen (KNOB, BLURtooth) y Mathias Payer (BLURtooth).

1. KNOB: Key Negotiation Of Bluetooth BR/EDR

Este ciberataque Bluetooth KNOB se realiza a dispositivos que hacen uso de la versión extendida del Bluetooth clásico (Bluetooth Basic Rate/Extended Data Rate (BR/EDR)). La documentación oficial de este ataque se puede consultar en https://knobattack.com.

En las implementaciones modernas de Bluetooth, se separa la pila de protocolos de Bluetooth en dos componentes que serán relevantes para este ataque: el anfitrión y el controlador. El anfitrión es implementado por el sistema operativo del dispositivo y controla las capas superiores de la pila, mientras que el controlador se ejecuta en el firmware del chip Bluetooth y controla las capas inferiores.

Para la explicación de este ciberataque se hará uso de los mismos roles definidos en el ataque BIAS: Alice y Bob para indicar los dispositivos del canal de comunicaciones que se quiere atacar y Charlie para indicar el atacante.

El objetivo del ciberataque es reducir la entropía de la clave de sesión a un byte de forma que el atacante pueda escuchar la comunicación y averiguar la clave, por fuerza bruta, entre las 256 posibles. Esto es posible debido a que la entropía de la clave se negocia en cada establecimiento de conexión. Puesto que el estándar permite claves de entre 1 y 16 bytes de entropía, se puede interferir en la negociación para forzar la elección de 1 byte.

El proceso se describe para el modo Secure Simple Pairing (SSP), aunque los investigadores indican que también es efectivo en el modo Secure Connections (SC).

Para cada conexión, Alice y Bob calculan una clave de cifrado, KC, basándose en los parámetros KL, BTADD (direcciones Bluetooth), AU_RAND y EN_RAND, donde KL es la clave de enlace negociada durante el emparejamiento y el resto son parámetros públicos. La entropía de KC es siempre de 16 bytes, pero esta no es la verdadera clave utilizada para cifrar las comunicaciones, sino que es K’C, que se deriva de KC reduciendo su entropía a N, siendo N resultado de la negociación de la clave, como se indica a continuación:

El iniciador de la comunicación, Alice, propone una entropía de entre 1 y 16 bytes y Bob la acepta o propone un valor más pequeño. Esta negociación continúa hasta alcanzar un acuerdo común. La negociación se realiza sin cifrado ni autenticación por parte de los dispositivos.

En este caso, Alice y Bob negocian una entropía de 1 byte para K’C. El protocolo introduce este paso para adaptarlo a la regulación sobre cifrado en diferentes países y facilitar las actualizaciones de seguridad.

Para la realización del ataque, asumimos que Charlie, el atacante, no tiene acceso a ningún secreto compartido por Alice y Bob (clave de enlace, KL, y clave de cifrado, KC), pero puede observar los nonces (EN_RAND y AU_RAND), el reloj de Bluetooth y los paquetes intercambiados. El atacante, por tanto, puede interferir en la negociación de la siguiente forma:

En la imagen vemos que Charlie interfiere la propuesta de Alice de establecer la entropía en 16 bytes y, en su lugar, envía a Bob una entropía de 1 byte. Bob acepta la propuesta y Charlie envía a Alice, fingiendo ser Bob, otra propuesta de establecer la entropía en 1 byte.

Ambos extremos aceptan, pensando que el otro ha bajado la entropía porque no soporta claves de cifrado más complejas. El resultado es que se ha establecido una clave de 1 byte de entropía sin necesidad de conocer los parámetros secretos para la comunicación.

En las imágenes anteriores, se puede observar que todo el proceso de negociación se realiza en el nivel del controlador, no del anfitrión. Esto es muy relevante, porque la aplicación que utiliza el protocolo Bluetooth para la comunicación no recibe ningún indicio de que la conexión haya sido interferida.

Una vez se establece con éxito la entropía, el descubrimiento de la clave se realiza por un método exhaustivo o de fuerza bruta. La clave K’C, utilizada para cifrar las comunicaciones, se deriva de KC siguiendo un procedimiento denominado Encryption Key Size Reduction, determinado por la siguiente ecuación:

K’C=g2(N) xor (KC mod g1(N))

En ella, N es la entropía negociada y g1(N) y g2(N) son polinomios determinados por el valor de N, según una tabla. Para el valor 1 de N, g1(1) es 0x00…0xff y g2(1) es el valor 0x00e275a0abd218d4cf928b9bbf6cb08f. Puesto que, para este caso, se hace un módulo a 0xff, sólo hay 256 posibilidades, que pueden ser precalculadas y luego probadas para descifrar los mensajes.

2. BLURtooth: Derivación de claves entre transportes en Bth clásico y Bth de baja energía

Este tipo de ciberataque Bluetooth afecta a las versiones de Bluetooth 4.2 y 5.0 ya que a partir de la versión 5.1 se ha emitido un parche que corrige esta vulnerabilidad. La documentación oficial del ataque se puede consultar en el enlace: BLURtooth_paper.

El ciberataque se basa en un fallo de seguridad que existe en la especificación del estándar relativo a la función de Cross-Transport Key Derivation (CTKD). Esta función permite a dos dispositivos previamente pareados generar las claves Long Term Key (LTK) para Bluetooth Clásico (BT) y de bajo consumo (BLE) a partir de las claves de BLE y BT respectivamente.

Tal y como se especifica en el estándar de Bluetooth, las LTK utilizadas tanto en Bluetooth clásico (BT) como en Bluetooth de bajo consumo (BLE) se obtienen mediante la función CTKD que acepta como parámetros de entrada una clave de longitud 128 bits (16 Bytes) y 2 strings de 4 bytes. Como resultado, la función devuelve una clave de longitud de 128 bits (16 bytes) haciendo uso de AES-CMAC.

Para Bluetooth clásico (BT), los strings utilizados para derivar una clave BLE a partir de la clave BT (KBT → KBLE) son: tmp2 y brle. Por su parte, los strings utilizados para derivar la clave BT a partir de BLE (KBLE → KBT) son tmp1 y lebr.
Para la realización del ataque, el conocimiento se limita a la información disponible en el canal, es decir, a la información que Alice y Bob envían: direcciones BT, nombres BT, authentication requirements, IO capabilities, y device classes.

Así, el atacante (Charlie) no necesita conocer ni las LTK (long term keys) ni las claves de sesión de Alice y Bob.
El funcionamiento del ataque a alto nivel es el siguiente:

1) Se presupone que Alice (master) y Bob (slave) han establecido una conexión vía Bluetooth clásico (BT).
2) Charlie descubre que Bob es emparejable vía BLE. Así, suplanta a Alice y envía una petición de conexión a Bob por BLE. Al ir BT y BLE por canales físicos diferentes no existe una colisión con el tráfico lícito entre Alice y Bob (que discurre por un canal BT).
3) Bob le envía a Charlie una respuesta a su petición de pairing pensando que Alice quiere emparejarse o re-emparejarse vía BLE haciendo uso de CTKD.
4) Charlie y Bob a partir de las claves públicas intercambiadas para calcular DK (shared Diffie-Helman secret). A partir del DK calculado y los nonces intercambiados (NC, NB) ambos dispositivos generan la clave BLE (KBLE).
5) A partir de KBLE ambos dispositivos calculan la clave KBT haciendo uso de la función CTKD.
6) Al sobrescribir la clave KBT, Alice pierde la sesión con Bob. Así, Charlie es capaz de secuestrar el canal de comunicación original.

El funcionamiento del ataque es independiente de si el canal original de la comunicación entre Alice y Bob es sobre BT o sobre BLE. Además, el procedimiento para atacar a Bob es análogo al de Alice con alguna pequeña variación.

Finalmente, haciendo uso de este tipo de ataques se puede construir un ataque más elaborado que dé como resultado un Man-in-the-middle tal y como se puede observar en la imagen inferior.

En el próximo artículo se presentará la familia de ataques Bluetooth BrakTooth así como unas conclusiones y análisis críticos de todos los ataques presentados a lo largo de la serie.

Referencias

● Antonioli, D., Tippenhauer, N. O., & Rasmussen, K. B. (2019). The {KNOB} is Broken: Exploiting Low Entropy in the Encryption Key Negotiation Of Bluetooth BR/EDR. In 28th {USENIX} Security Symposium ({USENIX} Security 19) (pp. 1047-1061).

● Antonioli, D., Tippenhauer, N. O., Rasmussen, K., & Payer, M. (2020). Blurtooth: Exploiting cross-transport key derivation in bluetooth classic and bluetooth low energy. arXiv preprint arXiv:2009.11776.

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

En TarlogicTeo y en TarlogicMadrid.