francozappa/blurBLURtooth: Explorando a Derivação de Chave entre Transportes no Bluetooth Clássico e Bluetooth Low Energy [CVE-2020-15802] [CVE-2022-20361]
Repositório sobre os ataques BLUR apresentados no AsiaCCS'22 no artigo intitulado: BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic e Bluetooth Low Energy
Links úteis: pdf, vídeo, slides, site.
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}
}
Os ataques BLUR foram atribuídos CVE-2020-15802 e CVE-2022-20361.
No restante do README, indicamos Bluetooth Classic (também conhecido como BR/EDR) como BT, Bluetooth Low Energy como BLE, e Cross-Transport Key Derivation como CTKD. Assumimos também que o dispositivo atacante e as vítimas suportam BT, BLE e CTKD. Isso significa que os dispositivos suportam Bluetooth 4.2+ e BT/BLE Secure Connections.
A maneira mais fácil de realizar os ataques é usar um dispositivo tanto como vítima quanto como dispositivo atacante. Por exemplo, recomendamos usar um laptop Linux como dispositivo vítima/atacante e qualquer outro dispositivo como a outra vítima.
Estamos usando uma máquina Linux executando bluez
e bluez tools. Contamos
com a ferramenta btmgmt e pode ser útil examinar seu
código-fonte. Em
particular, usamos seu subcomando pair, que, entre outros, permite enviar solicitações
de pareamento arbitrárias via BT/BLE enquanto declara capacidades de entrada-saída arbitrárias.
Usage: pair [-c cap] [-t type] <remote address>
Se quiser reproduzir o cenário de ataque exato apresentado em nosso artigo, você precisa fazer algum trabalho extra. Especificamente, você precisa reproduzir a configuração apresentada no BIAS attack. Uma vez que sua configuração esteja pronta, você deve ser capaz de usar a placa de desenvolvimento como seu Controlador BT/BLE, e o laptop Linux como um Host. Além disso, você deve ser capaz de capturar os pacotes da camada de enlace do Host (por exemplo, tráfego BT LMP) e corrigir dinamicamente o firmware da placa de desenvolvimento em tempo de execução usando internalblue.
Este passo é opcional e requer a correção do seu próprio kernel Linux.
Ao usar btmgmt -c 3, o bluez automaticamente desmarca o sinalizador de proteção MitM,
por exemplo, define o byte AuthReq como 0x02 em vez de 0x03.
No entanto, os ataques BLUR não exigem desmarcar este sinalizador, apenas exigem
declarar capacidades NoInputNoOutput quando o dispositivo remoto suporta
capacidades de entrada-saída. Ao fazer isso, o procedimento de pareamento é
rebaixado para Just Works sem desmarcar o sinalizador MitM.
Implementar esta configuração requer uma modificação mínima do kernel Linux. Em
particular, em /net/bluetooth/hci_event.c alteramos:
cp.authentication = conn->auth_type;
para:
cp.authentication = 0x03;
Ao fazer isso, codificamos permanentemente nosso sinalizador AuthReq como 0x03,
independentemente das capacidades de entrada-saída que declaramos.
Pareie os dispositivos vítimas como de costume. Por exemplo, se você está visando um smartphone, pareie-o com seu laptop (atuando tanto como vítima quanto como dispositivo atacante). Pode ser necessária alguma interação do usuário como parte do pareamento (por exemplo, Comparação Numérica).
REMOTE-BTADDhciconfig e anote seu índice hci, por exemplo, 0sudo btmgmt -i 0[hci0] #Aqui estou assumindo que a vítima está usando um endereço BLE público. Se estiver usando
um aleatório, mude a opção -t para 2
A partir da CLI do btmgmt, execute:
pair -t 1 REMOTE-BTADD
Se você também precisar rebaixar a associação para Just Works, execute:
pair -c 3 -t 1 REMOTE-BTADD
O sinalizador -c define as capacidades de entrada-saída do atacante e um valor de
0x3 mapeia para NoInputNoOutput, enquanto o valor padrão para um laptop/smartphone
é 0x1 mapeando para Display Yes/No.
Neste caso, mesmo que personifiquemos um periférico BLE, pareamos via BT como Central.
A partir da CLI do btmgmt, execute:
pair -t 0 REMOTE-BTADD
Se você também precisar rebaixar a associação para Just Works, execute:
pair -c 3 -t 0 REMOTE-BTADD
Repita os ataques descritos acima enquanto personifica um dispositivo que é atualmente desconhecido para (ou seja, não pareado com) a vítima.
A partir da CLI do bluetoothctl você pode definir
discoverable como on ou off e pairable. Da CLI do btmgmt você também pode
definir o sinalizador connectable.
A partir do bluetoothctl,
você pode controlar o tempo limite de descobribilidade usando discoverable-timeout,
por exemplo, se você defini-lo como 0, o dispositivo está sempre descobrível.
Para BT, ao parear com um dispositivo remoto como Central ou
Periférico, você receberá o seguinte pacote LMP: LMP not accepted ext (opcode: 0x02) com pareamento
não permitido (código de erro: 0x18)
Para BLE, ao parear com um dispositivo remoto como Central ou
Periférico, você receberá o seguinte pacote SMP: SMP Pairing Failed Command
(opcode 0x05) com Pairing Not Supported (motivo 0x05).
Para BT, ao parear com um dispositivo remoto, procure pelo suporte a Secure Connections
do Host e do Controlador nos pacotes de recursos LMP, por exemplo, usando
o seguinte filtro de exibição do Wireshark: btbrlmp.efeat.scc or btbrlmp.efeat.sch.
Para BLE, ao parear com um dispositivo remoto na Solicitação ou Resposta de
Pareamento SMP, verifique o byte AuthReq contendo o sinalizador Secure Connection, por exemplo,
usando o seguinte filtro de exibição do Wireshark: btsmp.sc_flag == 1.
Para BT, ao parear com um dispositivo remoto, o tráfego SMP BLE é encapsulado
via L2CAP. Portanto, usando o filtro Wireshark btl2cap.payload, você deve ver um
pacote do Central para o Periférico contendo um payload começando com
0x01 (Solicitação de Pareamento SMP) e outro pacote na direção oposta com um
payload começando com 0x02 (Resposta de Pareamento SMP). Em seguida, você também deve ver
outros pacotes L2CAP brutos codificando a fase de distribuição de chaves SMP.
Para BLE, ao parear com um dispositivo remoto na Solicitação ou Resposta de
Pareamento SMP, verifique se tanto o Central quanto o Periférico estão dispostos a enviar
e receber uma chave de link durante a distribuição de chaves SMP, por exemplo, use o seguinte filtro
Wireshark: btsmp.key_dist_linkkey or btsmp.key_dist_linkkey.