francozappa/blurBLURtooth: Explotando la derivación de claves entre transportes en Bluetooth Clásico y Bluetooth de Baja Energía [CVE-2020-15802] [CVE-2022-20361]
Repositorio sobre los ataques BLUR presentados en AsiaCCS'22 en el artículo titulado: BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy.
Enlaces útiles: pdf, video, slides, website.
Entrada BibTex:
@inproceedings{antonioli22blur,
author={Antonioli, Daniele and Tippenhauer, Nils Ole and Rasmussen, Kasper
and Payer, Mathias},
title={{BLURtooth: Exploiting Cross-Transport Key Derivation in
Bluetooth Classic and Bluetooth Low Energy}},
booktitle={Proceedings of the Asia conference on computer and
communications security (ASIACCS)},
month={May},
year={2022}
}
Los ataques BLUR han sido asignados CVE-2020-15802 y CVE-2022-20361.
En el resto del README indicamos Bluetooth Classic (alias BR/EDR) como BT, Bluetooth Low Energy como BLE, y Cross-Transport Key Derivation como CTKD. También asumimos que el dispositivo atacante y las víctimas soportan BT, BLE y CTKD. Esto significa que los dispositivos soportan Bluetooth 4.2+ y BT/BLE Secure Connections.
La forma más sencilla de realizar los ataques es usar un dispositivo tanto como víctima como dispositivo atacante. Por ejemplo, recomendamos usar un portátil Linux como víctima/dispositivo atacante y cualquier otro dispositivo como la otra víctima.
Estamos usando una máquina Linux que ejecuta bluez
y herramientas bluez. Nos
apoyamos en la herramienta btmgmt y puede ser útil echar un vistazo a su
código fuente. En
particular, usamos su subcomando pair que, entre otros, permite enviar solicitudes
de emparejamiento arbitrarias sobre BT/BLE declarando capacidades de entrada/salida arbitrarias.
Usage: pair [-c cap] [-t type] <remote address>
Si deseas reproducir el escenario de ataque exacto presentado en nuestro artículo, debes hacer algo de trabajo adicional. Específicamente, necesitas reproducir la configuración presentada en BIAS attack. Una vez que tu configuración esté lista deberías poder usar la placa de desarrollo como tu Controlador BT/BLE, y el portátil Linux como un Host. Además, deberías poder sniffear los paquetes de la capa de enlace desde el Host (por ejemplo, tráfico BT LMP) y parchear dinámicamente el firmware de la placa de desarrollo en tiempo de ejecución usando internalblue.
Este paso es opcional y requiere parchear tu propio kernel de Linux.
Cuando se usa btmgmt -c 3, bluez automáticamente desactiva el flag de protección MitM,
por ejemplo, establece el byte AuthReq a 0x02 en lugar de 0x03.
Sin embargo, los ataques BLUR no requieren desactivar este flag, solo requieren
declarar capacidades NoInputNoOutput cuando el dispositivo remoto soporta
capacidades de entrada/salida. Haciendo este truco, el procedimiento de emparejamiento se
degrada a Just Works sin desactivar el flag MitM.
Implementar esta configuración requiere una modificación mínima del kernel de Linux. En
particular, en /net/bluetooth/hci_event.c cambiamos:
cp.authentication = conn->auth_type;
por:
cp.authentication = 0x03;
Al hacerlo, codificamos nuestro flag AuthReq a 0x03 independientemente de las
capacidades de entrada/salida que declaremos.
Empareja los dispositivos víctimas como de costumbre. Por ejemplo, si estás atacando un teléfono inteligente, emparejalo con tu portátil (actuando tanto como víctima como dispositivo atacante). Puede ser necesaria alguna interacción del usuario como parte del emparejamiento (por ejemplo, Comparación Numérica).
REMOTE-BTADDhciconfig y toma nota de tu índice hci, p.ej., 0sudo btmgmt -i 0[hci0] #Aquí asumo que la víctima está usando una dirección BLE pública. Si usa una
dirección aleatoria, cambia la opción -t a 2
Desde la CLI de btmgmt ejecuta:
pair -t 1 REMOTE-BTADD
Si también necesitas degradar la asociación a Just Works ejecuta:
pair -c 3 -t 1 REMOTE-BTADD
El flag -c establece las capacidades de entrada/salida del atacante y un valor de
0x3 corresponde a NoInputNoOutput, mientras que el valor predeterminado para un portátil/teléfono inteligente
es 0x1 que corresponde a Display Yes/No.
En este caso, incluso si suplantamos un periférico BLE, nos emparejamos sobre BT como el Central.
Desde la CLI de btmgmt ejecuta:
pair -t 0 REMOTE-BTADD
Si también necesitas degradar la asociación a Just Works ejecuta:
pair -c 3 -t 0 REMOTE-BTADD
Repite los ataques descritos anteriormente mientras suplantas un dispositivo que actualmente es desconocido (es decir, no emparejado) para la víctima.
Desde la CLI de bluetoothctl puedes configurar
discoverable a on o off y pairable. Desde la CLI de btmgmt también puedes
establecer el flag connectable.
Desde bluetoothctl,
puedes controlar el tiempo de espera de descubribilidad usando discoverable-timeout,
por ejemplo, si lo estableces a 0 el dispositivo siempre es descubrible.
Para BT, al emparejar con un dispositivo remoto ya sea como Central o
Periférico, recibirás el siguiente paquete LMP: LMP not accepted ext (opcode: 0x02) con emparejamiento
no permitido (código de error: 0x18)
Para BLE, al emparejar con un dispositivo remoto ya sea como Central o
Periférico, recibirás el siguiente paquete SMP: SMP Pairing Failed Command
(opcode 0x05) con Pairing Not Supported (razón 0x05).
Para BT, al emparejar con un dispositivo remoto, busca el soporte de Secure Connections
para el Host y el Controlador en los paquetes de características LMP, por ejemplo, usando
el siguiente filtro de visualización de Wireshark: btbrlmp.efeat.scc or btbrlmp.efeat.sch.
Para BLE, al emparejar con un dispositivo remoto, en la Solicitud o
Respuesta de Emparejamiento SMP, verifica el byte AuthReq que contiene el flag de Secure Connection, por ejemplo,
usando el siguiente filtro de visualización de Wireshark: btsmp.sc_flag == 1.
Para BT, al emparejar con un dispositivo remoto, el tráfico SMP de BLE se canaliza
a través de L2CAP. Por lo tanto, usando el filtro de Wireshark btl2cap.payload deberías ver un
paquete desde el Central al Periférico que contiene un payload que comienza con
0x01 (Solicitud de Emparejamiento SMP) y otro paquete en la dirección opuesta con un
payload que comienza con 0x02 (Respuesta de Emparejamiento SMP). Luego también deberías ver
otros paquetes L2CAP sin procesar que codifican la fase de distribución de claves SMP.
Para BLE, al emparejar con un dispositivo remoto, en la Solicitud o
Respuesta de Emparejamiento SMP, verifica que tanto el Central como el Periférico estén dispuestos a enviar
y recibir una clave de enlace durante la distribución de claves SMP, por ejemplo, usa el siguiente filtro
de Wireshark btsmp.key_dist_linkkey or btsmp.key_dist_linkkey.