Risque de cybersécurité dans les dispositifs Bluetooth Low Energy (BLE)

Auteurs : Ramakrishnan Lakshminaryanan et Jasper Nota

Les appareils dotés d'une connexion Bluetooth Low Energy (BLE) sont aujourd'hui monnaie courante. Cependant, leur utilisation peut s'avérer dangereuse. C'est le cas lorsque BLE est mis en œuvre de manière non sécurisée. Pour démontrer le risque de cybersécurité de ces appareils, nous avons choisi un dispositif médical qui peut être commandé par les consommateurs dans plusieurs boutiques en ligne bien connues.

Note : Avant de publier cet article, nous avons tenté à plusieurs reprises d'informer le fabricant d'équipement d'origine (OEM) des vulnérabilités découvertes et des conséquences qui en découlent. Malheureusement, aucune réponse n'a été reçue de la part de l'équipementier. Bureau Veritas Cybersecurity a choisi de publier cet article afin de sensibiliser les fabricants et les utilisateurs à la sécurité.

De nombreux problèmes de sécurité

De nombreux problèmes de sécurité ont été observés au cours de la brève enquête menée. Dans le cadre de cet article, seuls les risques liés à la fonctionnalité BLE seront dévoilés.

Le dispositif médical

L'appareil testé (DUT) est un appareil médical certifié qui permet aux utilisateurs de soulager la douleur, de détendre ou de renforcer les muscles à l'aide d'électrodes. Cet appareil peut être contrôlé à l'aide de l'application Android associée (v4.3.15 au moment de l'essai de cet appareil).

L'ensemble des fonctionnalités dépend de l'intensité réglée par le dispositif central ou périphérique. En fonction de la valeur de l'intensité [min = 0 ; max = 60], la vibration peut être ressentie sur le corps via les patchs d'électrodes. Selon la partie du corps sur laquelle les électrodes sont collées, il existe un ensemble de programmes d'entraînement, de relaxation et de récupération.

Les tests ont commencé en collant les patchs sur les bras ou les jambes. L'observation (lors du test sur le bras) était que lorsque la valeur de l'intensité dépassait 25, le bras subissait de violentes secousses. L'intensité contrôlait le mouvement du bras, ce qui rendait difficile la résistance à ce mouvement. Ces vibrations peuvent devenir des chocs graves à des intensités plus élevées ou lors de changements brusques d'intensité.

Services et caractéristiques

Une découverte BLE a été lancée pour identifier l'adresse MAC (Media Access Control) associée à l'objet sous test. Une fois identifiée, les services et les caractéristiques, qui sont des objets imbriqués responsables du traitement des données transmises, ont pu être énumérés :

Remarquez que plusieurs handles ont la propriété WRITE déclarée pour l'objet sous test. Cela signifie que ces handles acceptent les données entrantes de l'appareil central, qui est le téléphone portable dans ce cas.

Parmi les handles répertoriés avec un accès en écriture, il y en a plusieurs qui sont intéressants et qui sont énumérés ci-dessous :

(1) Poignée 0007 - Indicateur de confidentialité des périphériques

Cet indicateur est explicitement lié à la fonction de confidentialité du périphérique. En d'autres termes, c'est l'indicateur qui détermine si le périphérique prend en charge la confidentialité - activée ou désactivée. Tester si cette poignée peut être écrasée ou basculée serait l'une des choses les plus intéressantes pour un attaquant.

(2) Poignée 000b - Adresse de reconnexion

Cette poignée contient des informations relatives à l'adresse à utiliser lors de la reconnexion à un dispositif privé. Étant donné que cette poignée est également un point d'intérêt du point de vue d'un attaquant, nous voulions vérifier si elle pouvait être écrasée.

(3) Poignées 0010, 0011, 0012, 0013 - relatives aux intensités de vibration

Ces handles contiennent des valeurs d'intensité de vibration et seraient à nouveau des handles intéressants à écraser pour un attaquant.

