Un défaut du Bluetooth Low Energy permet de prendre le contrôle d'un objet connecté

Un défaut du Bluetooth Low Energy permet de prendre le contrôle d’un objet connecté

Sortez les brouilleurs

Avatar de l'auteur
Guénaël Pépin

Publié dans

Internet

11/08/2018 9 minutes
14

Un défaut du Bluetooth Low Energy permet de prendre le contrôle d'un objet connecté

En brouillant une partie précise d'une connexion Bluetooth Low Energy, il est possible de se lier à un appareil déjà associé à un smartphone. Un attaquant peut empêcher l'accès à l'objet, voire interagir avec lui. Le protocole intègre bien des protections, mais elles seraient peu utilisées.

Comme le Bluetooth classique, le BLE permet de connecter deux appareils ensemble, à l'instar d'un smartphone et d'un objet connecté. Ce problème du Bluetooth Low Energy (BLE), variante basse consommation du protocole, pourrait ouvrir bien des possibilités. Il permet de prendre la main sur une connexion existante, sans que l'objet connecté ne s'en rende compte.

Damien Cauquil (Virtualabs), chercheur en sécurité chez Digital Security, a présenté sa découverte à la DEF CON, l'un des principaux événements mondiaux dédiés à la sécurité informatique. « Depuis des années, on peut analyser et intercepter des communications. Par contre, la prise de contrôle était considérée comme peu faisable » nous explique-t-il.

Il travaille depuis deux ans sur le protocole, qu'il rencontrerait souvent dans ses recherches. « Après avoir relu maintes et maintes fois la spécification technique, je suis tombé sur l'idée d'un scénario possible. Ce n'est pas trop difficile à exploiter. J'ai conçu un prototype, et un outil l'implémente désormais » détaille le spécialiste.

Les dernières branches du BLE (4.x et 5) semblent vulnérables, même si le prototype actuel n'existe que pour la version 4 actuellement. L'idée, née en janvier, a été concrétisée en mai dernier.

Tromper un objet connecté

Le principe de l'attaque repose sur les deux sens d'une connexion Bluetooth Low Energy, du smartphone vers l'objet et inversement. Il suffit de brouiller « de manière très précise » le lien dans un sens (depuis l'objet), pour faire croire au smartphone qu'il a perdu la connexion. Il se déconnecte donc après un temps d'inactivité (timeout de supervision).

Le smartphone, qui ne reçoit plus de données de l'objet pendant le brouillage, lance son minuteur avant déconnexion, mais continue d'envoyer des données pour tenter de récupérer le lien. Au bout d'un moment (jusqu'à 32 secondes), le terminal considère la connexion disparue. Par contre, l'objet pense toujours être connecté, ayant bien reçu des paquets valides pendant ce temps.

« On arrive donc à désynchroniser le smartphone de l'objet. C'est à partir de ce moment que l'objet, ne recevant plus d'information, va lancer son minuteur jusqu'à déclarer que la connexion est perdue. C'est un effet secondaire du fonctionnement de la connexion. Les créateurs de la norme ont essayé de limiter la consommation et faciliter les échanges, donc ils les ont énormément simplifiés » nous assure Cauquil.

C'est après la déconnexion du smartphone, et pendant le minuteur de l'objet avant déconnexion, que l'attaquant prend la main sur l'appareil. Il suffit de se faire passer pour le terminal maître pour maintenir la connexion déjà créée.

Quelle utilité ?

Le niveau de prise de contrôle dépendra de chaque objet. Il peut aller du simple déni de service (empêcher le smartphone de se connecter) à la prise de contrôle complète.

« Il y a une constante dans les objets utilisant du BLE : ils considèrent qu'ils sont soit connectés, soit en train de s'annoncer... À l'heure actuelle, la grande majorité de ces objets BLE n'acceptent qu'une seule connexion. Beaucoup de constructeurs se disent qu'une fois un appareil connecté à l'objet, ce dernier ne s'annonce plus. Il devient donc introuvable » détaille le chercheur.

