Sécurité des protocoles Bluetooth

Bluetooth

La sécurité des protocoles Bluetooth est la protection des périphériques et des données transmises selon les normes du standard Bluetooth.

Bluetooth est un standard de communication dont le but est d'établir des connexions rapidement et sans fil. Différentes normes composent ce standard, afin de donner aux constructeurs de périphériques les informations nécessaires au bon fonctionnement de Bluetooth. Certaines de ces normes définissent de quelle manière la sécurité doit être implémentée. Cela est vrai tant pour le périphérique en lui-même que pour les protocoles de communication à utiliser. Elles indiquent également comment les clefs permettant l'authentification et le maintien des connexions doivent être générées et stockées.

Malgré ces précautions, la nature même des réseaux créés grâce à Bluetooth rend possible plusieurs types de menaces. On peut en effet craindre que le réseau ne soit scanné pour en découvrir la topologie, ou encore que les données transitant sur les ondes ne soient interceptées. Il se pourrait également que quelqu'un tente d'empêcher un appareil de communiquer. Les menaces sur un réseau si volatile, fonctionnant qui plus est par ondes, sont donc très nombreuses., un nombre important d'attaques ont vu le jour depuis le début de l'utilisation de Bluetooth. Pour chaque catégorie de menaces, une faille dans les spécifications du standard Bluetooth a été trouvée. À l'aide d'outils adaptés, les pirates ont ainsi pu pénétrer des réseaux Bluetooth ou empêcher des périphériques de fonctionner normalement.

Néanmoins, quelques règles permettent de repérer relativement facilement des attaques en cours, et ainsi protéger son périphérique ou ses données. La détection d'une attaque peut alors déclencher une procédure de prévention afin que cette attaque en particulier ne puisse plus être reproduite sur le même périphérique. Des bonnes pratiques permettent à l'utilisateur de réduire également les risques d'attaque sur ses périphériques.

Il ne faut néanmoins pas se reposer sur ces contre-mesures, car les spécifications du Bluetooth évoluent sans cesse, et les pirates continuent de les analyser afin d'y trouver de nouvelles vulnérabilités.

Fondamentaux

Normes

Le but du Bluetooth est d'établir une connexion ad hoc ou peer-to-peer entre plusieurs appareils afin d'échanger des données dans un picoréseau, dans la bande de fréquence des 2,4 GHz.

Il existe plusieurs versions du Bluetooth :

• Bluetooth Basic Rate/Enhanced Data Rate (BR/EDR) : Établit une connexion sans fil continue sur des distances relativement courtes (10 m) ;
• Bluetooth à faible énergie (LE) Permet de courtes rafales de connexions radio, ce qui le rend idéal pour les applications Internet de type (IoT) qui ne nécessitent pas de connexion continue, mais demandent une longue durée de vie de la batterie ;

La mise en œuvre d’un système Bluetooth est spécifiée à partir des normes constituant l’architecture de base du protocole Bluetooth. Le cœur d’un système Bluetooth est divisé en deux parties : la couche contrôleur implémentant la partie matérielle et une couche hôte implémentant la partie logicielle.

Description de l'architecture d'un système bluetooth

La couche contrôleur est implémentée physiquement via un module RF radio qui permet d’envoyer et recevoir les signaux radio entre deux appareils. La couche liaison est définie dans les systèmes Bluetooth comme la couche assurant le transport des paquets entre les appareils d’un même picoréseau à travers plusieurs canaux :

• Basic channel : Canal pour la communication entre deux appareils ;
• Adapted channel : Canal pour la communication dans le picoréseau ;
• Inquiry scan : Canal pour l'acquisition des appareils bluetooth aux alentours ;
• Page scan Canal pour la connexion avec un nouvel appareil ;

Les paquets possèdent un champ header pour distinguer le picoréseau de l’appareil des autres picoréseaux. De plus, les paquets doivent avoir un champ LT_ADDR dans leur header qui spécifie quel transport logique ce paquet utilise. Plusieurs types de transports logiques sont définis via plusieurs protocoles:

• ACL (Asynchronous Connection Less) ;
• SCO (Synchronous Connection Oriented) ;
• ASB (Active Slave Broadcast) ;
• PSB (Parked Slave Broadcast) ;
• LC (Link Control protocol) ;
• LMP (Link Manager Protocol) ;
• LELL (Low-energy Link Layer) ;

La liste complète des protocoles Bluetooth est décrite dans cet article List_of_Bluetooth_protocols (en).

L'interface host-controller (HCI) fait la liaison entre la couche hôte et la couche contrôleur en assurant le transfert des événements et des paquets de données. Cette interface assure le transfert d’information pour que la couche hôte puisse découvrir, ajouter et gérer les appareils dans un picoréseau. Sur certains appareils Bluetooth les couches hôte et contrôleur sont implémentées sur le même microprocesseur, l’interface HCI existe mais devient obsolète.

Les paquets reçus par le HCI sont traités par le protocole L2CAP (Logical Link Control and Adaptation Protocol), dans le cas d’un appareil sans HCI les paquets sont directement envoyés par les liens ACL, PSB et ASB. Ce protocole assure le transports des paquets vers les couches supérieures, la segmentation et le ré-assemblage des paquets.

Attribute protocol (ATT) définit l’aspect clients/serveur du picoréseau pour assurer l'échange des données une fois la connexion établie.

Profils

Treize profils sont définis dans la version 1.1 des spécifications Bluetooth. Ces profils correspondent au comportement général des appareils afin de communiquer entre eux. Ils décrivent une base pour les différents types d'usages et définissent les protocoles à utiliser pour les futurs usages.

Profils	Acronyme
Generic Access Profile	GAP
Service Discovery Application Profile	SDAP
Cordless Telephony Profile	CDP
Intercom Profile	IP
Serial Port Profile	SPP
Headset Profile	HS Profile
Dial-up Networking Profile	DUN Profile
Fax Profile	FAX
LAN Access Profile	LAN
Generic Object Exchange Profile	GOEP
Object Push Profile	OPP
File Transfert Profile	FTP
Synchronisation Profile	SYNC

