Autenticación mutua

BR/EDR

Durante el proceso de autenticación Bluetooth, no es necesario que los dos dispositivos involucrados comprueben la identidad el otro. Esto puede dar pie a ataques de suplantación de identidad, en los que un dispositivo malicioso puede hacerse pasar por otro dispositivo.

El proceso de autenticación se puede realizar mediante los métodos:

  • Legacy Authentication: Realiza autenticación unilateralmente, de maestro a esclavo, y puede permitir que el maestro de una comunicación no sea autenticado. Se debe evitar ya que permite realizar ataques de suplantación de identidad.
  • Secure Authentication: Exige la autenticación de ambas partes de la comunicación, evitando que alguna de ellas sea suplantada por un tercer dispositivo.

Descripción del proceso

Para comprobar si el dispositivo admite Legacy Authentication, es necesario modificar las capacidades LMP del controlador Bluetooth. Las capacidades LMP (LMP features) indican las funcionalidades que soporta el controlador Bluetooth. En concreto, las capacidades “Secure Connections (Host Support)” y “Secure Connections (Controller Support)” indican si el host y el controlador soportan conexiones tipo Secure Connection, que requieren el método de autenticación Secure Authentication.

Para comprobar si el dispositivo puede ser forzado a reducir la seguridad de la autenticación a Legacy Authentication, se establecen los bits correspondientes a las capacidades “Secure Connections (Host Support)” y “Secure Connections (Controller Support)” a 0 en nuestro dispositivo.

Dependiendo del fabricante del controlador, esto será posible utilizando un mensaje específico de HCI. En el caso de la placa de desarrollo CYW920819EVB-02, el fabricante, Broadcom, permite escrituras en memoria RAM a través de un mensaje HCI, y, gracias a la PoC de la vulnerabilidad BIAS, se conoce la localización en memoria de las cadenas de bits correspondientes a las LMP features, por lo que se pueden sobrescribir asegurando siempre que el dispositivo indique que no se soportan las conexiones de tipo “Secure Connection”.

Tras modificar las capacidades del controlador, se inicia una conexión con el dispositivo auditado. Si el dispositivo inicia la autenticación mediante Legacy Authentication el control no se cumple.

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

Descripción del proceso

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

Para habilitar la autenticación mutua entre dos dispositivos uno Central y otro Periférico se tiene que cumplir que el host del dispositivo admita conexiones seguras. Esto se hace indicando un valor 0x01 (Secure_Connections_Host_Support is ‘enabled’. Host supports Secure Connections.) en el campo Secure_Connections_Host_Support del comando HCI_Write_Secure_Connections_Host_Support.

Este paquete deberá de ser localizado en las capturas de Wireshark, durante el proceso de emparejamiento, entre el dispositivo Central y el Periférico para verificar su valor. La no existencia del mismo ya indica que los dispositivos no configuraron la conexión segura.

El resultado del control será FAIL si no se encuentra el comando HCI_Write_Secure_Connections_Host_Support o si se encuentra con un valor del campo Secure_Connections_Host_Support distinto a 0x01.