Sécurité IT : qui veut les clés du Bluetooth ?

Si vous n’utilisez pas le Bluetooth, coupez-le.

La société Armis Labs, à l’origine d’une plate-forme pour la sécurité de l’IoT, avait émis cette recommandation l’an dernier en parallèle d’un rapport sur plusieurs failles de sécurité touchant potentiellement des milliards d’appareils.

Sophos donne le même conseil en conclusion d’une analyse relative à une autre vulnérabilité, rendue publique ce 23 juillet 2018.

Le problème se trouve dans la gestion du chiffrement lors des procédures d’appairage. Il concerne aussi bien les appareils en eux-mêmes que leurs pilotes logiciels.

Le Bluetooth SIG (groupement d’intérêt qui définit les spécifications du Bluetooth) les a mises à jour pour l’occasion.

Objectif de la démarche : imposer une mesure qui n’était auparavant que recommandée. En l’occurrence, que tout appareil valide la clé publique qui lui est communiquée lors d’une procédure d’appairage.

La non-validation de ces clés ouvre la porte à des attaques qui pourraient permettre à des tiers d’intercepter et de manipuler des données (typiquement, une saisie au clavier).

Courbes lâches

Le Bluetooth SIG affirme n’avoir connaissance d’aucun appareil qui serait dans ce cas.

C’est plus problématique à l’échelon des pilotes, comme l’ont démontré deux chercheurs du Technion (Institut de technologie d’Israël).

Leurs découvertes sont synthétisées dans le descriptif de la vulnérabilité référencée CVE-2018-5383.

Le point sensible réside dans le mécanisme d’échange de clés effectué lors de l’appairage afin de protéger les communications.

L’algorithme Diffie-Hellman est exploité dans ce cadre, pour permettre, sans avoir besoin d’un canal sécurisé, l’établissement d’une clé privée partagée.

Cette procédure implique des courbes elliptiques sur les paramètres desquelles les deux appareils doivent s’accorder.

Plusieurs recherches ont démontré, par le passé, que ces paramètres n’étaient pas systématiquement validés avant d’être utilisés pour calculer la clé privée.

La présente étude va plus loin : certains pilotes n’effectuent tout simplement jamais de validation. Conséquence : un tiers a la possibilité d’introduire une clé publique invalide qui lui permettra « très probablement » de déterminer la clé privée.

La vulnérabilité a été rendue publique ce 23 juillet, plus de six mois après son enregistrement au CVE. Les principaux fournisseurs de puces ont eu le temps de rectifier le tir (officiellement corrigé le 6 février chez Qualcomm, le 19 juin chez Broadcom… et le 23 juillet chez Intel). Même chose pour les éditeurs, avec un doute sur l’écosystème Android : les utilisateurs devront s’assurer que les constructeurs aient bien repris les patchs intégrés au code source.

Crédit photo : adafruit via VisualHunt / CC BY-NC-SA