Depuis la version 2.0 du Bluetooth de nombreux profils ont été ajoutés, la liste complète des profils est décrite dans l'article ci-contre : List of Bluetooth profiles (en).

Format des paquets

Tous les paquets possèdent un header de 8 bit, suivi par une adresse de 32 bits qui correspond a un identifiant unique pour une connexion donnée, enfin une suite variable de bits avec un PDU (Protocol Data Unit) de 2 a 39 octets (en BLE 4.0 et 4.1) contenant la charge utile du message suivi d'un CRC (Cyclic redundancy check) de 24 bits.

Champ	Header	Access Address	Protocol Data Unit	CRC
Taille	8 bits	32 bits	2–39 octets	24 bits

Implémentation de la sécurité

Modes de sécurité

Les appareils Bluetooth sont implémentés selon le GAP (Generic Access Profile) correspondant à un ensemble d’exigences obligatoires que doivent respecter les appareils Bluetooth pour qu'ils puissent communiquer entre eux. Plusieurs niveaux de sécurité sont définis dans le GAP :

• Mode 1 :
  • Ce mode est non sécurisé pour toute opération
  • Aucune procédure d’initialisation sécurisée
  • Les appareils qui utilisent ce mode ne peuvent communiquer qu’avec les appareils de ce même mode.

• Mode 2
  • Fournit un niveau de sécurité au niveau application après établissement d'une liaison avec un autre appareil.
  • Il n’y a aucune procédure sécurisée avant l’établissement d’un canal de communication.
  • Niveau de sécurité implémenté au niveau du protocole minimal d’échange de donnée L2CAP.

• Mode 3
  • Fournit un niveau de sécurité avant l’établissement du canal de communication.
  • Chiffrement sécurisé au niveau de la liaison avec un autre équipement Bluetooth : LMP protocol.

Si un service ou un service connexe effectue une demande avec un mode de sécurité différent, le mode de sécurité le plus élevé est forcé afin de traiter la demande.

Gestions des clés

Gestion des clés dans les protocoles bluetooth

La gestion et l'utilisation des clés permet aux protocoles Bluetooth d'établir et de maintenir une connexion entre plusieurs appareils d'un même picoréseau.

Les clés de communication peuvent être des combinaisons de plusieurs types de clés, les Unit keys, les clés de combinaisons, les clés maîtres et les clés d’initialisation.

Plusieurs entités permettent d’assurer une communication sécurisée entre plusieurs équipements Bluetooth : une adresse publique unique de 48 bit (BD-ADDR - Bluetooth Device address) utilisée pour identifier quel appareil est en train d'envoyer les données, aucun autre appareil ne doit avoir cette adresse. Cette adresse est définie par l’IEEE (Institute of Electrical and Electronics Engineers).

Une clé secrète d'authentification de 128 bit, l’appareil qui génère aléatoirement cette clé.

Une seconde clé secrète pour le chiffrement des données, la longueur de cette clé dépend du niveau de sécurité de la transaction, cette longueur varie entre 8 et 128 bit. Un nombre aléatoire est généré à chaque transaction de données, l’appareil génère automatiquement ce nombre pour l'utiliser dans les différentes processus de chiffrement et d'authentification.

Clé de liaison

La clé de liaison est un nombre de 128 bit généré aléatoirement, elle est échangée entre plusieurs appareils Bluetooth pour effectuer toutes les transactions sécurisées. La clé est utilisée pour la routine d’authentification et c’est l’un des paramètres pour créer la clé de chiffrement.

C’est une clé semi-permanente, elle est stockée dans la mémoire vive de l’appareil et peut dont être réutilisée lorsque la session est terminée. La clé de liaison peut s'utiliser dans le processus d'authentification entre plusieurs appareils Bluetooth. La durée de vie de cette clé dépend uniquement de la durée de vie d’une session.

Clé d’initialisation

La clé d’initialisation est utilisée pendant l’initialisation d’une communication entre deux appareils Bluetooth quand aucune clé de liaison ou autre combinaison de clé n'existe. Durant l’étape d’initialisation le code PIN des deux appareils doit être saisi. La clé est le résultat de l'algorithme E22 avec le code PIN de l'appareil, l’adresse de l’autre appareil Bluetooth et un nombre 128 bit généré aléatoirement en entrée.

Clé Initialisation

Clé Unit

La clé Unit est générée grâce à l’algorithme E21 quand l’appareil opère pour la première fois avec un autre appareil. Après la création, la clé est stockée dans une mémoire non volatile, elle est rarement changée. Un appareil peut utiliser la Unit Key d’un autre appareil comme une clé de liaison entre les deux appareils. Durant la phase d’initialisation, l’application décide quel appareil fournit sa Unit Key en tant que clé de liaison. Si la mémoire d’un des appareils est pleine, il ne pourra pas se souvenir d’une clé supplémentaire sa clé de liaison sera donc utilisée.

Clé de combinaison

La clé de combinaison est construite à partir d’informations de deux appareils. Elle est créée durant la phase d’initialisation, les deux appareils génèrent leur clé en même temps. Les deux appareils utilisent l’algorithme E21 avec un nombre généré aléatoirement et leur BD_ADDR en entrée. Ils échangent ensuite leurs nombre aléatoire de manière sécurisée afin de calculer leur clé de combinaison.

Construction de la clé maître dans le protocole bluetooth

Clé Maître

La clé maître est une clé temporaire remplaçant l’actuelle clé de liaison. Elle est utilisée quand l'appareil maître veut transmettre des informations à plus d’un destinataire. L’appareil maître génère une clé maître avec l’algorithme E22 et 2 nombres aléatoires de 128 bit.

