Attaque KNOB, permettant d'intercepter le trafic Bluetooth chiffré

Dévoilé informations sur l'attaque KNOB (Key Negotiation Of Bluetooth), permettant d'organiser l'interception et l'injection d'informations dans le trafic Bluetooth chiffré. En ayant la capacité de bloquer la transmission directe de paquets lors de la négociation de la connexion entre les appareils Bluetooth, l'attaquant peut amener à l'utilisation pour la session de clés ne contenant qu'un seul octet d'entropie, ce qui permet d'appliquer la méthode de force brute (brute-force) pour déterminer la clé de chiffrement.

Le problème est causé par des défauts (CVE-2019-9506) dans la spécification Bluetooth BR/EDR Core 5.1 et les versions antérieures, permettant l'utilisation de clés de chiffrement trop courtes et ne prévenant pas l'intervention de l'attaquant lors de la négociation de la connexion pour revenir à de telles clés peu fiables (il est possible d'injecter des paquets par un attaquant non authentifié). L'attaque peut être effectuée au moment de la négociation de la connexion entre les appareils (les sessions déjà établies ne peuvent pas être attaquées) et n'est efficace que pour les connexions dans les modes BR/EDR (Bluetooth Basic Rate/Enhanced Data Rate), si les deux appareils sont vulnérables. En cas de succès dans la découverte de la clé, l'attaquant peut déchiffrer les données transmises et, de manière imperceptible pour la victime, effectuer une substitution dans le trafic de n'importe quel texte chiffré.

Lors de l'établissement d'une connexion entre deux contrôleurs Bluetooth A et B, le contrôleur A, après authentification par la clé de liaison (link key), peut proposer d'utiliser pour la clé de chiffrement (encryption key) 16 octets d'entropie, et le contrôleur B peut accepter cette valeur ou indiquer une valeur inférieure s'il n'est pas en mesure de former une clé de la taille proposée. En réponse, le contrôleur A peut accepter la contre-offre et activer le canal de communication chiffré. À ce stade de la négociation des paramètres, le chiffrement n'est pas appliqué, permettant à l'attaquant d'intervenir dans l'échange de données entre les contrôleurs et de substituer un paquet avec la taille d'entropie proposée. Étant donné que la taille de clé autorisée varie de 1 à 16 octets, le deuxième contrôleur acceptera cette valeur et enverra sa confirmation avec une taille similaire.

Pour reproduire la vulnérabilité en laboratoire (l'activité de l'attaquant a été simulée sur l'un des appareils), un
prototype d'outil pour réaliser l'attaque a été proposé.
Pour une attaque réelle, l'attaquant doit se trouver dans la zone de réception des dispositifs cibles et être capable de bloquer temporairement le signal de chaque appareil, ce qui pourrait être réalisé par la manipulation du signal ou le brouillage réactif.

L'organisation Bluetooth SIG, responsable du développement des normes Bluetooth, a publié a corrigé la spécification sous le numéro 11838, dans laquelle des mesures pour bloquer la vulnérabilité ont été proposées aux fabricants (la taille minimale de la clé de chiffrement a été augmentée de 1 à 7). Le problème se manifeste dans tous les stacks Bluetooth conformes et les firmwares des puces Bluetooth, y compris les produits Intel, Broadcom, Lenovo, Apple, par Microsoft, Qualcomm, Linux, Android, Blackberry et Cisco (des 14 puces testées, toutes se sont révélées vulnérables). Dans le stack Bluetooth du noyau Linux, un correctif a été apporté permettant de modifier la taille minimale de la clé de chiffrement.

Source : opennet.ru