Récemment des informations importantes ont été publiées sur une nouvelle attaque appelée KNOB (Négociation clé de Bluetooth), qui permet à un attaquant d'organiser l'interception et la substitution d'informations dans le trafic Bluetooth crypté.
En ayant la possibilité de bloquer la transmission directe des paquets dans le processus de négociation de la connexion des appareils Bluetooth, l'attaquant peut réaliser l'utilisation de clés contenant seulement 1 octet d'entropie pour la session, qui vous permet d'utiliser la méthode de force brute pour déterminer la clé de chiffrement.
À propos de KNOB
Danièle Antonioli de SUTD, Dr. Nils Tippenhauer de CISPA et le professeur Kasper Rasmussen de l'Université d'Oxford découvert cette nouvelle vulnérabilité KNOB et il affecte les appareils Bluetooth BR / EDR, également connus sous le nom de Bluetooth Classic, en utilisant les versions de spécification 1.0 à 5.1.
Les chercheurs ont signalé la vulnérabilité aux membres de l'ICASI, Microsoft, Apple, Intel, Cisco et Amazon, qui a publié une divulgation coordonnée de la vulnérabilité.
Le problème (CVE-2019-9506) Il est causé par des failles dans la spécification Bluetooth BR / EDR Core 5.1 et les versions antérieures Ils permettent l'utilisation de clés de chiffrement trop courtes et n'empêchent pas un attaquant d'interférer avec l'étape de négociation de connexion pour revenir à ces clés non approuvées (les paquets peuvent être remplacés par un attaquant non authentifié).
Une attaque peut être menée lors de la négociation de la connexion d'un appareil (les sessions déjà établies ne peuvent pas être attaquées) et n'est efficace que pour les connexions en modes BR / EDR (Bluetooth Basic Speed / Enhanced Data Rate) si les deux appareils sont vulnérables
Si la clé est sélectionnée avec succès, l'attaquant peut déchiffrer les données transmises et effectuer silencieusement une substitution de texte chiffré arbitraire sur le trafic de la victime.
Comment fonctionne l'attaque?
Pour reproduire la vulnérabilité dans le laboratoire (l'activité de l'attaquant a été diffusée sur l'un des appareils), un prototype de boîte à outils a été proposé pour mener l'attaque.
Pour une attaque réelle, l'attaquant doit se trouver dans la zone de réception des appareils des victimes et avoir la capacité de bloquer brièvement le signal de chaque appareil, qu'il entend mettre en œuvre par la manipulation du signal ou des interférences réactives.
Exploiter cette vulnérabilité n'est pas une tâche facile, car il nécessite l'établissement de conditions spécifiques. Ceci comprend:
- Les deux appareils doivent être Bluetooth BR / EDR.
- Un attaquant doit être à portée des appareils lors de l'établissement d'une connexion.
- «Le dispositif attaquant devrait intercepter, manipuler et relayer les messages de négociation de longueur de clé entre les deux dispositifs tout en bloquant simultanément les transmissions des deux, le tout dans une fenêtre temporelle étroite.
- La clé de chiffrement devrait être raccourcie avec succès, puis forcée à déchiffrer la clé de déchiffrement.
- L'attaquant devra répéter cette attaque à chaque fois que les appareils sont couplés.
Lors de l'établissement d'une connexion entre deux contrôleurs Bluetooth A et B, contrôleur A, après authentification avec une clé de canal (clé de liaison), peut proposer d'utiliser 16 octets d'entropie pour la clé chiffrement, et le contrôleur B peut accepter cette valeur ou spécifier une valeur inférieure, lui-même, il n'est pas possible de générer une clé de la taille proposée.
En réponse, le contrôleur A peut accepter la réponse et activer le canal de communication crypté.
Étant donné que la taille de clé autorisée varie de 1 à 16 octets, le deuxième pilote acceptera cette valeur et enverra sa validation avec une indication d'une taille similaire.
L'organisation Bluetooth SIG responsable du développement des normes Bluetooth a publié une mise à jour de la spécification avec le numéro 11838, dans lequel les fabricants ont proposé des mesures pour bloquer la vulnérabilité (la taille minimale de la clé de chiffrement a été augmentée de 1 à 7).
Pour le noyau Linux, une solution a été proposée dans la pile du noyau qui permet de modifier la taille minimale d'une clé de chiffrement.