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

Sortez les brouilleurs 14
Accès libre
image dediée
Crédits : SolStock/iStock
Securité
Guénaël Pépin

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é.


chargement
Chargement des commentaires...