Attaque d'un bracelet sportif

1. Attaquer un bracelet sportif, mais quel intérêt ?!

Il faut le reconnaître : un attaquant est rarement intéressé par votre performance sportive, vos parcours préférés ou la qualité de votre sommeil. Sauf si vous êtes un VIP, comme Barack Obama [1], car alors votre vie privée peut avoir d'autres répercussions ou une personne de votre entourage vous en veut personnellement..

Mais, même s'il appartient à l'individu lambda, ce n'est pas pour autant qu'un bracelet connecté est dénué d'intérêt pour un attaquant. Il y a d'autres enjeux que l'on n'imagine pas forcément au premier abord… comme l'obtention de prix non mérités. En effet, que ce soit pour motiver les utilisateurs à se servir de leur bracelet ou pour cibler des consommateurs sportifs, les utilisateurs ont la possibilité de participer à des défis ou concours. Typiquement, s'ils effectuent 20000 pas en un jour, ils peuvent afficher un trophée virtuel sur leur profil, ou obtenir des réductions à l'achat de chaussures de marche (ex. : Higi). Certes, ce n'est pas encore vraiment alléchant pour un attaquant, mais il y a mieux : d'autres programmes d'affiliation offrent carrément de l'argent au bout d'un certain moment (voir par exemple Achievemint). Enfin, il existe quelques initiatives originales comme Pact où le possesseur du bracelet sportif parie sur ses performances. S'il atteint son objectif, il remporte sa mise plus un certain bonus. Au contraire, s'il échoue, il perd le montant de son pari, qui se trouve ainsi réparti auprès de tous les autres sportifs qui ont atteint leurs objectifs. Dès qu'il y a de l'argent en jeu, les cybercriminels se montrent tout de suite plus intéressés. En faussant des résultats sportifs, un attaquant peut récupérer de l'argent, dans le cas d'Achievemint, ou plus subtil, dans le cas de Pact, blanchir de l'argent. Ce dernier scénario est classique en cybercriminalité avec les sites de paris en ligne : des cybercriminels jouent ensemble. Celui qui dispose d'argent « sale » fait exprès de perdre. Les autres récupèrent alors « honnêtement » l'argent qui se trouve ainsi blanchi…

Autre intérêt du bracelet sportif pour un cybercriminel : la propagation de virus. Dans ce cas-là, l'attaquant n'est pas intéressé par les données personnelles de l'utilisateur, mais veut juste se servir du bracelet connecté comme moyen de transport pour le virus. Par exemple, il injecte du code malveillant dans un bracelet situé à proximité, à l'insu de son propriétaire. Le propriétaire revient chez lui, synchronise les données de son bracelet avec son profil en ligne, et infecte son ordinateur avec ledit code malveillant. Ou pire : le propriétaire continue son jogging dans un parc ; ce faisant, il passe devant d'autres personnes qui sont en train de scanner des objets Bluetooth à proximité pour une raison ou une autre (appairage d'un nouvel appareil, synchronisation de leur propre bracelet, etc.). Il les infecte sans le savoir : son bracelet transmet le code malveillant, qui arrive ensuite sur les appareils des autres individus du parc. Imaginez qu'une telle attaque soit possible : les objets connectés étant de plus en plus répandus, cette méthode de propagation pourrait devenir très rapide et dangereuse. C'est ce scénario que j'ai choisi d’approfondir pour le bracelet connecté Fitbit Flex. D'autres scénarios sont parfaitement envisageables (infection des trames Bluetooth, man-in-the-middle, etc.).

Pourquoi le Fitbit Flex ? Parce qu'il est très répandu, peu onéreux, que Fitbit est sur le marché depuis plusieurs années, et enfin parce que c'est un bracelet assez simple : si, lui, qui possède peu d'espace mémoire peut être infecté, alors il y a de grandes chances que d’autres bracelets sportifs mieux dotés soient encore plus faciles à compromettre.

