Il y a quelques jours, Des chercheurs de l'Ecole polytechnique fédérale de Lausanne libérés qu'ils ont identifié vulnérabilités dans les méthodes de matchmaking appareils conformes à la norme Bluetooth Classique (Bluetooth BR / EDR).
La vulnérabilité porte le nom de code BIAS et le problème permet à l'attaquant d'organiser la connexion de son faux appareil au lieu de l'appareil d'un utilisateur précédemment connecté et réussir la procédure d'authentification sans connaître la clé de canal (clé de lien) générée lors de l'appairage initial des dispositifs et autoriser sans répéter la procédure de confirmation manuelle sur chaque connexion.
L'essence de la méthode est que lorsque vous vous connectez aux appareils prenant en charge le mode Connexions sécurisées, le l'attaquant annonce l'absence de ce mode et revient à une méthode d'authentification obsolète (mode "hérité"). En mode "legacy", l'attaquant initie le changement de rôle maître-esclave, et présentant son appareil comme "maître", reprend la procédure d'authentification. Ensuite, l'attaquant envoie une notification sur la réussite de l'authentification, sans même avoir de clé de canal, et l'appareil s'authentifie auprès de l'autre côté.
L'attaque par usurpation d'identité Bluetooth (BIAS) peut être effectuée de deux manières différentes, selon la méthode de couplage simple sécurisé (connexions sécurisées héritées ou connexions sécurisées) précédemment utilisée pour établir une connexion entre deux appareils. Si la procédure de couplage a été effectuée à l'aide de la méthode Secure Connections, l'attaquant pourrait prétendre que c'est le périphérique distant précédemment couplé qui ne prend plus en charge les connexions sécurisées, ce qui réduit la sécurité d'authentification.
Après cela, l'attaquant peut réussir à utiliser une clé de chiffrement trop courte, contenant seulement 1 octet d'entropie et appliquer l'attaque KNOB développée auparavant par les mêmes chercheurs pour établir une connexion Bluetooth cryptée sous le couvert d'un appareil légitime (si l'appareil est protégé contre les attaques KNOB et que la taille de la clé ne peut pas être réduite, l'attaquant ne pourra pas établir un canal de communication crypté, mais continuera à être authentifié auprès de l'hôte).
Pour une exploitation réussie de vulnérabilité, l'appareil de l'attaquant doit être à portée de l'appareil Bluetooth vulnérable et de l'attaquant vous devez déterminer l'adresse du périphérique distant auquel la connexion a été établie précédemment.
Les chercheurs ont publié un prototype de boîte à outils mettant en œuvre la méthode d'attaque proposée et ont montré comment usurper la connexion d'un smartphone Pixel 2 précédemment couplé à l'aide d'un ordinateur portable Linux et d'une carte Bluetooth CYW920819.
La méthode BIAS peut être réalisée pour les raisons suivantes: l'établissement d'une connexion sécurisée Bluetooth n'est pas crypté et le choix de la méthode d'appairage de connexion sécurisée ne s'applique pas pour un appairage déjà établi, l'établissement d'une connexion sécurisée de Legacy Secure Connections ne ne nécessite pas d'authentification mutuelle, un appareil Bluetooth peut effectuer un changement de rôle à tout moment après la recherche en bande de base, et les appareils qui ont été couplés avec des connexions sécurisées peuvent utiliser les connexions sécurisées héritées tout en établissant une connexion sécurisée.
Le problème est causé par un défaut de mémoire et se manifeste dans plusieurs piles Bluetooth et le firmware des puces Bluetooth, y compris Intel, Broadcom, Cypress Semiconductor, Qualcomm, Apple et Samsung Jetons utilisés dans les smartphones, les ordinateurs portables, les ordinateurs monocarte et les périphériques de divers fabricants.
Les chercheurs ont testé 30 appareils (Apple iPhone / iPad / MacBook, Samsung Galaxy, LG, Motorola, Philips, Google Pixel / Nexus, Nokia, Lenovo ThinkPad, HP ProBook, Raspberry Pi 3B +, etc.), qui utilisent 28 puces différentes, et les fabricants avertis de la vulnérabilité en décembre dernier. Il n'est pas encore détaillé lequel des fabricants a publié des mises à jour de firmware avec la solution.
Compte tenu de cela, l'organisation Bluetooth SIG responsable du développement des normes Bluetooth a annoncé le développement d'une mise à jour de la spécification Bluetooth Core. La nouvelle édition définit clairement les cas dans lesquels un changement de rôle maître-esclave est autorisé, il y a une exigence obligatoire pour l'authentification mutuelle lors du retour au mode «hérité», et il est recommandé de vérifier le type de cryptage pour éviter une diminution de la connexion Niveau de protection.
source: https://www.kb.cert.org