BLUFFS — vulnérabilités Bluetooth permettant une attaque MITM.

Daniele Antonioli, chercheur en sécurité Bluetooth ayant précédemment développé des techniques d'attaques BIAS, BLUR et KNOB, a découvert deux nouvelles vulnérabilités (CVE-2023-24023) dans le mécanisme de négociation des sessions Bluetooth, affectant toutes les implémentations Bluetooth supportant les modes de couplage sécurisé « Secure Connections » et « Secure Simple Pairing », conformes aux spécifications Bluetooth Core 4.2-5.4. Pour démontrer l'application pratique des vulnérabilités découvertes, 6 variantes d'attaques ont été élaborées, permettant de s'immiscer dans la connexion entre des dispositifs Bluetooth précédemment appairés. Le code mettant en œuvre les méthodes d'attaque et les outils pour vérifier la présence de vulnérabilités a été publié sur GitHub.

Les vulnérabilités ont été identifiées lors de l'analyse des mécanismes décrits dans la norme pour atteindre la secretessité directe (Forward and Future Secrecy), qui contrent la compromission des clés de session en cas de détermination d'une clé permanente (la compromission d'une clé permanente ne doit pas conduire à déchiffrer des sessions auparavant interceptées ou futures) et le réemploi des clés de session (la clé d'une session ne doit pas être applicable à une autre session). Les vulnérabilités trouvées permettent de contourner cette protection et de réutiliser une clé de session non fiable à travers différentes sessions. Ces vulnérabilités sont causées par des lacunes dans la norme de base, ne sont pas spécifiques à des piles Bluetooth particulières et se manifestent dans des puces de différents fabricants.

Les méthodes d'attaque proposées mettent en œuvre différentes variantes d'organisation du spoofing entre des connexions Bluetooth classiques (LSC, Legacy Secure Connections utilisant des primitifs cryptographiques obsolètes) et protégées (SC, Secure Connections utilisant ECDH et AES-CCM) entre le système et le périphérique, ainsi que l'organisation d'attaques MITM pour les connexions en modes LSC et SC. Il est supposé que toutes les implémentations Bluetooth conformes à la norme sont sujettes à l'une ou l'autre des variantes d'attaque BLUFFS. L'efficacité de la méthode a été démontrée sur 18 dispositifs de sociétés telles qu'Intel, Broadcom, Apple, Google, Microsoft, CSR, Logitech, Infineon, Bose, Dell et Xiaomi.

La nature des vulnérabilités réside dans la possibilité, sans enfreindre la norme, de forcer une connexion à revenir à l'ancien mode LSC et à une clé de session (SK) peu fiable, en indiquant lors de la négociation de connexion l'entropie minimale possible et en ignorant le contenu de la réponse contenant les paramètres d'authentification (CR), ce qui entraîne la génération d'une clé de session basée sur des paramètres d'entrée fixes (la clé de session SK est calculée comme un KDF à partir de la clé fixe (PK) et des paramètres convenus pendant la session). Par exemple, un attaquant lors d'une attaque MITM peut remplacer dans le processus de négociation de session les paramètres 𝐴𝐶 et 𝑆𝐷 par des valeurs nulles, et fixer l'entropie 𝑆𝐸 à 1, ce qui aboutira à la formation d'une clé de session 𝑆𝐾 avec une entropie effective de 1 octet (la taille minimale standard de l'entropie est de 7 octets (56 bits), ce qui est comparable au niveau de sécurité du cracking de clés DES).

Si l'attaquant parvient à obtenir l'utilisation d'une clé plus courte lors de la négociation de connexion, il peut ensuite, par brute force, déterminer la clé fixe (PK) utilisée pour le chiffrement et déchiffrer le trafic entre les appareils. Étant donné que lors d'une attaque MITM, il est possible d'initier l'utilisation de la même clé de chiffrement, une fois que cette clé est trouvée, elle peut être utilisée pour déchiffrer toutes les sessions passées et futures interceptées par l'attaquant.

Pour bloquer les vulnérabilités, un chercheur a proposé d'apporter des modifications à la norme, élargissant le protocole LMP et changeant la logique d'utilisation de la KDF (Key Derivation Function) lors de la création des clés en mode LSC. Le changement ne compromet pas la rétrocompatibilité, mais conduit à l'inclusion d'une commande LMP étendue et à la nécessité d'envoyer 48 octets supplémentaires. L'organisation Bluetooth SIG, responsable de l'élaboration des standards Bluetooth, a proposé, en guise de mesure de protection, de rejeter les connexions sur un canal de communication chiffré avec des clés de jusqu'à 7 octets. Les implémentations, qui appliquent toujours le niveau Security Mode 4 Level 4, sont invitées à rejeter les connexions avec des clés de jusqu'à 16 octets.

Source : opennet.ru