Actualités

Bluetooth : mise à nue de 7 vulnérabilités permettant une attaque Man-in-the-Middle !

La connectivité continue d’être ardemment éprouvée :  dans le cadre de la 15ième édition 2021 du Woot (Workshop On Offensive Technologies), les chercheurs Tristan Claverie et José Lopes Esteves (ANSSI) ont mis en lumière, dans un rapport technique, 7 vulnérabilités. Celles-ci concernent les technologies Bluetooth Basic Rate/ Enhanced Data Rate (BR / EDR) et Bluetooth LE (Low Energy) et affectent de nombreuses spécifications ou protocoles…

 

 

Sont impactés :

  • Passkey : Simple Pairing – spécification Core : versions 2.1 à 5.2 incluses,
  • Secure connections pairing – spécification Core : versions 4.1 à 5.2 incluses et,
  • Low Energy, couplage de connexions sécurisées – spécification Core : versions 4.2 à 5.2 incluses.

 

“Les chercheurs ont identifié qu’il était possible pour un attaquant agissant en tant que MITM dans la procédure d’authentification par clé de passe d’utiliser une série de réponses spécialement conçues pour déterminer chaque bit de la clé de passe générée aléatoirement sélectionnée par l’initiateur du couplage à chaque tour de la procédure de couplage, et une fois identifié, pour utiliser ces bits de clé de passe au cours de la même session d’appariement pour terminer avec succès la procédure d’appariement authentifiée avec le répondeur“, indique un communiqué du Bluetooth SIG, le 24 Mai 2021. Suite malheureusement logique d’une attaque Man-in-the-Middle, une fois le cyber-attaquant intercalé dans la procédure d’authentification mais il lui faudra encore pouvoir s’approcher suffisamment près de deux terminaux Bluetooth pour parfaire l’exploit qui repose, donc, sur des vulnérabilités au sein des protocoles BR / EDR et LE du Bluetooth.

Voici le lot de vulnérabilités mises en relief par les chercheurs et dont le document technique, pour l’heure, n’est pas encore disponible (mise à disposition des informations – partagées – sur le site de l’Université de Carnegie Mellon) :

 

  • CVE-2020-26555 : spécification Core Bluetooth concernant les versions 1.0B à 5.2. Accès illégitime depuis le code PIN d’appareillage du protocole BR / EDR ;
  • CVE-2020-26556 : profil Mesh Bluetooth concernant les versions-profil 1.0 et 1.0.1. Attaque potentielle par brute-force depuis une faiblesse de la valeur AuthValue (pas assez de complexité, de randomisation) combiné à Malleable Commitment ;
  • CVE-2020-26557 : Mesh Provisionning affecté (au sein du profil Mesh Bluetooth : toujours concernant les versions-profil 1.1 et 1.0.1). Possibilité potentielle d’identifier la valeur AuthValue (cette fois, sans connaître cette donnée préalablement) et / ou d’effectuer une attaque par brute-force (sauf si randomisation suffisante) ;
  • CVE-2020-26558 : vulnérabilité affectant l’authentification par appareillage Bluetooth LE et Bluetooth BR / EDR (v2.1 à v5.2 incluses). Attaque MitM permettant d’identifier la clé d’accès (Passkey) durant la procédure d’authentification ;
  • CVE-2020-26559 : Mesh Provisionning (au sein du profil Mesh Bluetooth : v1.1 et v1.0.1). Un appareil proche (et inclus au sein du protocole de provisionnement, provisionning) peut identifier la valeur AuthValue, le numéro de confirmation et le nonce du Mesh Provisionning. Un individu malveillant peut potentiellement finaliser le processus de provisionnement sans avoir recours forcément à une attaque par brute-force ;
  • CVE-2020-26560 : Mesh Provisionning (au sein du profil Mesh Bluetooth : v1.1 et v1.0.1). Un appareil proche peut, pour finaliser l’authentification en tant que Provisioner, obtenir différentes clés (NetKey et AppKey) sans nécessairement deviner au préalable la valeur AuthValue ;
  • Non-assignée : Bluetooth Low-Energy, spécification Bluetooth Core pour les versions 4.0 à 5.2 incluses. Possibilité d’identifier ou deviner la randomisation sous le protocole-réseau BLE sans avoir besoin de la clé temporaire (Temporary Key – TK). L’exploit n’est, cependant, pas viable pour maintenir ou finaliser l’authentification du fait, principalement, que la TK ou la Short-Term Key (STK) n’est pas usurpée ou obtenue avec réussite, du moins, pendant la cyber-attaque potentielle. Le B-SIG estime que cette vulnérabilité n’est pas une menace même si l’exploit, lui, est bien potentiel et potentiellement ajustable sur le long terme.

 

