Cambio de rol antes de cifrado
BR/EDR
En la comunicación Bluetooth existen dos roles definidos:
- Central: Define los parámetros físicos de la conexión dentro del piconet.
- Periférico: Sigue los parámetros establecidos por el Central.
El cambio de rol puede ser utilizado por dispositivos diseñados para operar solo como periféricos para evitar actuar como central. Este mecanismo normalmente ocurre durante el establecimiento de la conexión y siempre antes de la autenticación.
Si ocurre un cambio de rol después de la autenticación y antes del cifrado, podría explotarse para atacar la fase de cifrado e intentar extraer la clave temporal usada durante la conexión, comprometiendo la confidencialidad. Por este motivo, los dispositivos no deben permitir cambios de rol tras la autenticación a menos que sean estrictamente necesarios.
Descripción del proceso
Dado que el cambio de rol se produce mediante un mecanismo en capa de enlace (LMP o Link Layer), para verificar que el dispositivo no permite un cambio de rol tras la autenticación existen dos posibles opciones:
- Mediante la revisión del código fuente del firmware de controlador
- Mediante el envío de una solicitud de cambio de rol tras el proceso de autenticación, se captura la respuesta para evaluar si se permite el cambio.
Para el envío de una solicitud de cambio de rol tras el proceso de autenticación es necesario modificar el flujo habitual de mensajes LMP y, por tanto, es necesario tener la capacidad de enviar y recibir mensajes LMP. Para esto, habitualmente, es necesario modificar el firmware del controlador Bluetooth utilizado para realizar la auditoría (no el del dispositivo auditado).
Es necesario introducir modificaciones para que se envíe un mensaje LMP_switch_req justo tras la autenticación y antes del inicio del cifrado. El dispositivo auditado podrá responder con un mensaje LMP_accepted, lo que indica que ha aceptado el cambio de rol y no cumple el control, o con LMP_not_accepted, que sería la respuesta esperada por un dispositivo que cumple el control.
Además, para capturar la respuesta, es necesario poder capturar mensajes LMP, para lo cual se pueden utilizar los mensajes de depuración del controlador Bluetooth: los controladores Broadcom redirigen el tráfico LMP hacia el host en forma de mensajes de depuración.
Para la modificación del firmware, es necesario disponer de un controlador Bluetooth que permita estas modificaciones y del que se disponga del código del firmware (o del que exista un trabajo de ingeniería inversa). Las modificaciones al firmware de la placa de desarrollo Cypress CYW920819EVB-02, realizadas para la investigación de BIAS, son de utilidad en este aspecto.
Recursos relacionados
Para comprobar este control, pueden ser útiles los siguientes recursos:
| ID | Descripción |
|---|---|
| BSAM-RES-04 | Sniff de una conexión Bluetooth |
| BSAM-RES-05 | Captura de una conexión Bluetooth |
| BSAM-RES-06 | Modo depuración en controladores Bluetooth |
| BSAM-RES-07 | Envío y recepción de mensajes HCI |
| BSAM-RES-09 | Cambiar los atributos de un controlador |
Caso de ejemplo
Usaremos Wireshark con BTVS (btvs.exe -Mode wireshark) para realizar la captura de paquetes para su análisis.
«««< HEAD Se dispone de un portátil con la herramienta Scapy que está realizando un emparejamiento con rol de Periférico con otro dispositivo de rol Central. Durante el proceso de conexión existe la posibilidad de realizar un paso extra que se llama cambio de rol. ======= Se dispone de un ordenador con la herramienta Scapy que está realizando un emparejamiento con rol de Periférico con otro dispositivo de rol Central. Durante el proceso de conexión existe la posibilidad de realizar un paso extra que se llama cambio de rol.
fdf8cd6a8e3182eb139f0d88e92313c413b12fbb
El dispositivo Periférico recibe la petición de conexión del dispositivo central mediante el comando HCI_Connection_Request.
Tras esto la respuesta del dispositivo Periférico es aceptar la conexión con el comando HCI_Accept_Connection_Request indicando que su preferencia es trabajar como dispositivo central indicando en el campo Role un valor 0x00 (Become Central for this connection. The LM will perform the role switch.).
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 del procedimiento.
Para saber si este cambio de rol se está produciendo antes del proceso de cifrado 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 aparece después los dos comandos (HCI_Link_Key_Request_Reply / HCI_Command_Complete ) es un role switch previo a la etapa de cifrado.
El resultado del control será FAIL si se localiza el comando HCI_Role_Change con el campo Status con valor 0x00 antes del cifrado de los dispositivos.