Appairage

L’appairage (ou pairing en anglais) permet l’association entre deux terminaux Bluetooth. Les clefs de liaison, permettant de sécuriser les canaux de communication entre les deux terminaux, sont créés lors de cette phase.

Deux méthodes sont proposées : le « Legacy pairing » et le « Secure simple pairing ».

Le Legacy pairing est utilisé uniquement si un des terminaux n’est pas compatible avec une version supérieure à 2.0. Il se base sur un code PIN à 4 chiffres. La clef de liaison est générée à partir du code PIN. Ce mode n’offre pas de protection contre les attaques de l’intercepteur.

Le Secure simple pairing est utilisé par les terminaux supportant une norme supérieure à 2.0. Il se base sur un secret partagé par l’algorithme Diffie-Hellman. La clef de liaison est générée à partir de ce secret partagé. Ce mode offre une protection contre les attaques de l’intercepteur et contre les écoutes passives.

Les différentes phases du Secure simple pairing, définies par la norme 5.0, sont :

1. Échange des paramétrages d’entrée/sortie
2. Échange d’un secret via l’algorithme Diffie-Hellman
3. Première phase d’authentification via la vérification du code PIN généré par les terminaux. Quatre modèles d’association peuvent être utilisés
   • Comparaison numérique : peut être utilisée si les deux terminaux peuvent afficher un code PIN. Ce dernier est généré et est affiché par les deux terminaux. L’association continue après confirmation manuelle que les codes PIN sont identiques sur les deux terminaux
   • « Just work » : peut être utilisé si un des deux terminaux ne peut pas afficher de code PIN. Celui-ci est généré et l’association continue après confirmation manuelle sans vérifier que les codes PIN sont identiques. Cette méthode ne permet pas de protéger la communication d’attaque de l’intercepteur
   • Passphrase : peut être utilisé si un des deux terminaux peut afficher des chiffres et si l'autre permet d'entrer des chiffres mais n’offre pas d’affichage. L’association continue si le code PIN entré dans le deuxième terminal est identique à celui du premier terminal
   • Out-of-Band : la découverte de terminaux et l'échange des données cryptographiques pour la création des clefs sont faits hors ligne, par exemple via NFC
4. Création des clefs de liaison à partir du secret partagé lors de l’étape 2.
5. Deuxième phase d’authentification via la vérification que les 2 terminaux partagent la même clef de liaison, décrite ci-dessous
6. Création de la clef de chiffrement si l’option est activée

Authentification

L'authentification bluetooth utilise une technique de question/réponse, un appareil vérifie si l'autre appareil connait la clé de liaison. Le programme procède ensuite à l'authentification avec la clé de liaison actuelle, le processus nécessite que les deux parties partagent la même clé de liaison.

Authentification Bluetooth

Pour l'étape d'authentification, le maître envoie un numéro aléatoire au demandeur. Ensuite, les deux parties utilisent la fonction d'authentification avec le numéro généré aléatoirement et la clé de liaison pour produire une réponse signée, enfin le maître vérifie que les deux réponses sont valides.

Si l'authentification échoue, une nouvelle tentative est initialisée après une courte période, cette période est doublée pour chaque tentatives supplémentaires sur la même adresse.

Chiffrement des données

Les données utilisateurs sont protégées par un chiffrement du paquet du payload. Le code d’accès et l'entête ne sont jamais chiffrés. Le chiffrement du payload est effectué par un algorithme de chiffrement E0 qui se resynchronise à chaque nouveau payload.

L'algorithme de chiffrement E0 est réalisé en trois blocs :

• Initialisation de la clé du payload
• Génération des keys stream
• Réalisation du chiffrement et déchiffrement

Chiffrement des données depuis un système bluetooth

Le bloc d'initialisation combine les bits entrants dans un ordre approprié et les décale dans les 4 LFSRs du bloc de génération des key stream. Plusieurs modes de chiffrements sont possibles si l'appareil utilise une clé semi-permanente ou la clé maître, dans le cas où l’appareil utilise une clé semi-permanente, la diffusion en broadcast n'est pas chiffrée car la clé est utilisée pour plus d'une session donc potentiellement moins sécurisée. Individuellement, le trafic peut être chiffré ou non. Dans le cas où la clé maître est utilisée, soit rien n'est chiffré, soit la diffusion en broadcast n'est pas chiffrée mais individuellement le trafic est chiffré avec la clé maître, soit tout le trafic est chiffré avec la clé maître.

Catégories de menaces

Le Bluetooth est devenu un des principaux standards de communication sans fil. Cependant, cette technologie de par sa nature ouverte présente de nombreuses menaces sur ses divers périphériques, notamment sur les téléphones portables.

Les menaces peuvent être classées selon les catégories suivantes :

Surveillance

Le but principal de la surveillance est d'observer et / ou de collecter des informations du réseau des périphériques Bluetooth comme leur position, les autres appareils avec lesquels ils communiquent ou toute donnée venant du réseau en lui-même. Les éléments récupérés servent à une prévision d'attaque ou une étude du réseau afin d'en connaître l'architecture ou les acteurs principaux.

Range extension

La Range Extension ou extension de portée n'est pas une menace directe en elle-même puisque son seul but est d'étendre la portée d'un signal Bluetooth. Elle est donc utilisée pour permettre à d'autres menaces d'être mise à l’œuvre depuis une position plus éloignée ou sur une plus grande échelle. En effet, la portée de Bluetooth étant limitée, 240 m pour la version 5, un attaquant souhaitera augmenter sa portée maximum pour réaliser son attaque ou se distancer de la source de l'attaque.

Obfuscation

L'obfuscation est une technique utilisée pour brouiller l’identité de l'attaquant en ajoutant des informations inutiles, corrompues ou chiffrées à l'information. L'utilité de brouiller son identité est de passer au travers la surveillance d'un réseau ou de communiquer sans que le message soit clairement lisible. Cette menace est d'autant plus faisable puisque quelle que soit la version de Bluetooth, il n'existe pas d'authentification par utilisateur sauf pour l'appareil en lui-même.