Voici une liste de recommandation émanant du Bluetooth SIG et des chercheurs :

 

  • Maintenir son terminal à jour via les mises à jour systèmes dédiées ;
  • Bluetooth LE : malgré le caractère jugé non-dangereux de la dernière vulnérabilité (non-assignée), il est, toutefois, recommandé par le B-SIG l’intégration du LE Secure Connections pour les terminaux qui exploitent l’appareillage et le chiffrement sous le protocole-réseau ;
  • Concernant l’attaque MitM au sein de PassKey : ne pas accepter les doublons ou clones de clés publiques qui auraient été initialement présentées lors de session d’appareillage antérieure. Appliquer un état d’échec de connexion dans ce cas ;
  • Concernant l’attaque MitM au sein du code PIN : ne pas accepter de connexions entrantes ou sortantes depuis des terminaux distants qui exploiteraient un BD_ADDR identique ou présenté antérieurement (en local) ;
  • Concernant l’attaque MitM depuis Mesh Provisioning : les fournisseurs ne doivent pas fournir des numéros (randomisation + confirmation-identification) à un terminal distant qui auraient des numéros identiques à ceux présentés antérieurement (comme en haut : éviter les doublons numéraires ou doublons de données numéraires qui sont exploitables) ;
  • Concernant le Mesh en général : la valeur AuthValue doit être bien plus randomisée en exploitant l’ensemble des bits disponibles (ou dans les limites permises). La complexité est signe de sécurité. Pour le cas d’une valeur statique, il faudrait que le cyber-attaquant, alors, puisse être performant sur la durée, en terme de vitesse, pour trouver rapidement la valeur avant d’être rejeté du réseau-protocole ;
  • Concernant les Mesh Provisioners : pour les fournisseurs potentiellement impactés ou impactés fortement. Ne pas accepter, au sein du processus de provisionnement, une donnée randomisée et, surtout, des numéros de confirmation ou d’authentification antérieurement soumis (et venant d’un terminal distant). Enfin, pour les échanges de clés publiques, il est préconisé d’exploiter une technique hors bande (out-of-band) pour limiter les usurpations d’identité.

 

Le site universitaire regroupe, pour l’heure, 248 vendeurs-fournisseurs (dont : Intel, Android, Red Hat, Cisco, Amazon, ATandT, Broadcom, Dell, Fortinet, GNU, Hitachi, HP, HTC, Google, IBM, MediaTek, Microsoft, NetBSD, Netgear, Oracle, OpenSSL, Palo Alto Networks, Philips Electronics, Qualcomm, Roku, Pulse Secure, PowerDNS, Sony, Sonos, Ubuntu, ZTE, Xiaomi, Sophos, NEC Corp., Bluetooth SIG, Belkin Inc., Alpine Linux, Alcatel-Lucent) qui sont impactés ; ceux ayant le statut “non impactés” ne sont, soit pas concernés par le Bluetooth (et donc non-impactés) soit ont colmatés vraisemblablement les vulnérabilités sans pour autant communiquer officiellement sur la résolution. Pour les autres, en toute logique, les mises à jour – pensons à Android… – devraient arriver, théoriquement, assez vite… A veiller !

 

 

Sources :

 

  • WOOT 2021 (15ième édition), Tristant Claverie et José Lopes Esteves – 27 Mai 2021 – BlueMirror: Reflections on the Bluetooth Pairing and Provisioning Protocols (papier technique à venir… ?).



  • 100% J'apprécieVS
    0% Je n'apprécie pas
    Pas de commentaire

    Laisser un commentaire

    ;) :zzz: :youpi: :yes: :xmas: :wink: :whistle: :warning: :twisted: :sw: :sleep: :sg1: :schwarzy: :sarko: :sante: :rollol: :roll: :rip: :pt1cable: :popcorn: :pff: :patapai: :paf: :p :ouch: :oops: :o :non: :na: :mrgreen: :mdr: :macron: :love: :lol: :kissou: :kaola: :jesuisdehors: :jap: :ilovesos: :idea: :houra: :hello: :heink: :grumpy: :fume: :frenchy: :fouet: :fouet2: :first: :fessee: :evil: :dispute: :demon: :cryy: :cry: :cpignon: :cool: :cassepc: :capello: :calin: :bug: :boxe: :bounce: :bluesbro: :bisou: :babyyoda: :assassin: :arrow: :annif: :ange: :amen: :D :??: :?: :/ :-| :-x :-o :-P :-D :-? :-1: :+1: :) :( 8-O 8)

    Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

    Copyright © Association SOSOrdi.net 1998-2021 - v1.11.0