Comme le montre la figure ci-dessus, l'indicateur de confidentialité périphérique [Handle 0007] a été écrasé. On peut donc en conclure qu'il est possible de le désactiver et de l'activer. De même, le champ "Adresse de reconnexion [Poignée 000b]" a également pu être écrasé, comme le montre la figure ci-dessous. Les figures relatives à l'écrasement des valeurs d'intensité des vibrations sont présentées dans la section suivante de cet article.

Il existe de nombreuses méthodes pour analyser le trafic BLE entre les appareils, en utilisant divers outils matériels et logiciels.

L'une des premières méthodes que nous avons envisagées consiste à capturer passivement le trafic BLE en utilisant l'Ubertooth One, puis à analyser les paquets à l'aide de Wireshark. Vous trouverez ci-dessous une capture d'écran d'un paquet à l'aide de Wireshark. Les informations relatives à la valeur de l'intensité de la vibration, au type de protocole utilisé et aux informations sur les poignées peuvent être examinées :

Dans la capture d'écran ci-dessus, on peut voir que les paquets capturés utilisent le protocole ATT. ATT, également connu sous le nom de protocole Attribute, fait partie de la pile BLE, qui définit strictement la manière dont les données doivent être représentées dans la base de données d'un serveur BLE, ainsi que la manière dont les données peuvent être lues ou écrites.

Une autre approche pour analyser les communications BLE consiste à utiliser la technique d'espionnage HCI sur un téléphone mobile Android rooté. Fondamentalement, un appareil Android rooté est un appareil modifié qui permet à l'utilisateur d'avoir un accès de super-utilisateur. Le processus d'enracinement d'un appareil consiste pour l'utilisateur à briser un ensemble de limitations prédéfinies par le fabricant de l'appareil, afin d'obtenir un contrôle total sur le système d'exploitation. Il s'élève ainsi au rang d'administrateur. Une fois que le couplage/communication BLE est établi, les journaux de fouille peuvent être extraits de l'appareil rooté afin d'analyser les paquets capturés.

Les méthodes susmentionnées consistaient principalement à renifler passivement la communication BLE afin de recueillir des informations sur le processus d'appariement, le type de protocoles en place, l'adresse MAC de l'objet sous test, les différentes poignées, etc.

L'outil Bettercap, associé à un dongle Bluetooth, a été utilisé pour interagir activement avec les différents handles. Les résultats de cette approche sont présentés plus haut dans cet article.

Détournement de la communication

Maintenant que la communication entre le dispositif central et périphérique a été analysée, une tentative a été faite pour établir une position d'homme du milieu (Man-in-the-Middle, MiTM).

La capture d'écran ci-dessous montre comment une connexion BLE légitime entre l'appareil mobile et l'objet sous test a été détournée avec succès. Cela signifie que l'appareil central est désormais la machine de l'attaquant et non plus le téléphone portable :

Lorsque le détournement BLE est en cours, l'écran mobile et le panneau avant de l'appareil indiquent qu'un comportement non réglementé est en cours.

Indication 1 : l'appareil est allumé ; aucun programme d'entraînement n'est actif sur l'application Android. Normalement, si un utilisateur quitte le programme d'entraînement, l'appareil devrait s'éteindre après quelques secondes (comportement normal). Il est donc impossible que l'appareil soit en état de marche alors que l'application n'exécute aucun programme, à moins qu'il ne soit maintenu en état de marche par une connexion BLE active provenant d'un autre appareil central. Cela démontre que l'application Android ne contrôle plus l'appareil, mais que l'attaquant contrôle désormais l'appareil.

Indication 2 : l'objet sous test est allumé ; l'application Android tente de se reconnecter à l'objet sous test, mais échoue en affichant un message indiquant que l'utilisateur doit allumer l'objet sous test. Cependant, l'appareil est déjà allumé et l'attaquant exécute un programme d'entraînement actif.