L'intérêt d'une prise de contrôle, une fois une connexion créée, est que le smartphone et l'objet ont sûrement déjà mené une passe d'authentification, pour montrer patte blanche. Une fois cette vérification initiale menée, les objets connectés accepteraient généralement les commandes suivantes sans broncher, se pensant en sécurité.

Il est donc possible d'envoyer de mauvaises commandes ou de récupérer des données sensibles, par exemple pour des appareils médicaux. Damien Cauquil dispose de deux démonstrations : le déclenchement imprévu d'un sextoy et la prise de contrôle d'un drone connecté. Ce dernier, déconnecté, se poserait simplement. Ici, l'attaquant en prend le contrôle en vol et peut l'obliger à s'écraser au sol.

Le chercheur aurait aussi réussi à faire fuiter une partie de la mémoire d'un appareil, sans beaucoup plus de détails. Le sabotage est aussi envisageable, en provoquant des erreurs ou plantages en envoyant des données aléatoires (fuzzing). Un attaquant, via des données de gestion de connexion, pourrait aussi couper le chiffrement ou le renégocier à son avantage.

La plus grande difficulté serait d'adapter l'attaque à chaque objet. Il faudrait donc le qualifier, par exemple à partir des données transmises à la connexion (constructeur et modèle), pour concevoir et déclencher les bonnes actions.

Des contre-mesures déjà intégrées

Des garde-fous existent bien  dans le protocole. Malgré cela, « à partir du moment où on arrive à se synchroniser sur une connexion existante, par exemple en interceptant la connexion dès le début, on peut suivre la communication et réussir cette attaque. Peu importe la version du protocole ».

Une « connexion sécurisée » Bluetooth Low Energy peut protéger de l'injection de paquets par un tiers dans une connexion existante, en signant ces messages (via une « vérification de l'intégrité des messages »). Confronté à cette barrière, un attaquant ne pourrait plus contrôler ou voler des données de l'objet, même avec la technique de Cauquil. Par contre, il pourrait toujours maintenir sa connexion en envoyant des messages « vides », donc empêcher l'utilisateur légitime de se connecter.

« Malheureusement, ces mesures sont très peu utilisées. C'est contraignant pour l'utilisateur, donc la sécurité est intégrée directement au sein des applications plutôt que sur la couche de transport » explique Cauquil. Des développeurs préfèrent donc blinder la sécurité au niveau de leurs applications, en laissant la connexion sous-jacente plus vulnérable.

Dans ce cas comme dans le premier, l'attaquant ne pourrait pas manipuler l'objet, mais toujours empêcher l'utilisateur légitime d'y accéder. Ajouter la protection au niveau du protocole BLE ne serait pas compliqué, mais pourrait demander des validations supplémentaires de l'utilisateur sur Android ou iOS, ce que les constructeurs voudraient éviter.

Une attaque en trois minutes, mais avec des conditions

Selon Cauquil, l'attaque peut prendre moins de trois minutes. Il faut tout de même être proche de l'objet et qu'un smartphone soit déjà connecté. « Ça fait beaucoup de si », reconnaît-il. « Dans un environnement très rempli, au réseau très pollué, il est difficile de trouver une cible particulière. C'est le souci de l'attaque : quand on prend le contrôle, on ne sait pas forcément à quoi on a affaire. »

L'attaque ne permet pas des compromissions de masse, mais des attaques précises, comme toutes celles concernant le Bluetooth Low Energy et le monde physique, assure le chercheur. Les attaques sur ce protocole seraient encore rares, mais peuvent viser des objets spécifiques comme des serrures connectées.

15 euros de matériel et un smartphone

Pour son attaque, le chercheur utilise un BBC micro:bit, un minuscule ordinateur programmable, vendu environ 15 euros. Très personnalisable, il peut être trituré profondément, contrairement à la puce Bluetooth d'un appareil classique.