2. La sécurité du Fitbit Flex

Le bracelet Fitbit Flex n'a pas accès à Internet, il ne connaît que le protocole Bluetooth Low Energy qui est particulièrement adapté aux applications soucieuses de leur consommation d'énergie. Par conséquent, la synchronisation du bracelet avec les serveurs distants de Fitbit se fait par l'intermédiaire d'un ordinateur connecté à Internet d'une part, et d'un dongle USB d'autre part. Ce dongle USB est spécifique à Fitbit et permet d'envoyer au bracelet des commandes (propriétaires) au bracelet via Bluetooth Low Energy (BLE).

Précisément, une synchronisation du bracelet se décompose de la manière suivante :

1. Le dongle USB s'assure qu'il est dans un état « propre » : il coupe toutes les communications restantes et récupère des informations sur lui-même (sa version, son adresse MAC).

2. Le dongle USB diffuse des paquets pour découvrir la présence de bracelets Fitbit dans son entourage. Chaque bracelet présent répond par un paquet indiquant son adresse MAC et la puissance du signal qu'il reçoit.

3. L'utilisateur choisit le bracelet qu'il veut synchroniser. Le dongle USB établit alors une session avec le bracelet à l'adresse MAC correspondante.

4. Le dongle USB envoie un paquet spécifique pour demander au bracelet de fournir un « megadump », c’est-à-dire ses données de synchronisation. Le format de certaines trames est explicité dans [2] et [3].

5. Le bracelet reçoit la commande et dès qu'il est prêt, renvoie une réponse pour notifier qu'il va commencer à envoyer les données.

6. Viennent ensuite un ou généralement plusieurs paquets qui contiennent le « megadump ». Le format du « megadump » est propriétaire. L'en-tête d'un megadump est partiellement connu (par reverse engineering), mais le gros du bloc est apparemment chiffré et jusqu'ici son format ainsi que l'algorithme de chiffrement sont inconnus. Dans l'état actuel des choses, on ne peut donc pas lire les données envoyées. Chaque paquet de transmission du megadump fait 20 octets, sauf le dernier qui peut être plus petit.

7. Enfin, le bracelet avertit qu'il a envoyé tout le megadump. Il envoie un paquet de fin de transmission. Ce paquet comporte notamment la taille du megadump.

8. Sur l'ordinateur où se trouve le dongle, le megadump est encodé en base64, puis inclus dans des données XML qui sont postées via HTTP ou HTTPS au serveur de Fitbit. Il est important de noter que le dongle ne possède pas la clé pour chiffrer ou déchiffrer les données : il ne fait que relayer les informations entre le bracelet et le serveur.

9. Le serveur chez Fitbit déchiffre les données du megadump et met à jour le profil de l'utilisateur. Il prépare une réponse, qui s'appelle « megadump response », qui contient par exemple de nouvelles alarmes ou défis choisis par l'utilisateur (le bracelet peut servir de réveil : l'utilisateur configure une alarme pour l'heure souhaitée, et le bracelet vibrera à cette heure-là – il ne possède pas de sonnerie). La réponse est chiffrée, encodée en base64 et renvoyée au client.

10. Sur le poste de l'utilisateur, la réponse au megadump est transmise sans modification au dongle USB (encore une fois, les données restent chiffrées à cette étape). D'abord, le dongle avertit le bracelet qu'il va envoyer des données :

11. Le bracelet acquitte le message par un paquet contenant un numéro de séquence incrémenté à chaque transmission.

12. Puis la réponse au megadump est transmise au bracelet par paquets de 20 octets, et acquitté par le bracelet. Le dernier paquet de données est généralement plus petit, et signifie la fin de la transmission. Que se passe-t-il s'il a exactement 20 octets ? Je ne suis jamais tombée dans ce cas, mais ce serait intéressant à tester.

13. Le bracelet peut alors déchiffrer les données de son côté, et la communication est coupée.

3. Fuite mémoire

