Une faille s’est glissée dans les versions 4.2 à 5.0 du protocole Bluetooth. Affectant un composant utilisé pour configurer les clés d’authentification, cette vulnérabilité écrase ces dernières, ou au mieux affaibli leur chiffrement, permettant à un attaquant de se connecter au terminal ciblé.
Encore une faille dans le protocole Bluetooth ! CVE-2020-15802 affecte le composant CTKD, pour Cross-Transport Key Derivation, du protocole. Entre les versions 4.2 et 5.0, ce composant permet de générer les clés de chiffres lors de l’appairage de deux appareils prenant en charge le Low Energy et le BR/EDR (Basic Rate/Enhanced Data Rate). On parle de Dual-mode : les appareils décident qui de BLE ou de BR/EDR ils préfèrent utiliser, sans avoir à s’appairer une seconde fois sachant que CTKD permet d’écraser les clés de chiffrement .
Ce qui, dans le cas de BLURtooth, permet une attaque de type man-in-the-middle, l’attaquant écrasant les autres clés d’authentification Bluetooth sur l’appareil ciblé et de s’y connecter. Et donc d’accéder à tout dossier et application qui seraient partagés par ce biais.
Clés écrasées
Le Bluetooth Special Interest Group précise néanmoins que “pour que cette attaque réussisse, un appareil attaquant doit être à portée d'un appareil Bluetooth vulnérable prenant en charge les transports BR/EDR et LE et CTKD entre les transports et permet l'appariement sur le transport BR / EDR ou LE soit avec aucune authentification (par exemple JustWorks) ou aucune restriction d'accès contrôlée par l'utilisateur sur la disponibilité de l'appairage”.
Si la norme 5.1 du protocole contient les options permettant d’empêcher l’exploitation de BLURtooth, ce n’est pas le cas des versions antérieures. Quant aux patchs, distribués par chacun des fabricants de terminaux, on ignore encore quand ils pourront être diffusés.
En attendant, le SIG recommande des tests de conformité supplémentaires pour garantir que l’écrasement d’une clé autorisée par une clé non légitime ou plus faible ne soit pas autorisé. Il conseille en outre de limiter les appairages aux seules interactions de l’utilisateur ainsi que la durée du Dual-mode lorsque l’utilisateur n’a pas explicitement appairé son terminal avec un autre appareil.