« Une attaque avec un smartphone seul n'est pas envisageable, on n'a pas le contrôle sur la puce BLE. Ça nécessite des programmes bien précis, qui manipulent le protocole radio. On travaille sur du bas niveau, donc l'implémentation a demandé pas mal de tâtonnements pour être efficace » détaille le spécialiste.

Le micro:bit est contrôlé par un PC, qui se contente de déclencher la recherche de cibles, la sélection de la victime et des actions à mener. Un smartphone connecté à un micro:bit (via port USB OTG) pourrait donc convenir.

La technique signalée aux concepteurs

Damien Cauquil assure avoir transmis la documentation de son attaque aux concepteurs du protocole (le Bluetooth SIG) début juillet, sans nouvelles deux semaines plus tard. Il n'a pas eu de retour du concepteur du sextoy (présenté comme sûr), alors que le constructeur du quadcopter visé est un partenaire de Digital Security.

« En soi, [cette technique] n'est pas vraiment problématique, dans le sens où la norme propose des contre-mesures » estime-t-il. La question est l'intégration encore limitée par les constructeurs d'objets connectés. « Ils se disent qu'il n'y a pas de danger. Et jusqu'à maintenant, personne ne pensait que c'était possible de prendre le contrôle d'une connexion BLE » justifie notre interlocuteur.

L'attaque ne serait pas à la portée de tous. Il faut bien connaître le protocole et ses subtilités, malgré le bas coût du matériel. Le chercheur tient à montrer que l'exploitation est possible, mais ne fournit pas d'élément pour interagir avec un objet en particulier.

« On fournira un outil démontrant que c'est possible, mais il reste une recherche à mener pour adapter ces attaques à différents types d'équipements. On ne livre pas un outil clé en main pour attaquants » assure notre interlocuteur. Il a d'ailleurs évité sciemment de créer un prototype pour le BLE 5.

« Dans le Bluetooth version 5, les concepteurs sont en train d'étendre la portée des communications. Ils visent quelques centaines de mètres [jusqu'à 400, NDLR]. Dans les prochaines années, on pourrait voir émerger des usages fondés sur le BLE. Si ce type d'attaque est encore possible, on n'est pas à l'abri de problèmes » anticipe le spécialiste.

Damien Cauquil est un expert de la bidouille d'objets connectés, les attaquant à bas niveau. Pour s'amuser, il avait piraté la Clé TV d'Orange, un ersatz de Chromecast aux fonctionnalités limitées. Pour la Nuit du hack en 2017, il montrait que la clé était en fait capable de bien plus, y compris de streaming de vidéos en 1080p de source imprévue. Orange a depuis publié le code source d'OCast, à la base de sa clé.

14

Écrit par Guénaël Pépin

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Tromper un objet connecté

Quelle utilité ?

Des contre-mesures déjà intégrées

Une attaque en trois minutes, mais avec des conditions

15 euros de matériel et un smartphone

La technique signalée aux concepteurs

Commentaires (14)


Effectivement c’est ennuyeux pour les sextoys …


Un déclenchement intempestif de sextoy, cela doit être juste chiant mais ce n’est pas aussi grave qu’une serrure connectée, surtout quand elle fait office de sextoy: Heureusement que ce n’était pas une ceinture de chasteté connectée.


Micro bit et sextoy. Encore une histoire de sexe <img data-src=" />


C’est pourtant simple de signer les messages pour authentifier l’émetteur… surtout si on ne gère qu’un seul interlocuteur… comme dit c’est aussi lié aux implémentation foireuse




Une « connexion sécurisée » Bluetooth Low Energy peut protéger de l’injection de paquets par un tiers dans une connexion existante, en signant ces messages (…)



« Malheureusement, ces mesures sont très peu utilisées. C’est contraignant pour l’utilisateur, donc la sécurité est intégrée directement au sein des applications plutôt que sur la couche de transport » explique Cauquil.





L’absence de sécurité au motif du “c’est contraignant pour l’utilisateur” est aussi justifiée que celle pour des raisons “budgétaires”. Et espérer que ce soit à l’applicatif de se sécuriser… C’est comme mettre des routeurs à la place de firewalls en disant “c’est l’appli qui va filtrer”.

