francozappa/blurBLURtooth : Exploitation de la dérivation de clés inter-transports dans Bluetooth Classic et Bluetooth Low Energy [CVE-2020-15802] [CVE-2022-20361]
Dépôt sur les attaques BLUR présentées à AsiaCCS'22 dans l'article intitulé : BLURtooth: Exploiting Cross-Transport Key Derivation in Bluetooth Classic and Bluetooth Low Energy.
Liens utiles : pdf, vidéo, diapositives, site web.
Entrée 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}
}
Les attaques BLUR ont été assignées CVE-2020-15802 et CVE-2022-20361.
Dans la suite de ce README, nous indiquons Bluetooth Classic (aka BR/EDR) comme BT, Bluetooth Low Energy comme BLE, et Cross-Transport Key Derivation comme CTKD. Nous supposons également que l'appareil attaquant et les victimes supportent BT, BLE et CTKD. Cela signifie que les appareils supportent Bluetooth 4.2+ et les connexions sécurisées BT/BLE.
Le moyen le plus simple d'effectuer les attaques est d'utiliser un seul appareil à la fois comme victime et comme appareil attaquant. Par exemple, nous recommandons d'utiliser un ordinateur portable Linux comme appareil victime/attaquant et tout autre appareil comme autre victime.
Nous utilisons une machine Linux exécutant bluez
et bluez tools. Nous
nous appuyons sur l'outil btmgmt et il peut être utile de parcourir son
code source. En
particulier, nous utilisons sa sous-commande pair qui, entre autres, permet d'envoyer des
demandes d'appairage arbitraires sur BT/BLE tout en déclarant des capacités d'entrée-sortie arbitraires.
Usage: pair [-c cap] [-t type] <remote address>
Si vous souhaitez reproduire le scénario d'attaque exact présenté dans notre article, vous devez faire un travail supplémentaire. Plus précisément, vous devez reproduire la configuration présentée dans l'attaque BIAS. Une fois votre configuration prête, vous devriez pouvoir utiliser la carte de développement comme contrôleur BT/BLE, et l'ordinateur portable Linux comme hôte. De plus, vous devriez pouvoir sniffer les paquets de la couche liaison de l'hôte (par exemple, le trafic LMP BT) et patcher dynamiquement le firmware de la carte de développement à l'exécution en utilisant internalblue.
Cette étape est facultative et nécessite de patcher votre propre noyau Linux.
Lors de l'utilisation de btmgmt -c 3, bluez désactive automatiquement le drapeau de protection MitM,
par exemple, il met l'octet AuthReq à 0x02 au lieu de 0x03.
Cependant, les attaques BLUR ne nécessitent pas de désactiver ce drapeau, mais seulement de déclarer
les capacités NoInputNoOutput lorsque l'appareil distant supporte des capacités d'entrée-sortie.
En faisant cette astuce, la procédure d'appairage est rétrogradée à Just Works sans désactiver le drapeau MitM.
La mise en œuvre de cette configuration nécessite une modification minime du noyau Linux. En
particulier, dans /net/bluetooth/hci_event.c, nous changeons :
cp.authentication = conn->auth_type;
en :
cp.authentication = 0x03;
Ce faisant, nous codons en dur notre drapeau AuthReq à 0x03 indépendamment des
capacités d'entrée-sortie que nous déclarons.
Appairez les appareils victimes comme d'habitude. Par exemple, si vous ciblez un smartphone, appariez-le avec votre ordinateur portable (agissant à la fois comme victime et appareil attaquant). Une certaine interaction utilisateur peut être nécessaire dans le cadre de l'appairage (par exemple, la comparaison numérique).
REMOTE-BTADDhciconfig et prenez note de votre index hci, par exemple 0sudo btmgmt -i 0[hci0] #Ici, je suppose que la victime utilise une adresse BLE publique. Si elle en utilise une
aléatoire, changez l'option -t en 2.
Depuis la CLI btmgmt, exécutez :
pair -t 1 REMOTE-BTADD
Si vous avez également besoin de rétrograder l'association à Just Works, exécutez :
pair -c 3 -t 1 REMOTE-BTADD
Le drapeau -c définit les capacités d'entrée-sortie de l'attaquant et une valeur de
0x3 correspond à NoInputNoOutput, tandis que la valeur par défaut pour un ordinateur portable/smartphone
est 0x1 correspondant à Display Yes/No.
Dans ce cas, même si nous usurpons un périphérique BLE, nous appairons sur BT en tant que Central.
Depuis la CLI btmgmt, exécutez :
pair -t 0 REMOTE-BTADD
Si vous avez également besoin de rétrograder l'association à Just Works, exécutez :
pair -c 3 -t 0 REMOTE-BTADD
Répétez les attaques décrites ci-dessus en usurpant un appareil qui est actuellement inconnu (c'est-à-dire non appairé) de la victime.
Depuis la CLI bluetoothctl, vous pouvez définir
discoverable sur on ou off et pairable. Depuis la CLI btmgmt, vous pouvez également
définir le drapeau connectable.
Depuis bluetoothctl,
vous pouvez contrôler le délai de découvrabilité en utilisant discoverable-timeout,
par exemple, si vous le réglez sur 0, l'appareil est toujours découvrable.
Pour BT, lors de l'appairage avec un appareil distant en tant que Central ou
Périphérique, vous recevrez le paquet LMP suivant : LMP not accepted ext (opcode : 0x02) avec appairage
non autorisé (code d'erreur : 0x18).
Pour BLE, lors de l'appairage avec un appareil distant en tant que Central ou
Périphérique, vous recevrez le paquet SMP suivant : SMP Pairing Failed Command
(opcode 0x05) avec Pairing Not Supported (raison 0x05).
Pour BT, lors de l'appairage avec un appareil distant, examinez la prise en charge des connexions sécurisées
pour l'hôte et le contrôleur dans les paquets de fonctionnalités LMP, par exemple en utilisant
le filtre d'affichage Wireshark suivant : btbrlmp.efeat.scc or btbrlmp.efeat.sch.
Pour BLE, lors de l'appairage avec un appareil distant, dans la demande ou la
réponse d'appairage SMP, vérifiez l'octet AuthReq contenant le drapeau Connexion sécurisée,
par exemple en utilisant le filtre d'affichage Wireshark suivant : btsmp.sc_flag == 1.
Pour BT, lors de l'appairage avec un appareil distant, le trafic SMP BLE est tunnelisé
sur L2CAP. Ainsi, en utilisant le filtre Wireshark btl2cap.payload, vous devriez voir un
paquet du Central vers le Périphérique contenant une charge utile commençant par
0x01 (demande d'appairage SMP) et un autre paquet dans l'autre sens avec une
charge utile commençant par 0x02 (réponse d'appairage SMP). Vous devriez ensuite voir
d'autres paquets L2CAP bruts encodant la phase de distribution des clés SMP.
Pour BLE, lors de l'appairage avec un appareil distant, dans la demande ou la
réponse d'appairage SMP, vérifiez que le Central et le Périphérique sont disposés à envoyer
et recevoir une clé de liaison pendant la distribution des clés SMP, par exemple en utilisant
le filtre Wireshark suivant : btsmp.key_dist_linkkey or btsmp.key_dist_linkkey.