iBeacon, ça balise un max !

Magazine
Marque
MISC
Numéro
92
Mois de parution
juillet 2017
Domaines


Résumé
De nombreux protocoles sans fil tels iBeacon, Eddystone, ou encore Gimbal beacons sont souvent utilisés dans un but commercial et visent les possesseurs de smartphones ou tout autre appareil utilisant le Bluetooth Low Energy (BLE). Ces protocoles ont également pour objectifs de localiser les personnes et de proposer du contenu spécifique lié à un lieu. Cet article présente la technologie iBeacon, son fonctionnement et ses méthodes de communication, et pour finir, les attaques ciblant cette technologie sont détaillées.

Body


1. Introduction à iBeacon

La technologie iBeacon ou balise en français a été développée par Apple afin de permettre de localiser la position d'objets ou de personnes dans un espace restreint (magasin, musée, gare, etc.). La technologie permet d’envoyer des informations à un équipement (smartphone/tablette) dès lors qu’il entre dans le rayon d’action d’une balise (environ 20 mètres de portée). iBeacon est basé sur la technologie Bluetooth Low Energy (BLE) et plus particulièrement sur ses aspects liés aux « advertising » ou annonces. L’article n’ayant pas pour but de présenter la technologie BLE, nous recommandons aux lecteurs curieux de lire l’article « Bluetooth Low Energy for pentesters » paru dans le MISC n°88. Voici cependant quelques informations le concernant et nécessaires à la bonne compréhension du présent article.

Le BLE est un protocole d’échange de données inspiré du protocole  Bluetooth « classique ». On constate alors 3 normes Bluetooth :

- Bluetooth « classique » : l'équipement est compatible uniquement avec le Bluetooth traditionnel ;

- Bluetooth Smart Ready : permet de supporter à la fois le Bluetooth « classique » et le Bluetooth LE ;

- Bluetooth Smart : ne supporte que le Bluetooth Low Energy.

La technologie iBeacon se basant sur le protocole BLE, il est donc nécessaire de disposer d’un appareil compatible (Smart Ready ou Smart) pour pouvoir recevoir les informations d’une balise. Il est important de signaler que depuis plusieurs années, la majorité des Smartphones sont Smart Ready.

Le BLE dispose de deux méthodes principales de communication :

 - La première utilise des annonces (advertising) où le périphérique BLE envoie des paquets à tous les équipements alentour. Les récepteurs peuvent réagir en fonction des données reçues ou se connecter à l’équipement pour s’échanger d’autres données.

 - La seconde se déroule si les appareils sont connectés ensemble. Il est alors possible de lire les services proposés par l’appareil BLE, et pour ces différents services, lire les caractéristiques proposées (profils GATT). Chacune des caractéristiques fournit une valeur qui peut être lue, écrite ou les deux.

Les paquets envoyés lors d’une annonce ont une longueur pouvant aller jusqu’à 47 octets dont voici la composition :

 - 1 octet de préambule ;

 - 4 octets pour l’adresse d’accès ;

 - 2 à 39 octets de données utiles (PDU : Protocol Data Unit) ;

 - 3 octets pour le CRC.

La technologie iBeacon n’utilise que la partie liée aux annonces du BLE et transmet des paquets de données qui peuvent être captés par les appareils compatibles. Le format des paquets envoyés par les balises est le suivant :

iBeacon_figure_01

Fig. 1 : Format des paquets iBeacon.

Les 9 premiers octets sont utilisés comme préfixe iBeacon et sont définis dans la norme avec les informations suivantes :

iBeacon_figure_02

Fig. 2 : Norme iBeacon.

Les 21 octets suivants sont découpés en 4 parties :

 - un UUID : identifiant unique ;

 - un identifiant dit « Major » qui correspond à un sous-ensemble, comme par exemple un lieu précis tel un magasin ;

 - un identifiant dit « Minor » qui correspond à un endroit spécifique dans ce sous-ensemble, par exemple un rayon de ce magasin ;

 - le dernier octet est utilisé pour la force du signal dont les caractéristiques sont détaillées plus bas.