Fuzzer

Le Fuzzer consiste à envoyer des données non standard afin de recevoir une réponse différente ou non prévue du périphérique Bluetooth. Il peut être utile pour découvrir des bugs ou des failles de sécurité sur l'appareil. Le comportement voulu est de provoquer un Buffer Overflow, une Attaque par déni de service ou des injections SQL soit pour arrêter, rendre hors-service ou obtenir des informations grâce à la mauvaise réaction face à l'envoi d'une erreur.

Sniffing

Le Sniffing est l'action de capturer des informations du trafic Bluetooth entre deux appareils sans aucune interaction directe avec ceux-ci. Elle est utilisée pour identifier les acteurs de la communication, récupérer les données d'un échange ou se faire passer par un des deux communicants et essayer une attaque de l'homme du milieu. Une fois l'adresse du périphérique Bluetooth obtenue (la BD_ADDR) on peut l'associer à un utilisateur et suivre ses activités ce qui enfreint les principes de vie privée

DoS

L'Attaque par déni de service (Denial Of Service) consiste à saturer le trafic de données jusqu'à ce que le matériel refuse toute communication. Cette attaque peut être facilement réalisée et implémentée dans différents langages. Une interaction avec le périphérique et le programme réalisant le DoS suffit pour mettre en place ce type d'attaque.

Malware

Les menaces de type logiciel malveillant sont des attaques portées grâce à un logiciel dont le seul but est d'endommager ou d'extraire des informations d'un appareil. Le malware peut être par exemple un cheval de Troie qui s'introduit dans l'appareil Bluetooth voire les autres périphériques connectés pour les infecter.

Faiblesses connues

À travers son évolution, le protocole Bluetooth a connu de nombreuses vulnérabilités due à sa communication sans fil. Bien que certaines furent corrigées, il existe toujours dans les versions actuelles, des failles qui peuvent être exploitées.

Dans les versions antérieures à 2.1

Les failles suivantes ont été répertoriées depuis l'implémentation de la version 1.0 à 2.0 de Bluetooth

Catégorie de menace associée	Vulnérabilité	Description et exemple
Sniffing	La clé Unit est réutilisable et devient publique après usage	La clé Unit est utilisée de façon unique. Générer un ensemble de clés aléatoires avec celle-ci permet d'éviter une réutilisation malveillante.
Sniffing	La publication de la clé Unit peut provoquer de l'espionnage sur le trafic	Lorsque deux utilisateurs communiquent, la clé Unit est partagée et divulguée. Une personne malveillante peut donc compromettre la sécurité de la communication.

Dans les versions antérieures à 4.0

Ce tableau contient les vulnérabilités existantes dans les versions antérieures à 4.0 de Bluetooth

Catégorie de menace associée	Vulnérabilité	Description et exemple
Sniffing/Obfuscation	La gestion des PIN est inexistante	La bonne gestion des PIN dans la configuration d'une entreprise peut être difficile. Les problèmes d'extensibilité dans l'entreprise peuvent induire des problèmes de sécurité.
Sniffing	Les PIN de taille faible sont autorisées	Les PINs sont utilisées pour la génération des clés de chiffrement notamment, les utilisateurs ont tendance à choisir des PINs trop courte. Elles peuvent donc être facilement obtenues par une attaque par force brute. La clé Unit est utilisée de façon unique. Générer un ensemble de clés aléatoires avec celle-ci permet d'éviter une réutilisation malveillante.
Fuzzer	Le chiffrement de la séquence de clé se répète après 23.3 heures d'une connexion encore en vie	La séquence de clé dépend de la clé de liaison, du EN_RAND, de l'adresse du périphérique BD_ADDR et de la Clock. Si une connexion dure plus de 23.3 heures, la valeur de la clock sera la même que précédemment et générera par conséquent la même séquence de clé.

Depuis sa création jusqu'à la version actuelle

Ce tableau contient plusieurs vulnérabilités existantes depuis la création de Bluetooth et sa version 1.0 jusqu'à la version actuelle, qui restent non corrigées.

Catégorie de menace associée	Vulnérabilité	Description et exemple
Surveillance/Sniffing	Les clés de liaisons ne sont pas stockées de façon sécurisée	Les clés de liaisons peuvent être lues ou modifiées par un attaquant s'il n'y a pas de protection avec des codes d'accès.
DoS/Sniffing	Le nombre d'authentifications n'est pas limité directement	Bien qu'une temporisation exponentielle soit ajoutée entre chaque essai, aucune limite n'est fixée dans le nombre de requêtes.
Toutes (en Bruteforce)	La robustesse du générateur aléatoire pour l'authentification n'est pas connue	Le générateur de nombre pseudo aléatoire (GNR) peut produire des nombres statiques ou périodiques ce qui réduit l'efficacité de l'authentification lors du challenge réponse.
Fuzzer	La taille des clés de chiffrement peut être réduite	Les spécifications de Bluetooth autorisent des clés de un octet seulement, ce qui mène à une faille de sécurité.
Obfuscation	Authentification des utilisateurs inexistante	Bien qu'une authentification sur le périphérique existe. Il faut ajouter un niveau de sécurité applicatif avec une authentification par le développeur de l'application.
Sniffing	Compromission de la sécurité avec l'adresse du périphérique Bluetooth (BD_ADDR)	Lorsque l'adresse BD_ADDR est associée à un utilisateur, ses activités peuvent être journalisées et ainsi compromettre sa confidentialité.
DoS/Fuzzing	Les périphériques connectés sont cibles d'attaques	Tout périphérique fonctionnant en mode découverte du réseau ou mode connecté peut recevoir une attaque à n'importe quel moment, il est conseillé de l'activer peu de temps seulement.