En gros, c’est de la merde.


Juste une aparté pour signaler la mise en ligne de la nouvelle version de lite.qwant.

Pour le moment, le résultat de recherche que j’obtiens le plus est : internal server error :-)



C’est marrant de voir que l’histoire se répète. Pour chaque nouvelle technologie, les concepteurs sous-estiment toujours la faisabilité de l’exploiter surtout que le protocole intègre les signatures de paquets.








JCLB a écrit :



C’est pourtant simple de signer les messages pour authentifier l’émetteur





Le problème principal n’est peut-être pas tant la complexité que le surcoût en terme d’énergie que ça implique ; en BLE comme pour d’autres protocoles du même accabit (zwave, zigbee, etc…), le moindre milliwatt de conso est traqué car les périphériques peuvent être des mini-trucs qui fonctionnent avec des piles boutons et pensés pour durer des mois avec une seule charge.



Ce serait intéressant d’avoir une idée du surcoût énergétique que le chiffrement/déchiffrement engendrerait, car là se situe peut-être le noeud du problème.







SebGF a écrit :



L’absence de sécurité au motif du “c’est contraignant pour l’utilisateur” est aussi justifiée que celle pour des raisons “budgétaires”.





Pour (continuer à) me faire l’avocat du diable, est-ce le rôle du BLE de proposer du chiffrement ?



Je vois le BLE comme un protocole de niveau 2 (?) ; ça me paraît pas déconnant de penser que les problématiques de chiffrement devraient se situer aux niveaux supérieurs, non ? Sauf erreur de ma part, le chiffrement sur une pile IP est apparu à partir de la couche 3 en IPv6 ; on était encore au-dessus en IPv4.



Je pointais surtout la raison affichée dans l’article : “contraignant pour l’utilisateur”.





Ajouter la protection au niveau du protocole BLE ne serait pas compliqué, mais pourrait demander des validations supplémentaires de l’utilisateur sur Android ou iOS, ce que les constructeurs voudraient éviter.





Si l’argument avancé avait été la conso énergétique qui démolissait le ROI du Bluetooth LE, cela aurait été justifié.



La raison avancée ici ne me paraît pas justifiée pour se décharger de l’aspect sécurité.


Comme dit, finalement le problème est surtout du coté des concepteurs d’objets connectés qui ne font pas le boulot qu’au niveau du protocole lui-même. Après, au regard du nombre de failles qu’on peut trouver sur les objets connectés, l’attaquant aura probablement plus envie de poutrer via une faille spécifique à l’objet que via le protocole BLE au regard des conditions exposées dans l’article.

&nbsp;







StephaneGames a écrit :



Juste une aparté pour signaler la mise en ligne de la nouvelle version de lite.qwant.

Pour le moment, le résultat de recherche que j’obtiens le plus est : internal server error :-)



C’est ballot <img data-src=" />



“Il suffit de se faire passer pour le terminal maître”heu pardon? “y’a qu’a faut que” et c’est bon, c’est hacké ??








StephaneGames a écrit :



Juste une aparté pour signaler la mise en ligne de la nouvelle version de lite.qwant.

Pour le moment, le résultat de recherche que j’obtiens le plus est : internal server error :-)







Ca semble résolu (pas de souci chez moi), mais souvenez-vous du dicton de MEP : si ça marche du premier coup, c’est qu’on a raté un truc <img data-src=" />



Ouais, l’objet ne demande aucune preuve que c’est le terminal maître.

C’est grave :(


Bof, les objets BLE ne sont pas légion chez moi ou dans mon entourage. A part une souris, un clavier et un bracelet. Et c’est bien le contrôle de l’objet dont il est question, pas se faire passer pour lobjet. Donc peu d’impact.


Sauf si l’objet comporte une possibilité de mise à jour de son logiciel. Installer un enregistreur de frappes directement dans le clavier, c’est le top.