2. Les échanges réseau

La méthode de géolocalisation iBeacon permet de définir la proximité des appareils aux alentours. On distingue 4 notions de proximité :

 - immediate (0-1m) ;

 - near (1-3 m) ;

 - far (loin ou proche avec interférence) ;

 - unknown.

Par défaut, lorsqu’un appareil ayant son service Bluetooth activé se rapproche d’une balise, aucune action n’est effectuée. Pour qu’un traitement des données d’annonces soit réalisé, il est nécessaire de disposer d’une application installée et exécutée sur le smartphone/tablette ou autres appareils BLE qui doit intégrer dans son code une action à opérer lorsqu'une balise ayant un UUID et un identifiant majeur et mineur spécifique est détectée.

Prenons un exemple concret pour illustrer ces propos :

 1. Le magasin « FashionMisc » dans lequel vous souhaitez acheter des T-shirts met en place des balises                                                                                                                        iBeacon dans ses différents rayons.

 2. Les balises diffusent à intervalles réguliers des annonces avec un UUID (similaire pour l'ensemble des boutiques du magasin), un ID majeur (différent par boutique) et mineur (différent par rayon).

 3. Vous entrez dans le magasin et commencez à vous diriger vers le rayon « Mode pour geek » pour acheter les derniers modèles afin de pouvoir flamber lundi au bureau.

 4. Vous décidez d’ouvrir l’application mobile du magasin, car il vous semble qu'un modèle que vous aviez vu la veille n’est pas présent.

 5. L’application mobile dispose dans son code d'une routine permettant de détecter l'ensemble des balises disposées dans les différentes boutiques. Pour cela, soit elle intègre directement la valeur UUID, ID mineur et majeur en dur ou, pour une gestion plus efficace, récupère les informations sur un service web.

 6. Cette détection déclenche une condition dans le code de l’application et permet de vous faire bénéficier de 20% de remise dans le rayon ou vous êtes situé.

Ainsi, vous pouvez être géolocalisé dans les magasins ou lieux que vous visitez sans même le savoir, ceci permettant au service marketing de récolter différentes données comme le temps passé dans un rayon spécifique, le désintérêt pour certains produits du magasin et si l’application dispose des droits nécessaires, récupérer des informations spécifiques à votre smartphone.

3. Les balises

Après avoir introduit le fonctionnement des balises iBeacon, il est intéressant de présenter leur aspect physique.  Pour cela, de nombreux sites spécialisés ou sites d’e-commerces proposent à la vente des balises utilisant la technologie iBeacon et possédant des formes et couleurs différentes. En voici quelques exemples :

iBeacon_figure_03

Fig. 3 : Format des balises.

Les caractéristiques techniques peuvent différer en fonction du modèle et de la marque choisie (il existe par exemple plusieurs concurrents à la technologie d’Apple comme EddyStone chez Google ou encore Gimbal beacons pour Qualcomm).

De plus, il est souvent constaté que les fabricants mettent à disposition des SDK pour aider les développeurs à créer des applications permettant de répondre aux annonces de la balise puis gérer l’ensemble des statistiques récoltées via un service de type cloud.

Ainsi et pour pouvoir étudier la technologie, une balise a été achetée. Après réception du matériel, celle-ci a rapidement été démontée pour voir ce qui se cache dans ses entrailles :

iBeacon_figure_04

Fig. 4 : Accès hardware à une balise.

Le circuit et les composants utilisés sont assez basiques :

 - une puce NRF51822 [1] pour embarquer la technologie BLE ;

 - des résistances, bobines, condensateurs et une antenne ;

 - et une pile assez volumineuse permettant de garantir une durée de vie confortable.

Chose intéressante, les points de tests sont facilement accessibles et ont été renseignés sur le circuit électronique.

L’accès à la partie électronique et aux points de tests a permis de rapidement capturer la mémoire flash de la puce NRF51822. Pour y parvenir, le débogueur et programmateur ST-LINK/V2 a été utilisé et des broches ont été reliées aux points de tests disponibles. En utilisant l'outil OpenOCD [2] (interface SWD), il a ainsi été possible de récupérer l'ensemble des données de la flash :

iBeacon_figure_05

Fig. 5 : Capture de la Flash via OpenOCD.

La récupération du firmware permettrait son étude via ingénierie inverse, mais ne sera pas détaillée dans le présent article. Néanmoins, une trace de l'UUID a bien été retrouvée dans ce dump :

iBeacon_figure_06

Fig. 6 : Constat de la présence de l'UUID dans le firmware de la balise.

Ainsi, les différentes valeurs pourraient être modifiées en reflashant le firmware par exemple via Device Firmware Upgrade (DFU) [3] et la technologie Firmware Over The Air (FOTA).

Il apparaît néanmoins que les données comme l’UUID, l’ID majeur et mineur sont généralement modifiables légitimement via une application mobile proposée par les entreprises créatrices des balises, ceci permettant aux propriétaires de pouvoir définir un UUID spécifique qui sera identique à l'ensemble de la flotte de balises dans le cas d'installation de multiples balises dans un magasin par exemple.

Pour finir, certains modèles permettent de laisser le choix de la technologie utilisée. Par exemple, il est possible de placer la balise en mode iBeacon (Apple) ou de l'un de ses concurrents Eddystone qui permet de diffuser des URLs via les balises, on parle alors de la technologie « Web Physique ».

4. Écoute et émission d'annonces

Bien que l'ensemble des informations fournies précédemment permette une bonne compréhension théorique de la technologie iBeacon, un peu de pratique ne fait jamais de mal. Ainsi, nous détaillerons comment capturer non pas des Pokemons, mais des annonces envoyées par des balises et aussi de simuler le fonctionnement des balises pour la partie émission.

4.1 Capturer des annonces

Afin de pouvoir capturer des annonces iBeacon, plusieurs méthodes sont possibles dont voici quelques exemples :

- en utilisant un smartphone : de nombreuses applications ont été développées pour pouvoir capturer les annonces BLE des balises telles que Beacon Toy, nRF Connect, Locate Beacon, etc.

Ces applications permettent de récupérer via une écoute BLE, aussi bien l'UUID, les identifiants mineurs et majeurs et la valeur de proximité. Voici un exemple d'informations capturées en utilisant un smartphone Android et l'application Beacon Toy [5] :

iBeacon_figure_07

Fig. 7 : Capture iBeacon via l'application Beacon Toy.

- en utilisant un ordinateur : la réception de paquets diffusés peut être réalisée en utilisant la puce Bluetooth présente dans la plupart des ordinateurs portables ou via un dongle Bluetooth (ex : CSR 4.0). Ensuite, il est nécessaire d'utiliser un outil permettant de capturer les annonces tel Nordic nRF Sniffer ou encore hcitool/hcidump [6] :

$ sudo hcidump --raw

HCI sniffer - Bluetooth packet analyzer ver 2.5

device: hci0 snap_len: 1500 filter: 0xffffffffffffffff

> 04 3E 2A 02 01 00 01 52 XX 42 6E E8 F3 1E 02 01 06 1A FF 4C

  00 02 15 48 DE 49 80 XX XX XX XX XX XX XX 00 20 0C 9A 66 00

4.2 Simuler une balise

Après avoir indiqué comment récupérer les informations envoyées par les balises, il est aussi intéressant de pouvoir simuler leur fonctionnement en envoyant des annonces comportant à la fois un UUID, un ID majeur et mineur. Cette action peut également être réalisée depuis un smartphone ou ordinateur :

 - en utilisant un smartphone : outre l'écoute, l'application iBeacon Toy permet aussi de cloner les informations envoyées par une balise et ainsi se faire passer pour elle (le smartphone doit cependant être compatible pour l'utilisation de cette fonctionnalité) :

iBeacon_figure_08

Fig. 8 : Clonage d'une balise iBeacon.

D'autres applications mobiles permettent également de réaliser cette action (il est aussi possible d'en coder une soi-même).

- en utilisant un ordinateur : l'outil standard Linux hcitool permet de créer une annonce iBeacon (ici nous simulerons une balise avec un UUID défini à « DEADBEEF….DEADBE » :

$ sudo hcitool -i hci0 cmd 0x08 0x0008 1E 02 01 1A 1A FF 4C 00 02 15 DE AD BE EF DE AD BE EF DE AD BE EF DE AD BE 00 00 00 00 C8 00

Une troisième solution serait d'utiliser une balise dont l'UUID est modifiable légitimement ou via une modification du firmware.

5. Des exemples d'attaques possibles

Aucune mesure de sécurité n’a été embarquée dans les spécifications de iBeacon. Ainsi, plusieurs scénarios d’attaques basés sur l’usurpation d’une balise sont possibles dont quelques pistes techniques sont détaillées ci-dessous.

 - Envoi de fausses données dans le Cloud :

Les applications qui disposent d’un code déclenché lorsqu'une balise spécifique est détectée peuvent être facilement trompées en utilisant des annonces avec les données propres à la balise (UUID, ID majeur et mineur) depuis un équipement tiers. Ainsi, il est possible de faire croire à l’application que l’utilisateur se situe bien dans le lieu où se situe la balise, car l'application « pense » recevoir les informations d’annonces légitimes. Les statistiques réalisées pourraient être ainsi totalement faussées.

 - Profit commercial :

Imaginons un scénario ou une personne étant à un endroit et un horaire bien précis se verrait proposer des réductions ou diverses offres promotionnelles. Sachant qu’il est possible d’envoyer des annonces similaires à celles diffusées dans un magasin par exemple, l’utilisateur malveillant pourrait accéder à ces offres et cela depuis son domicile.

C’est exactement ce qui s’est produit au CES 2015. Le jeu-concours était le suivant : le CES avait disséminé des capteurs iBeacon sur le salon, et lorsqu’ils étaient détectés par un smartphone ayant une application dédiée exécutée, cela permettait d’ajouter des chances de remporter un cadeau. Ainsi, les balises disposaient des mêmes valeurs pour l'UUID et l'ID majeur et de différentes valeurs d'ID mineurs (une par balise).

De ce fait, il était trivial de reverser l'application mobile afin d'identifier les valeurs des balises et ainsi simuler leurs caractéristiques et cela sans même avoir à se déplacer de son canapé.

 - SPAM :

Sachant qu'il est aisé de simuler une balise, un attaquant pourrait utiliser un équipement portable simulant de nombreux UUID afin de faire afficher des alertes à de nombreux utilisateurs dans un rayon proche (nécessite    que ces derniers ouvrent des applications spécifiques qui réagiront aux UUID annoncés).

 - Modification illégitime de l'UUID :

Les puces utilisées permettent souvent d’être mises à jour à travers BLE, on parle plus précisément  du mode DFU. Il est également possible de mettre à jour le firmware à travers la technologie Firmware Over The Air (FOTA). Cette fonctionnalité est présente dans de nombreuses puces BLE dont celle de notre cas d’étude (NRF51822). Ainsi, si le mode DFU n'est pas protégé ou facilement activable, un attaquant pourrait mettre à jour le firmware des balises afin d'altérer leur fonctionnement et pourquoi pas modifier les valeurs des annonces.

L'envoi d'un firmware modifié comportant des erreurs pourrait accessoirement aussi provoquer un déni de service de la balise...

- Capture du mot de passe d'administration :

Certains modèles de balises peuvent incorporer toutes sortes de puces permettant d’interagir plus facilement avec le matériel à distance. On pourrait imaginer l’ajout de puces dédiées aux protocoles LoRa, Sigfox ou même Wifi. L’utilisation de ces différents protocoles pourrait inclure de nouveaux vecteurs d’attaques dont par exemple la capture de trames de management de l’équipement ou de l’envoi de données sensibles.

- Tracking :

Bien que la portée ne soit pas très importante, une balise pourrait potentiellement être dissimulée dans une voiture, dans un sac, ou un autre endroit afin de pouvoir suivre à distance une personne ou un bien. On peut noter par exemple certains projets qui proposent l’ajout d’une balise sur des modèles de vélos afin d’indiquer au propriétaire étant physiquement à quelques mètres de celui-ci, si un déplacement du vélo est détecté, ce qui serait la conséquence d’un vol.

Conclusion

Les technologies permettant de géolocaliser les utilisateurs dans des lieux précis sont très utiles dans de nombreux domaines. Bien qu’elle soit simple à déployer, la technologie iBeacon ne dispose pas de sécurité visant à empêcher les attaques présentées dans l’article notamment le clonage d’une balise ou encore la possibilité de tromper les applications mobiles réagissant à la présence d’un UUID de balise spécifique. Certaines parades semblent cependant voir le jour telle la rotation de ces UUID, mais ne permettent pas de se prémunir contre l’ensemble des menaces. Aussi, des questions d’atteintes à la vie privée pourraient se poser lorsqu’une entreprise a la possibilité de surveiller certains faits et gestes d’individus à travers cette technologie. Pour conclure, il est important de noter que les conséquences d’une attaque sur des balises restent tout de même assez limitées actuellement, mais pourraient devenir préoccupantes en fonction des contextes d’utilisations.

Remerciements

Merci à Florent Poulain et Damien Cauquil pour l’aide sur certaines parties et à toute l’équipe Digital Security.

Références

[1] https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF51822

[2] http://openocd.org/

[3]   https://devzone.nordicsemi.com/documentation/nrf51/4.4.1/html/group__bootloader__dfu__description.html

[4] https://docs.mbed.com/docs/ble-intros/en/latest/Advanced/FOTA/

[5] https://play.google.com/store/apps/details?id=com.uriio




Articles qui pourraient vous intéresser...

CVE-2020-3153 : élever ses privilèges grâce au télétravail

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Cet article explique comment développer un exploit pour la CVE-2020-3153, une élévation de privilèges à l’aide d’un « path traversal » dans le client Cisco AnyConnect pour Windows (avant la version 4.8.02042). Après une brève présentation de ce produit et de son fonctionnement, nous étudierons cette vulnérabilité et verrons comment elle peut être exploitée.

Surveillance des accès de production en télétravail

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Il est courant de protéger l'accès aux infrastructures de production au travers de VPN ou de bastions SSH, et beaucoup d’organisations limitent encore ces points d'entrée à leur infrastructure interne. Lorsque l'organisation passe en mode télétravail à 100%, il faut forcément permettre l'accès depuis des adresses IP arbitraires, et se pose alors la question de surveiller ces accès pour détecter et bloquer rapidement une tentative d'accès malveillante.

Désamorcer des bombes logiques

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Aujourd’hui, les développeurs de code malveillant sont capables de contourner les mesures de sécurité et les techniques d’analyse les plus poussées grâce à de simples mécanismes appelés « bombes logiques ». Un exemple significatif est le Google Play qui accepte toujours des applications malveillantes pouvant déjouer ses barrières de sécurité. Cette introduction aux bombes logiques permet de sensibiliser sur les différentes solutions pouvant être mises en place pour détecter ces artifices.

Introduction au dossier : Télétravail : comment ne pas sacrifier la sécurité ?

Magazine
Marque
MISC
Numéro
111
Mois de parution
septembre 2020
Domaines
Résumé

Le dossier du précédent numéro traitait du concept de « Zero Trust ». Le numéro actuel est en quelque sorte une suite logique : nous passons d’un idéal où l’accès distant est possible « par design », à une réalité où il a fallu faire des choix fonctionnels et être conciliant avec la sécurité.

Assurez l’intégrité de vos fichiers avec fs-verity

Magazine
Marque
Linux Pratique
HS n°
Numéro
48
Mois de parution
septembre 2020
Domaines
Résumé

Vous êtes-vous déjà demandé comment faire pour protéger des fichiers importants ? Votre système d’exploitation vous a-t-il déjà informé que vos fichiers étaient corrompus ? Pensez-vous souvent à l’intégrité des informations contenues dans vos fichiers ? Vous êtes tombé au bon endroit, nous découvrirons ici comment protéger vos données avec fs-verity.