Fitbit n'est pas supporté sous Linux. Pour l'utiliser sous ce système d'exploitation, mais aussi explorer sa sécurité, j'ai écrit un script, open source, en Python, talk2flex.py [4], qui permet de parler directement au dongle et au bracelet Fitbit sans communiquer avec leurs serveurs.

Le dongle exporte curieusement non pas un point d'entrée USB, mais deux. L'un est apparemment dédié à la communication avec le dongle (récupérer sa version, initier une communication Bluetooth, etc.), tandis que l'autre sert à envoyer des commandes au bracelet lui-même (récupérer un megadump, echo, etc.). Le script Python envoie tout simplement des paquets à ces points d'entrée USB, en respectant le format des trames du protocole de Fitbit (ceci étant déduit par ingénierie reverse) :

• Les paquets pour le dongle débutent par un octet indiquant sa taille. Ensuite, un octet indique le type de commande (par exemple, 0x01 pour récupérer les informations du dongle). La suite dépend de la commande. La taille du paquet est variable, mais fait au maximum 32 octets.
• Les paquets pour le bracelet débutent tous par C0, puis pareil : un octet pour le type de commande, suivi d’octets dépendant de cette commande. Les paquets pour le bracelet sont tous de taille fixe de 20 octets, si bien que la fin du paquet est éventuellement complétée par des zéros, et le dernier octet est réservé pour indiquer la « vraie » taille du paquet (C0 + type de commande + contenu).

Ce faisant, j'ai identifié un bug dans les paquets de commandes pour le bracelet. Ce bug permet d'écrire des données de manière persistante dans certains paquets (débordement mémoire), puis de lire ces données dans d'autres paquets (fuite mémoire).

On écrit des données en fournissant plus de données que prévu à une commande. Par exemple, certaines commandes n'ont besoin d'aucune donnée supplémentaire : si on en fournit, il se trouve que ces données sont apparemment mémorisées. Comme il s'agit d'un bug, cette écriture ne fonctionne pas pour toutes les commandes, seulement certaines. Appelons cette technique « écriture-vulnérable ».

Pour lire, pareil, un bug fait que certains paquets de commandes reproduisent la zone qui est écrite. Il s'agit d'une fuite mémoire typique, on peut même trouver dans cette zone par exemple l'adresse MAC du bracelet qui « fuite ». Appelons cette technique « lecture-vulnérable ».

N. B. : Comme Fitbit a reconnu la vulnérabilité il y a plus d'un an, mais ne l'a toujours pas corrigée, je m'abstiens de citer exactement quelles commandes utiliser.

4. À quoi cela peut-il servir ?

Que se passe-t-il si les données écrites via « écriture-vulnérable » sont malveillantes ? Dans ce cas-là, les données se trouvent également dans les paquets « lecture-vulnérable ». Ces derniers « transportent » les octets malveillants, d'un point de vue terminologique, on peut considérer qu'ils sont « infectés ».

C'est un premier pas intéressant dans l'infection et la transmission de code malveillant (par exemple un virus) via Fitbit. C'est également à partir de là que sont parties bon nombre d'exagérations et de fausses citations dans la presse. Il y a ceux qui disent que les bracelets sont vérolés, ou ceux qui disent que la vulnérabilité ne marche pas ;) Comme souvent, la vérité est entre les deux.

La vulnérabilité qu'on a vue plus haut fonctionne, on ne peut pas le nier puisque la preuve est apportée, mais elle comporte plusieurs limitations :

1. Limite en taille. La portion de paquets dans laquelle on peut écrire est limitée à 17 octets. C'est petit. Pas question d'envisager de coder un botnet bien garni dans cet espace-là. Cependant, c'est suffisamment grand pour écrire un petit exploit (le petit code qui faisait crasher les processeurs Pentium en 1997 tenait sur 4 octets : F0 0F C7 C8), ou même un petit virus (certains anciens virus, comme le virus « Mini » sur DOS en 1991, tenaient sur 13 octets). Sur un système d'exploitation récent, c'est probablement un peu plus compliqué, mais la contrainte n'est pas forcément bloquante.

