Cambio de rol antes de la autenticación

BR/EDR

En Bluetooth Classic (BR/EDR), los dispositivos operan con dos roles:

• Central: establece parámetros físicos.
• Peripheral: sigue las instrucciones del Central.

El dispositivo que inicia la conexión adopta automáticamente el rol Central.

El cambio de rol puede explotarse para evadir autenticación, ya que en autenticación heredada solo el Central autentica al Peripheral. Ataques como BIAS aprovechan este comportamiento forzando un cambio de rol antes de la autenticación, permitiendo que un atacante suplante un dispositivo previamente emparejado.

Para reducir este riesgo, este mecanismo debe evitarse salvo que sea estrictamente necesario.

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.