Attaques

Exemples d'attaques

Bluejacking

Le Bluejacking (de l'anglais « Blue » de Bluetooth et « to jack », prendre en otage), est une attaque consistant à envoyer un message visible non désiré à un appareil mobile via la fonctionnalité vCard. Ce type d'attaque est inoffensif pour l'appareil cible car l'attaquant n'obtient a aucun moment le contrôle de celui-ci, toutefois le possesseur du terminal peut penser être victime d'une intrusion dans sa vie privée. Cette pratique est utilisée, entre autres, pour diffuser des publicités sur les appareils à portée d'un magasin.

Bluesnarfing

Le Bluesnarfing (de l'anglais « to snarf », manger consommer gloutonnement), est une attaque consistant à extraire des informations personnelles d'un terminal. Dans ces informations on peut retrouver des données facilement accessibles sur mobile notamment, telles que le calendrier, les images, les contacts ainsi que les SMS. Contrairement au Blue Jacking cette attaque ne se contente pas d'envoyer des informations inoffensives aux terminaux mais elle a pour but le vol des informations privées.

Une version avancée du BlueSnarf appelée BlueSnarf++ permet également d’accéder au système de fichier de l'appareil cible.

Bluebugging

Le Bluebugging (de l'anglais « bugging », l'action de placer un mouchard), est une attaque similaire au Blue Snarfing, où l'attaquant ne se content pas de voler des informations disponible sur le terminal attaqué, mais laisse derrière lui un mouchard capable d'envoyer des informations même lorsque le lien Bluetooth est rompu, permettant à l'attaquant de récupérer et d'écouter des appels passés depuis l'appareil attaqué.

Bluetracking

Le Bluetracking (de l'anglais « track », suivre), est une technique qui consiste à placer un appareil qui écoute et enregistre le passage de tous les autres appareils à sa portée. L'attaquant peut donc se construire une base de données contenant les adresses MAC de terminaux, leur position et la durée durant laquelle ils sont à portée. Cette pratique ne laisse pas de traces et peut servir pour de futures attaques puisque l'on peut déterminer l'emplacement d'un certain terminal s'il se rend régulièrement au même endroit sur une même plage horaire.

Bluesnipping

Le Bluesnipping est une technique utilisée pour améliorer grandement la portée d'un signal Bluetooth afin de porter une attaque depuis une distance éloignée.

Man-in-the-Middle Attack

L'attaque Man-in-the-Middle est une attaque où un intrus se connecte à deux terminaux et fait croire à ces terminaux qu'ils sont connectés directement l'un à l'autre, il contrôle pourtant le trafic et peut écouter ou modifier les échanges entre les deux terminaux.

Épuisement de batterie

Diverses attaques permettent de vider rapidement la batterie d'un appareil connecté en Bluetooth en provoquant une utilisation intensive et inutile du protocole. Parmi ces attaques on peut retrouver: Ping of Death Flood, BlueSpam Flood, Blueper Flood ou encore BlueSmack Flood. Les attaques Blueper Flood ou BlueSmack Flood peuvent être qualifiées de DDoS, mais lorsque la quantité de requêtes est contrôlée, le service continue de marcher normalement et consomme de la batterie.

Cabir

Cabir est le nom d'un ver informatique infectant les mobiles, développé pour infecter des terminaux tournant sous Symbian OS, il utilise la fonction "Object Push Profile" pour se propager via Bluetooth sur les autres terminaux à portée. Ce virus est inoffensif car il ne fait que se répliquer et affiche le message "Caribe" au démarrage du téléphone, il est pourtant une preuve de concept sur le développement de virus sur mobile pouvant se répandre entre les terminaux et reste le premier ver pouvant infecter les mobiles découverts.

Outils d'attaque

Pour mettre en place les différentes attaques citées ci-dessus, de nombreux outils ont vu le jour. En voici quelques exemples ainsi que l'utilisation qui peut en être faite.

BlueScanner

BlueScanner est un programme écrit en Bash qui permet de récupérer des informations sur les dispositifs Bluetooth alentours sans demander d'appariement.

Blooover

Trifinite a publié en décembre 2005 Blooover II, la seconde version de son logiciel d'attaques Bluetooth qui fonctionne sur téléphone. Cet outil permet notamment à un attaquant de se connecter aux systèmes d'oreillettes sans fil des voitures vulnérables et d'enregistrer les conversations en cours dans cette voiture.

Bluetooth Stack Smasher

Publié par SecuObs en 2006, BSS (Bluetooth Stack Smasher) est un outil qui permet de stresser le protocole L2CAP d'un dispositif Bluetooth afin d'obtenir des informations sur ce dernier, ou le rendre non-fonctionnel. Bien que le résultat le plus courant de ce genre d'attaques soit un simple arrêt de l'appareil, BSS représente néanmoins un pas en avant pour ceux qui souhaitent implémenter des logiciels plus robustes de détection de failles d'implémentation des protocoles Bluetooth.

BT-Crack

BT-Crack est un outil qui permet de reproduire d'implémenter l'attaque Cracking the Bluetooth PIN.

Kali Linux

La plateforme de tests d'intrusion Kali Linux 2.0

Kali Linux est la nouvelle version de Backtrack. Kali Linux est une plateforme permettant des tentatives d'intrusion qui tourne sur Debian et est disponible en Live CD. C'est à ce jour un des outils les plus puissants pour faire des tentatives d'intrusions. Il possède notamment des extensions comme Redfang qui permet de dévoiler les appareils Bluetooth non-visibles à proximité.

Avec l'arrivée de la version 4 et 5 de Bluetooth qui ont considérablement augmenté sa portée, le nombre d'outils a crû rapidement. L'intégration de Bluetooth aux appareils de l'internet des objets rend également les attaques plus intéressantes pour les pirates. C'est pourquoi cette liste n'est pas exhaustive et continuera de grandir à mesure que de nouveaux outils et méthodes de tests d'intrusions verront le jour.

Contre-mesures

Afin de se prémunir contre les attaques sur Bluetooth, il faut tout d'abord trouver des méthodes de détection de ces attaques. Quelques techniques permettent de repérer un trafic anormal lors d'échanges de données. Une fois ces attaques découvertes, on peut alors mettre en place des systèmes permettant de contrer l'attaque. Cela signifie qu'il faut la stopper tout en protégeant le périphérique, tout en réduisant au maximum les perturbations sur les échanges en cours. Des mesures doivent également être mises en place afin d'empêcher l'attaquant de réitérer son attaque. Certaines mesures simples permettent également à l'utilisateur de limiter au maximum les risques de subir une attaque.

Détection des attaques

L'analyse du trafic d'un appareil permet de déceler des anomalies dans l'utilisation de Bluetooth, et ainsi repérer des tentatives d'intrusions. Quelques règles simples d'analyse permettent de détecter des attaques de différents types :

• Les tentatives de connexion répétées qui échouent peuvent indiquer une attaque en ligne visant à découvrir le PIN de la victime;
• Des connexions et déconnexions répétées peuvent indiquer une attaque par déni de service;
• Un nombre important de transmissions NAK peut indiquer une attaque Big NAK. Cela va causer une boucle de retransmission infinie sur le périphérique;
• Des délais anormalement longs peuvent indiquer une attaque par le milieu car l'attaquant perd un certain temps pour retransmettre les paquets à la destination;
• Des réceptions répétées de paquets POLL peuvent indiquer qu'un périphérique tente d'empêcher votre appareil de passer en mode veille. En effet, un paquet POLL est normalement envoyé par un maître pour vérifier si l'esclave est toujours en vie. Un périphérique esclave recevant un paquet POLL est obligé de répondre. Dans le cadre d'une attaque, cela peut forcer la victime à ne pas entrer en mode d'économie d'énergie ou en mode veille;
• Un taux anormal d'erreurs de bits peut indiquer que l'attaquant brouille la couche physique;
• Un trafic élevé entre deux périphériques. Cela peut indiquer que l'attaquant tente une attaque par épuisement de la batterie;
• Deux BD_ADDR identiques dans la portée de vulnérabilité peuvent indiquer que l'attaquant utilise une attaque de duplication du BD_ADDR pour empêcher les victimes d'échanger des données, ou même se faire passer pour elles;
• Une requête L2CAP pour le plus grand taux de données possible ou la plus faible latence possible est suspecte. Si une telle requête est acceptée, alors les périphériques légitimes ne pourront pas avoir accès au service dans un temps raisonnable car tout le débit sera réservé pour l'attaquant;
• Des tentatives de connexion surprenantes ou les requêtes de transfert de données depuis des hôtes inconnus peuvent indiquer qu'un virus ou un ver tente d'infecter le périphérique;
• Des périphériques qui demandent une clef de chiffrement inférieure à 128bits souhaitent probablement attaquer le système cryptographique de l'appareil;
• Une discordance dans les signatures des ondes radio indique une tentative d'usurpation d'identité. En effet, chaque appareil ayant une signature radio qui lui est propre, un changement de signature pendant une connexion est le signe que l'émetteur n'est plus celui qu'il prétend être;
• Les demandes de connexion en mode JW quand l'appareil peut utiliser un mode plus sécurisé sont à proscrire. Cela peut indiquer qu'une attaque par l'homme du milieu est en cours.

Un système de surveillance peut alors être implémenté. Ce système aurait besoin de connaître certaines informations concernant les autres périphériques du picoréseau auquel l'appareil est connecté, comme la signature de ses ondes radio par exemple. Ainsi, ce système pourrait détecter les tentatives d'attaques et ainsi déclencher un système de prévention des attaques manuel ou automatique. Un système automatique est fortement recommandé. Cependant, si aucun système de prévention d'attaques n'est implémenté, l'utilisateur serait néanmoins immédiatement prévenu.

Prévention des attaques

Afin de traiter les attaques détectées par le système de détection, un système de prévention d'attaques doit être implémenté. Ce système a pour but d'empêcher l'attaque de continuer, tout en permettant au périphérique de fonctionner le plus normalement possible. Cela fonctionne en deux étapes.

Tout d'abord, ce système recevrait un message d'alerte de la part du système de détection d'erreur. Il doit alors instantanément déconnecter le périphérique afin de stopper l'attaque au plus vite. Certains types d'attaques nécessitant également des demandes répétées de connexion, le système doit refuser toute demande d'appariement pendant un temps prédéterminé.

Dans un second temps, il sera possible de retenir un maximum d'informations possible concernant l'attaquant afin d'empêcher de nouvelles tentatives d'attaques de sa part. On peut notamment garder l'adresse de l'attaquant, son nom public, les aptitudes du périphérique attaquant ainsi que sa signature d'ondes radio.

Il faut cependant prendre garde, car l'implémentation de ces solutions n'est pas possible sur tous les périphériques. En effet, Bluetooth est implémenté dans des appareils qui possèdent parfois trop peu de mémoire ou de capacité de calcul pour permettre une utilisation de solutions de détection et de traitement des attaques. C'est sur ce point que se basent la majorité des attaques afin de ne pas être bloquées.

Bonnes pratiques d'utilisation

Pour se prémunir contre les attaques sur son périphérique Bluetooth, plusieurs solutions doivent être mises en place. Tout d'abord, d'un point de vue de l'utilisateur, il est important de ne pas utiliser son périphérique n'importe où et n'importe comment. Il faut éteindre son périphérique quand il n'est pas utilisé, et le rendre non-détectable par les périphériques alentours sauf quand c'est souhaité. Il ne faut pas accepter toutes les connexions, et taper son mot de passe à l'abri des regards indiscrets. Les mots de passe doivent être suffisamment longs et aléatoires pour ne pas être devinés. Lorsqu'un périphérique est perdu ou volé, il faut supprimer la connexion à ce périphérique sur tous les appareils qui s'y sont déjà connecté.

Ensuite, il faut configurer son périphérique. En effet, les paramètres par défaut ne sont souvent pas suffisamment sécurisés. L'installation d'un antivirus peut également permettre de se prémunir contre les vers. Le mode non-secure et le modèle Just Work ne doivent pas être utilisés pour transmettre des données confidentielles. L'authentification mutuelle doit être activée lors de l'appairage. Le chiffrement pour toutes les communications en broadcast doit être également activé. Enfin, il faut régler la puissance des appareils au minimum nécessaire, afin que la portée du périphérique n'excède pas celle escomptée.

Concernant les clefs d'appairage et de chiffrement, il ne faut pas utiliser de clef unique mais des combinaisons de clefs pour éviter la réutilisation de la clef d'appairage. Les clefs de chiffrement doivent avoir une longueur d'au moins 128bits pour empêcher les attaques par force brute. Une longueur supérieure augmentera encore le temps nécessaire à une telle attaque.

Bibliographie

Faiblesses

• (en) « An analysis of Bluetooth security vulnerabilities », Wireless Communications and Networking, 2003. WCNC 2003. 2003 IEEE,‎ 16-20 march 2003, p. 1825-1831 vol.3 (ISBN 0-7803-7700-1, ISSN 1525-3511, DOI 10.1109/WCNC.2003.1200664)
  2003 IEEE Wireless Communications and Networking, 2003. WCNC 2003
• (en) Margaret Tan et Kathrine Aguilar Masagca, « An Investigation of Bluetooth Security Threats », 2011 International Conference on Information Science and Applications,‎ avril 2011, p. 1-7 (ISBN 978-1-4244-9222-0, ISSN 2162-9048, DOI 10.1109/ICISA.2011.5772388)
  2011 International Conference on Information Science and Applications
• (en) Redjem Bouhenguel, Imad Mahgoub et Mohammad Ilyas, « Bluetooth Security in Wearable Computing Applications », 2008 International Symposium on High Capacity Optical Networks and Enabling Technologies,‎ novembre 2008, p. 182-186 (ISBN 978-1-4244-2960-8, DOI 10.1109/HONET.2008.4810232)
  2008 International Symposium on High Capacity Optical Networks and Enabling Technologies
• (en) Markus Jakobsson, Susanne Wetzel et David Naccache, « Security Weaknesses in Bluetooth », Lecture Notes in Computer Science, vol. 2020,‎ avril 2001, p. 176-191 (ISBN 978-3-540-41898-6, ISSN 0302-9743, DOI 10.1007/3-540-45353-9_14)
  Topics in Cryptology — CT-RSA 2001
• (en) N. Baker, « ZigBee and Bluetooth strengths and weaknesses for industrial applications », Computing Control Engineering Journal, vol. 16, n^o 2,‎ avril 2005, p. 20-25 (ISSN 0956-3385, DOI 10.1049/cce:20050204)
  Topics in Cryptology — CT-RSA 2001
• (en) Alfred Loo, « Technical opinion: Security threats of smart phones and Bluetooth », Communications of the ACM - Being Human in the Digital Age, vol. 52, n^o 3,‎ mars 2009, p. 150-152 (ISSN 0001-0782, DOI 10.1145/1467247.1467282)

Attaques

• (en) Mike Ryan, « Bluetooth: With Low Energy comes Low Security », Presented as part of the 7th USENIX Workshop on Offensive Technologies,‎ 2013
• (en) Yaniv Shaked et Avishai Wool, « Cracking the Bluetooth PIN », MobiSys '05,‎ 6-8 juin 2005, p. 39-50 (ISBN 978-1-931971-31-7, DOI 10.1145/1067170.1067176)
• (en) Keijo M.J. Haataja et Konstantin Hypponen, « Man-In-The-Middle attacks on bluetooth: a comparative analysis, a novel attack, and countermeasures », IEEE Transactions on Wireless Communications,‎ 12-18 mars 2008, p. 39-50 (ISBN 978-1-4244-1687-5, DOI 10.1109/ISCCSP.2008.4537388)
• (en) Keijo Haataja et Pekka Toivanen, « Two practical man-in-the-middle attacks on Bluetooth secure simple pairing and countermeasures », IEEE Transactions on Wireless Communications, vol. 9,‎ janvier 2010, p. 384-392 (ISSN 1536-1276, DOI 10.1109/TWC.2010.01.090935)
  We propose two new Man-In-The-Middle (MITM) attacks on Bluetooth Secure Simple Pairing (SSP
• (en) Yi Lu, Willi Meier et Serge Vaudenay, « The Conditional Correlation Attack: A Practical Attack on Bluetooth Encryption », Lecture Notes in Computer Science,‎ aout 2005, p. 97-117 (ISBN 978-3-540-28114-6, DOI 10.1007/11535218_7)
• (en) Albert Levi, Erhan Çetintaş, Murat Aydos, Çetin Kaya Koç et M. Ufuk Çağlayan, « Relay Attacks on Bluetooth Authentication and Solutions », Lecture Notes in Computer Science,‎ septembre 2004, p. 278-288 (ISBN 978-3-540-23526-2, DOI 10.1007/978-3-540-30182-0_29)
• (en) Dennis Kügler, « “Man in the Middle” Attacks on Bluetooth », Lecture Notes in Computer Science,‎ janvier 2003, p. 149-161 (ISBN 978-3-540-40663-1, DOI 10.1007/978-3-540-45126-6_11)
• (en) Jennifer Thom-Santelli, Alex Ainslie et Geri Gay, « Location, location, location: a study of bluejacking practices », CHI EA '07 CHI '07 Extended Abstracts on Human Factors in Computing Systems,‎ 28 avril 2007, p. 2693-2698 (ISBN 978-1-59593-642-4, DOI 10.1145/1240866.1241064)
• (en) Marc Haase et Matthias Handy, « BlueTrack – Imperceptible Tracking of Bluetooth Devices », Ubicomp Poster Proceedings,‎ septembre 2004, p. 2
  Bluetooth enabled devices are potentially vulnerable against passive tracking attacks because of their unique and invariant device address. The contribution of this paper is the exploration of tracking vulnerability of Bluetooth devices. We implemented BlueTrack, a tracking system based on off-the-shelf components. We tested our system at two sites, at a university building with several lecture rooms and at a CeBIT 2004 exhibition stand.

Sécurité

• (en) Paraskevas Kitsos, Nicolas Sklavos Sklavos, Kyriakos Papadomanolakis et Odysseas Koufopavlou, « Hardware implementation of Bluetooth security », IEEE Pervasive Computing, vol. 2, n^o 1,‎ janvier 2003, p. 1096-1102 (ISBN 978-1-4673-2843-2, ISSN 1536-1268, DOI 10.1109/MPRV.2003.1186722)
  Bluetooth can implement its security layer's key-generation mechanism and authentication in software or hardware.

• (en) Gyongsu Lee et Sin-Chong Park, « Bluetooth security implementation based on software oriented hardware-software partition », IEEE International Conference on Communications, 2005. ICC 2005. 2005, vol. 3,‎ mai 2005, p. 2070-2074 (ISBN 0-7803-8938-7, DOI 10.1109/ICC.2005.1494702)
  IEEE International Conference on Communications, 2005. ICC 2005. 2005

• (en) J. Alfaiate et J. Fonseca, « Bluetooth security analysis for mobile phones », IEEE Pervasive Computing,‎ juin 2012, p. 1-6
  7th Iberian Conference on Information Systems and Technologies (CISTI 2012)

• (en) S. Sandhya et K. A. S. Devi, « Contention for Man-in-the-Middle Attacks in Bluetooth Networks », 2012 Fourth International Conference on Computational Intelligence and Communication Networks,‎ novembre 2012, p. 700-703 (ISBN 978-1-4673-2981-1, DOI 10.1109/CICN.2012.72)
  2012 Fourth International Conference on Computational Intelligence and Communication Networks

• (en) Y. W. Su, J. S. Lee et C. C. Shen, « A Comparative Study of Wireless Protocols: Bluetooth, UWB, ZigBee, and Wi-Fi », IEEE Xplore,‎ novembre 2007, p. 46-51 (DOI 10.1109/IECON.2007.4460126)
  33rd Annual Conference of the IEEE Industrial Electronics Society, 2007. IECON 2007

• (en) Kumar Panigraphy Saroj, Kumar Jena Sanjay et Kumar Turuk Ashok, « Security in Bluetooth, RFID and wireless sensor networks », Proceedings of the 2011 International Conference on Communication, Computing & Security,‎ février 2011, p. 628-633 (ISBN 978-1-4503-0464-1, DOI 10.1145/1947940.1948071)

• (en) Purvish Patel, Akash Marchant, Nisarg Tailor et Chintan Trivedi, « Bluetooth Security Issues », International Journal of Computer Science and Information Technologies,‎ 2015, p. 5295-5299 (ISSN 0975-9646)

Contre Mesures

• (en) Timothy K. Buennemeyer, Theresa M. Nelson, Michael A. Gora, Randy C. Marchany et Joseph G. Tront, « Battery Polling and Trace Determination for Bluetooth Attack Detection in Mobile Devices », 2007 IEEE SMC Information Assurance and Security Workshop,‎ 2007, p. 135-142 (DOI 10.1109/IAW.2007.381925)

• (en) Usman Sarwar, Sureswaran Ramadass et Rahmat Budiarto, « A framework for detecting bluetooth mobile worms », 2007 IEEE International Conference on Telecommunications and Malaysia International Conference on Communications,‎ 2007, p. 343-347 (DOI 10.1109/ICTMICC.2007.4448656)

• (en) Nateq Be-Nazir Ibn Minar et Mohammed Tarique, « Bluetooth Security Threats and Solutions: A survey », International Journal of Distributed and Parallel Systems,‎ 2012, p. 127-148 (DOI 10.5121/ijdps.2012.3110)

• (en) John Padgette, Karen Scarfone et Lily Chen, « Guide to Bluetooth Security », Guide to Bluetooth Security: Recommendations of the National Institute of Standards and Technology (Special Publication 800-121 Revision 1),‎ septembre 2008, p. 1-43 (ISBN 9781478168966)
  Recommendations of the National Institute of Standards and Technology

• (en) Keijo Haataja, Security Threats and Countermeasures in Bluetooth-Enabled Systems, University of Kuopio, Professor Markku Nihtilä, D.Sc. Department of Mathematics and Statistics, février 2009, 191 p. (ISBN 978-951-781-992-3, lire en ligne)

• (en) Sanna Pasanen, Keijo Haataja, Niina Paivinen et Pekka Toivanen, « New Efficient RF Fingerprint-Based Security Solution for Bluetooth Secure Simple Pairing », 2010 43rd Hawaii International Conference on System Sciences,‎ 2010, p. 1-8 (DOI 10.1109/HICSS.2010.286)

(en) EC-Council, Ethical Hacking and Countermeasures : Secure Network Operating Systems and Infrastructures, 2017, 50 p. (ISBN 978-1-305-88346-8)

Outils d'attaque

• (en) Bruce Potter, « Bluetooth security moves », Network Security, vol. 2006, n^o 3,‎ mars 2006, p. 19-20 (DOI 10.1016/S1353-4858(06)70348-8)

Voir aussi

• Informatique
• Bluetooth
• Réseaux
• Wi-Fi
• Cryptographie
• Hacker
• Picoréseau