2. Limite d'exécution. Le code malveillant est transporté dans des paquets du Fitbit. Il ne peut pas « sauter » du dongle Fitbit à l'ordinateur comme ça. Il faut exploiter une vulnérabilité sur l'ordinateur, par exemple dans la gestion de l'USB, ou avoir un ordinateur préalablement infecté qui irait lire spécifiquement les paquets « lecture-vulnérable » pour traitement et exécution.

3. Limite sur la persistance. L'écriture dans la mémoire persiste à travers l'envoi de plusieurs paquets, y compris à travers l'établissement d'une nouvelle session Bluetooth avec le bracelet, mais elle ne persiste pas si le dongle est déconnecté (arraché) puis reconnecté sur l'ordinateur. Sachant que certains utilisateurs laisseront leur dongle en permanence sur leur ordinateur, ceci n'apparaît pas comme étant une limitation majeure.

4. Limite sur la destination. Il y a deux sortes de commandes : les commandes pour le dongle et les commandes pour le bracelet. Cependant, même les commandes « pour le bracelet » passent par le dongle qui y apporte un certain traitement. Dans l'état actuel des choses, le code malveillant est indubitablement transporté dans les paquets USB à destination du dongle, mais on ne le retrouve pas dans la majorité des paquets Bluetooth Low Energy entre le dongle et le bracelet. C’est-à-dire que si l'on prépare un paquet USB « à destination du bracelet » comportant des octets non prévus, le paquet arrive d'abord au dongle qui le traite, et – hélas ou heureusement suivant le point de vue – enlève ces octets dans de nombreux cas. Le paquet ainsi transformé est alors envoyé au bracelet via Bluetooth Low Energy.

L'écoute de trames BLE est plus complexe qu'il n'y paraît, mais il semblerait qu'actuellement les données ne soient transmises via BLE que pour la commande echo – ce qui est un peu sa raison d'être...

Donc, pour résumer, oui, actuellement on peut infecter le dongle USB de Fitbit, mais non, on ne peut pas ni infecter ni propager un virus sur ordinateur via cette vulnérabilité. Mais c'est un premier pas et cela permet de susciter l'intérêt des autres chercheurs (et de vous, lecteur ?) pour le domaine. Aucune des contraintes listées ci-dessus ne paraît vraiment impossible (franchement, résoudre le challenge SSTIC en 2 ou 3 jours seulement me paraît bien plus compliqué). Avec le temps, il y a fort à parier que chacune de ces limites soit levée ou simplifiée. C'est bien le problème de toute vulnérabilité d'ailleurs : en soi, il s'agit souvent juste d'un bug, mais son exploitation peut affecter la sécurité de l'appareil (ou d'autres éléments).

Conclusion

L'objectif de cet article est avant tout de promouvoir la recherche en sécurité sur les objets connectés. C'est passionnant, car les équipements sont tous très différents, donc la recherche est très variée. C'est bénéfique à leur sécurité (correction de failles), bien sûr, mais cela peut également déboucher sur de nouvelles idées : par exemple, on peut automatiquement verrouiller un ordinateur portable lorsqu'on s'en éloigne en mesurant la proximité du Fitbit Flex que l'on porte [5].

Un autre point important à comprendre c'est que tout objet connecté, même avec des données peu sensibles, peut devenir une cible intéressante pour un attaquant, notamment lorsqu'il en détourne son utilisation pour propager des virus.

Références

[1] http://www.geekwire.com/2016/smartwatch-president-barack-obama-wears/

[2] https://bitbucket.org/benallard/galileo

[3] https://hackinparis.com/data/slides/2015/axelle_aprville_hackinparis.pdf

[4] https://github.com/cryptax/fittools

[5] http://2015.hack.lu/archive/2015/fitbit-hacklu-slides.pdf