Les indications ci-dessus montrent donc que l'attaquant établit une position MiTM.

Une fois la position MiTM établie, la communication entre le téléphone portable et l'objet sous test a pu être observée au format HEX.

Il a été observé que, pour la même valeur d'intensité de vibration, il y avait deux formats de données HEX dans les paquets BLE capturés :

1. Données de l'appareil périphérique vers l'appareil central -> Format de données 1 ou DF1.
2. Données de l'appareil central à l'appareil périphérique -> Format de données 2 ou DF2.

Prenons par exemple la valeur d'intensité vibratoire 31.
Pour la même valeur, deux formats de données différents ont été observés tout au long des essais.

Le DF1 pour la valeur 31 a été capturé comme indiqué ci-dessous :
LL Data : 06 1b 17 00 04 00 1b 12 00 4e 4f 54 49 46 59 20 73 74 72 65 6e 67 74 68 20 33 31 0d 0a

Le DF2 pour la valeur 31 a été capturé comme indiqué ci-dessous :
LL Données : 02 10 0c 00 04 00 52 55 00 3e 73 74 72 20 33 31 0d 0a
Données LL : 0a 0f 0b 00 04 00 1b 55 00 73 74 72 3d 33 31 0d 0a

Les deux formats indiquent que la force ou l'intensité des vibrations sur les électrodes doit être de 31.

Le taux de réussite a été plus élevé avec DF2, en essayant d'écraser le handle qui contient la valeur de l'intensité de la vibration. Cela est logique, car l'appareil de l'attaquant est le nouvel appareil central après avoir détourné la connexion BLE, et DF2 fonctionnerait donc dans ce cas. Toutefois, l'approche ci-dessus a donné lieu à des scénarios intéressants

1. Le fait d'être à une valeur d'intensité ou de force plus élevée et d'écraser la poignée 0x12 par une valeur plus faible a fonctionné, car il y a eu un changement notable dans l'intensité de la vibration, qui pouvait être ressentie sur la partie du corps où les patchs d'électrodes sont collés [main/jambe]. Cependant, elle est revenue à sa valeur initiale au bout d'un certain temps.
   
2. Le fait d'être à une valeur d'intensité ou de force inférieure et d'écraser la poignée 0x12 par une valeur supérieure a également fonctionné, mais cela n'a duré que très peu de temps avant de revenir à la valeur d'origine. C'était également le cas lorsque le delta/la différence entre la valeur d'origine et la valeur écrasée était faible.
3. Le fait d'être à une valeur d'intensité ou de force plus faible et d'écraser la poignée 0x12 par une valeur plus élevée avec un grand delta/différence par rapport à l'intensité d'origine n'a pas provoqué de différence visible de vibration sur le corps. Il est possible que cela soit dû à une valeur delta seuil définie dans l'objet sous test. Nous n'avons pas abordé cette partie de l'expérimentation, car le détournement de la communication BLE était notre objectif et notre champ d'application.

Les données HEX suivantes ont été envoyées à l'appareil :

Après l'écrasement de la poignée 0x12, le changement d'intensité de la vibration pouvait être ressenti sur la partie du corps à laquelle les électrodes étaient attachées. Cela démontre qu'un attaquant a un contrôle total sur l'intensité définie pour les électrodes.

Conclusion

Nous avons démontré comment un pirate pouvait abuser des communications BLE lorsque les fournisseurs mettent en œuvre BLE de manière non sécurisée, ce qui pourrait causer de graves préjudices aux utilisateurs finaux.

De nombreux autres appareils intelligents sur le marché ont encore une implémentation non sécurisée de Bluetooth Low Energy (BLE). Faites-vous partie de l'industrie des appareils intelligents basés sur BLE ? Nous vous conseillons vivement d'évaluer vos produits d'un point de vue fonctionnel et sécuritaire.