Cambio de rol antes de la autenticación

BR/EDR

En una comunicación Bluetooth existen dos roles definidos:

• Maestro (master): Es el rol principal de una “piconet” (red de dispositivos Bluetooth) y define los parámetros físicos de las conexiones.
• Esclavo (slave): Dispositivo que se limita a seguir los pasos del maestro.

Tras el inicio de una conexión física, el dispositivo iniciador se convierte automáticamente en maestro.

En este contexto, el cambio de rol se utiliza habitualmente por dispositivos que sólo pueden actuar como esclavos para evitar ser maestros de la conexión cuando han sido iniciadores de esta.

Sin embargo, este mecanismo puede ser abusado para evitar el proceso de autenticación por parte de un dispositivo que actúa como maestro, ya que el proceso de autenticación Legacy sólo exige que el dispositivo maestro autentique al esclavo, pero no a la inversa.

Por ejemplo, la vulnerabilidad BIAS utiliza esta capacidad para que un dispositivo esclavo pase a ser el maestro de la comunicación justo antes de la autenticación, y así evitar ser autenticado por el otro extremo. Con esta estrategia se puede suplantar la identidad de otros dispositivos frente a una víctima con la que el dispositivo suplantado estuviese emparejado.

Es preferible no permitir el uso del mecanismo de cambio de rol de esclavo a maestro si no es necesario para el funcionamiento normal del dispositivo.

Descripción del proceso

El mensaje de cambio de rol se produce con mensajes LMP, por lo que depende del firmware del controlador Bluetooth.

Para comprobar si un dispositivo permite un cambio de rol de esclavo a maestro, es necesario disponer de un controlador que permita enviar mensajes LMP de cambio de rol en momentos clave de la comunicación.

Las modificaciones al firmware del controlador CYW920819WCD2 realizadas como parte de la PoC de BIAS incluyen un parche para cambiar el rol del dispositivo de esclavo a maestro antes de la autenticación, por lo que, en conjunto con Wireshark, puede utilizarse para comprobar el control, aunque para ello se requiere la placa de desarrollo CYW920819EVB-02, o una compatible con el mecanismo “Patch ROM”.

El proceso consiste en parchear el firmware de la placa (hay un ejemplo de cómo hacerlo en el repositorio de BIAS) y emplear la placa para iniciar una conexión con el dispositivo auditado mientras se captura la comunicación con Wireshark. Antes de iniciar la comunicación es necesario activar los mensajes de depuración de la placa, que incluyen los mensajes LMP enviados y recibidos. Además, se deberá capturar el tráfico a través de la interfaz de Bluetooth monitor y utilizar el disector de mensajes de depuración de Broadcom para observar e interpretar los mensajes LMP correctamente.

Antes de la autenticación, se observará el envío de un mensaje LMP_role_switch. Si el mensaje recibe una respuesta LMP_accepted, el dispositivo se puede cambiar de rol.

Recursos relacionados

Para comprobar este control, pueden ser útiles los siguientes recursos:

Caso de ejemplo

Usaremos Wireshark con BTVS (btvs.exe -Mode wireshark) para realizar la captura de paquetes para su análisis.

Se dispone de un ordenador con la herramienta Scapy, que está realizando un emparejamiento con rol Periférico con otro dispositivo de rol Central. Durante el proceso de conexión existe la posibilidad de realizar un paso extra de cambio de rol.

El dispositivo Periférico recibe la petición de conexión del dispositivo Central mediante el comando HCI_Connection_Request.

La respuesta del dispositivo periférico es aceptar la conexión con el comando HCI_Accept_Connection_Request, notificando que su preferencia es trabajar como dispositivo Central, esto se indica con el valor 0x00 (Become Central for this connection. The LM will perform the role switch.) en el campo Role.

Si el dispositivo remoto acepta este cambio de rol responderá con el comando HCI_Role_Change con el campo Status en valor 0x00 (A Role change has ocurred.). Con cualquier otro valor se indicaría el código de error de este procedimiento.

Para saber si este cambio de rol está siendo antes del proceso de autenticación se deben de localizar el comando HCI_Link_Key_Request_Reply seguido del comando HCI_Command_Complete en la captura de Wireshark.

Si el comando HCI_Accept_Connection_Request está antes de los dos comandos (HCI_Link_Key_Request_Reply / HCI_Command_Complete ) es un role switch previo a la etapa de autenticación.

El resultado del control será FAIL si se localiza el comando HCI_Role_Change con el campo Status con valor 0x00 antes de la autenticación de los dispositivos.