[Dossier Sécurité Bluetooth - partie 1] Introduction aux technologies Bluetooth

Par Pierre Betouin, secuobs.com
Le 05/02/2006

---

Résumé : Jusqu'à récemment, Bluetooth ne faisait pas l'objet d'inquiétudes particulières concernant les menaces liées à la sécurité de ses équipements, notamment en raison de sa faible portée. De plus grandes distances ont depuis pu être atteintes - Lire l'article



Bluetooth est un protocole de communications sans-fil courtes distances qui a été largement déployé depuis plusieurs années dans de nombreux types de périphériques (téléphones mobiles, ordinateurs portables, GPS, routeurs, imprimantes, appareils photos, etc.). Il fonctionne dans la gamme des 2.4GHz tout comme son homologue 802.11. Il existe 79 canaux Bluetooth, d'une largeur de bande d'1MHz chacun.

Jusqu'à récemment, Bluetooth ne faisait pas l'objet d'inquiétudes particulières concernant les menaces liées à la sécurité de ses équipements, notamment en raison de sa faible portée (quelques dizaines de mètres sur les équipements "normaux"). De plus grandes distances ont depuis pu être atteintes (cf. lien Long-Distance-Snarf ) avec des équipements appropriés : antennes directionnelles, etc.

Les technologies employées pour augmenter les distances de communication sont très proches de celles utilisées en 802.11 en raison de leurs gammes de fréquences équivalentes. Il suffit de se rendre dans un lieu relativement fréquenté (gares, cinémas, aéroports, etc.) avec un scanner Bluetooth pour comprendre l'ampleur des risques encourus d'avoir un équipement Bluetooth activé dans sa poche.

Les conséquences de la compromission d'un cellulaire ou d'un assistant personnel peuvent se révéler critiques, allant du simple déni de service, à la récupération du carnet d'adresses, de la consultation des derniers appels émis/reçus, de la lecture des SMS, ou à l'établissement (entièrement transparent pour la victime) d'un appel ou d'une connexion Internet.

Les premières spécifications ont été développées par Ericsson. Le SIG (Special Interest Group), composé entre autres d'Ericsson, IBM, Intel, Microsoft, Motorola, Nokia, ou Toshiba, a pris le relais en 1999. Les spécifications techniques sont disponibles sur lien

Si le protocole en lui-même est relativement bien pensé, les nombreuses implémentations, elles, le sont beaucoup moins : leur nombre important entraîne indéniablement de nombreux soucis concernant la sécurité. Il est d'ailleurs possible de retrouver des bugs équivalents pour des implémentations différentes. Les enseignements du passé n'ont malheureusement toujours pas servi de leçon.

Un périphérique Bluetooth maître peut communiquer avec 7 autres périphériques esclaves au maximum. Le "réseau" ainsi crée s'appelle un Piconet. Un Scatternet quant à lui consiste en une interconnexion de réseaux de type Piconet, grâce à des périphériques jouant le rôle de "routeurs". Le nombre de Piconets est limité à 10 dans un Scatternet.


Figure 1 : Découverte d'équipements Bluetooth sur Symbian






Un équipement Bluetooth est caractérisé principalement par :

* Son adresse BT (BD_ADDR), similaire à une adresse MAC : les 3 premiers octets sont ceux définis par le constructeur, suivis de 3 octets propres à l'équipement;

* Sa classe, propre au type de périphérique : oreillette Bluetooth, téléphone mobile. Attention cependant : les valeurs des classes varient selon les constructeurs pour des types de périphériques pourtant équivalents.

La quasi-intégralité des routines de bas niveau relatives à la sécurité est directement implémentée dans le chipset Bluetooth de façon matérielle. L'interface avec l'OS s'effectue via le protocole HCI (cf. ci-dessous). Il existe 3 modes de sécurité Bluetooth :

* Mode 1 : Pas de mécanisme de sécurité. Ce mode peut être comparé à un hotspot public 802.11 par exemple;
* Mode 2 : Sécurité assurée au niveau applicatif;
* Mode 3 : Sécurité assurée au niveau liaison de données.


HCI

Le protocole Bluetooth peut se décomposer en sous-couches liées les unes aux autres : les attaques distantes peuvent donc s'opérer à différents niveaux. L'abstraction matérielle est assurée par HCI (Host Controller Interface); il s'agit de l'interface entre l'OS et le firmware Bluetooth. Celui-ci gère différentes opérations basiques, dont la découverte des équipements distants :

# hcidump
HCI sniffer - Bluetooth packet analyzer ver 1.28
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Inquiry (0x01|0x0001) plen 5
> HCI Event: Command Status (0x0f) plen 4
> HCI Event: Inquiry Result (0x02) plen 15
> HCI Event: Inquiry Result (0x02) plen 15
> HCI Event: Inquiry Complete (0x01) plen 1


