Actualités

BLESA : couac sécuritaire dans la procédure de reconnexion, exposant l’ensemble des terminaux sous Bluetooth !

Une fois de plus, la connectivité est mise à nue : les chercheurs universitaires de l’Université de Purdue ont pointé une vulnérabilité intéressante. Alors que lors de la dernière édition du Black Hat (américain), un exploit a été démontré au niveau de la procédure d’authentification, BLESA (Bluetooth Low Energy Spoofing Attack) se cible, plutôt, une attaque lors de la reconnexion du terminal…

 

 

Ces attaques permettent à un attaquant de se faire passer pour un appareil BLE et de fournir des données usurpées à un autre appareil précédemment apparié. BLESA peut être facilement exécuté contre certaines implémentations du protocole BLE, comme celle utilisée dans Linux. De plus, pour les implémentations de pile BLE utilisées par Android et iOS, nous avons trouvé un bug logique activant BLESA“, est-il confirmé dans un rapport détaillé.

 

En temps normal, la connexion avec le serveur et le Bluetooth LE, se fait usuellement en quatre étape voire cinq (communication client-serveur pour partage d’une clé chiffrée et maintenir la communication plus longtemps). Le PoC a ainsi voulu mettre en relief que la reconnexion sur un terminal précédemment jointé (initialement) à la connectivité intégrait, dans ce contexte, des vulnérabilités sécuritaires relative à l’authentification :

 

  • Celle-ci étant optionnelle, l’étape (chiffrée : clé secrète) peut être personnalisée ou contournée du fait que, par défaut, le niveau sécuritaire est peu exigeant, techniquement. Dès lors, le chiffrement peut s’avérer insuffisant via des attributs-requête pauvres ;

  • Toujours basé sur un niveau de sécurité basique (peu ou prou de chiffrement), la reconnexion bénéficiera d’un chiffrement si des erreurs ou des alertes se constituent (pour peu que cela soit détecté)  et c’est à ce moment qu’un détournement potentiel peut se produire, via une substitution du message d’alerte ou d’erreur par un renvoi d’authentification frauduleux (programme malveillant) qui validera la reconnexion. Le rapport note que Linux suit le schéma de l’authentification réactive ;

  • Même constat sous iOS et Android : l’authentification proactive fait aussi défaut. En temps normal, l’authentification et le chiffrement, qui vont de paire, s’établissent sur le partage de la clé-session secrète (précédemment usitée, lors de la connexion originelle en BLE). En cas d’échec de connexion, également, les deux éléments seront annulés (y compris, donc le chiffrement), ce qui pourrait profiter à un individu malveillant, dans le cadre d’un détournement ou une réévaluation de l’authentification.

 

Nous constatons que seulement 41 (32,3%) des 127 applications inspectées contiennent la procédure d’appariement, ce qui implique qu’une majorité des applications compagnons BLE étudiées (67,7%) n’implémentent pas l’authentification de la couche de liaison […] En analysant les paquets interceptés, nous constatons que 10 des 12 des paquets BLE inspectés (ndlr : cf. tableau ci-dessus) ne prennent en charge aucun cryptage / authentification de couche liaison. À cette fin, nous concluons que la plupart des appareils BLE du monde réel n’utilisent pas d’authentification de couche de liaison“, est-il souligné. La conclusion fait référence à quelques 33 785 applications mobiles (populaires) pris en panel de base afin de référencer celle qui possèdent une authentification jointée avec un chiffrement.

 

Étant donné que la reconnexion se poursuit sous iOS ou Android, alors même que la procédure de chiffrement et d’authentification est en échec, les deux systèmes sont concernés ; contrairement à Windows qui ne serait, selon le rapport, aucunement impacté. La faille, assignée CVE-2020-9770, a été signalée dès le 8 Avril 2019 à Apple et Google et a été comblée mais les chercheurs signale qu’en revenant tester la rustine sur les environnements concernés, ils ont constaté, en Mai dernier, que le smartphone Pixel XL (qui avait servi pour éprouver BLESA sous Android 8, à 10 inclus) était “toujours vulnérable“. De son côté, Apple a colmaté BLASE lors de la mise à jour d’iOS 13.4 et iPadOS 13.4, entre Mars et Mai 2020… A veiller !

 

 

Source : Université de Purdue (éducation) – BLASE : vulnérabilité Bluetooth Low Energy lors de la reconnexion sur un terminal précédemment reconnu.




  • 50% J'apprécieVS
    50% 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-2020