Figure 2: Principaux protocoles Bluetooth






L2CAP

L2CAP est l'équivalent d'un protocole d'accès au média, propre au Bluetooth, permettant de multiplexer des protocoles de couches supérieures (RFCOMM par exemple) et de gérer les contraintes telles que la fragmentation des paquets et le ré-assemblement.

Il fonctionne via des canaux appelés PSM (Protocol/Service Multiplexer) qui se chargent de rediriger les requêtes vers les protocoles des couches supérieures. Le protocole RFCOMM (de type liaison série Bluetooth) utilise par exemple le PSM 3 tandis que SDP (Service Discovery Protocol) utilise le PSM 1.

Les PSM sont comparables, par analogie, à des ports TCP/UDP. D'autres PSM non documentés sont disponibles sur certains équipements. Il est alors typiquement difficile pour un utilisateur de s'assurer qu'il ne s'agit pas d'une porte dérobée ou d'un "service de débuguage". L'outil psm_scan (cf. lien ) permet de lister les PSM accessibles. Un grand nombre d'entre eux est également répertorié sur la base de données lien


SDP

SDP (Service Discovery Protocol) permet de lister les services disponibles sur un périphérique, ainsi que différentes informations relatives : PSM/Ports RFCOMM, description des services, encodage, etc. Il s'agit uniquement d'informations : il est tout à fait possible d'utiliser un service sans que celui-ci soit pour autant repertorié par le serveur SDP distant.

En revanche, certaines implémentations (notamment sur des téléphones et PDA) nécessitent que le service soit enregistré sur le serveur SDP pour y accéder. Les Liveboxes Wanadoo supportant le Bluetooth,par exemple, utilisent une pile modifiée qui ne déclare aucun service : ceux-ci sont pourtant accessibles directement.

# sdptool browse 00:03:C9:YY:YY:YY
Browsing 00:03:C9:YY:YY:YY ...

# psm_scan 00:03:C9:YY:YY:YY
psm: 0x0001 status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS
psm: 0x0003 status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS
psm: 0x0007 status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS
psm: 0x000f status: L2CAP_CS_NO_INFO result: L2CAP_CR_SUCCESS

Voici ci-dessous un enregistrement SDP de service Dial-Up Networking sur un téléphone mobile :

Service Name: Dial-Up Networking
Service RecHandle: 0x1000f
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0x454e
encoding: 0x6a
base_offset: 0x100
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100

Le service est disponible au niveau L2CAP sur le PSM 3, et sur le port RFCOMM 3.


RFCOMM

Le protocole RFCOMM permet d'effectuer des communications de type RS232 (série) sur L2CAP en Bluetooth. Les téléphones mobiles, par exemple, permettent un accès RFCOMM au travers de commandes AT* (AT, ATZ, ATDT, et autres).

Les oreillettes Bluetooth peuvent également utiliser RFCOMM via un service Handfree Audio Gateway par exemple. De nombreux équipements communiquent via RFCOMM : selon l'implémentation de la pile Bluetooth, et le port RFCOMM, une authentification de type pairing peut (et devrait!) être requise.


OBEX

OBEX (OBject EXchange) est un protocole d'échange d'objets, comme son nom l'indique, tels que des entrées de calendriers, de carnets d'adresses, ou encore de simples fichiers. Il est donc possible d'envoyer (commande PUSH), ou de recevoir (commande PULL) des données depuis un terminal Bluetooth. Comme le montre la figure 2, OBEX fonctionne au dessus de RFCOMM. Le port utilisé est en général indiqué dans l'enregistrement du serveur SDP :

Service Name: OBEX Object Push
Service RecHandle: 0x10000
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 5
"OBEX" (0x0008)
(...)


Autres ressources sur la sécurité Bluetooth :

[Dossier Sécurité Bluetooth - partie 2] Présentation des utilitaires Bluetooth lien

[Dossier Sécurité Bluetooth - partie 3] Les attaques génériques lien

[Dossier Sécurité Bluetooth - partie 4] Les attaques d'implémentations lien

[Dossier Sécurité Bluetooth - partie 5] Scénarios possibles & synthèse lien

[Infratech - vulnérabilité] PoC pour le DoS sur les téléphones portables Sony/Ericsson lien

[Infratech - vulnérabilité] Déni de Service sur les téléphones mobiles Sony/Ericsson lien

[Infratech - vulnérabilité] PoC pour le DoS sur hcidump lien

[Infratech - vulnérabilité] Déni de Service sur hcidump lien

[Infratech - release] BSS - Bluetooth Stack Smasher v0.6 lien