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

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

---

Résumé : Vous trouverez ici une présentation des différents outils (hcitools, l2ping, sdptool, rfcomm, hcidump) permettant de manipuler les opérations effectuées avec le protocol de communication Bluetooth. - Lire l'article



Vous trouverez ici une présentation des différents outils (hcitools, l2ping, sdptool, rfcomm, hcidump) permettant de manipuler les opérations effectuées avec le protocol de communication Bluetooth.


hcitool

La recherche de périphériques s'effectue via une commande de type inquiry. Les périphériques contactés doivent être joignables et détectables (mode discoverable). Il est possible, comme nous le verrons ci-dessous, d'identifier par bruteforce ceux qui sont en mode caché.

# hcitool inq
Inquiring ...
00:15:A0:XX:XX:XX clock offset: 0x4b4e class: 0x50020c
00:03:C9:YY:YY:YY clock offset: 0x7e8d class: 0x520310

Ici, 2 périphériques sont détectés : respectivement un téléphone mobile Nokia N70 et une Livebox Wanadoo.

Nous pourrions croire qu'il existe une relation entre les requêtes de découverte inquiry et le protocole SDP mais il n'en n'est rien (cf. sortie d'hcidump ci-dessus). Ce processus est géré de façon matérielle par le chipset Bluetooth de l'équipement : il s'agit de requêtes interfacées via le protocole HCI.


l2ping

l2ping permet d'envoyer à un périphérique des paquets de niveau L2CAP de type ECHO REQUEST, à la manière d'un ping ICMP. La taille des paquets, leur nombre, ainsi que l'adresse Bluetooth source peuvent être spécifiés. Certaines implémentations des piles ne répondent volontairement pas à ces requêtes. C'est le cas de nombreuses oreillettes Bluetooth par exemple.

# l2ping -c 3 00:15:A0:XX:XX:XX
Ping: 00:15:A0:XX:XX:XX from 00:20:E0:75:83:DA (data size 44) ...
0 bytes from 00:15:A0:XX:XX:XX id 0 time 64.18ms
0 bytes from 00:15:A0:XX:XX:XX id 1 time 43.94ms
0 bytes from 00:15:A0:XX:XX:XX id 2 time 37.25ms
3 sent, 3 received, 0% loss


sdptool

sdptool permet d'effectuer différentes opérations au niveau L2CAP : des requêtes directes vers les périphériques distants, mais également la configuration du serveur sdpd (ajout/suppression de services par exemple) sur la machine locale afin de répondre aux requêtes SDP entrantes.

sdptool [options] [command parameters]
Options:
-h Display help
-i Specify source interface
Commands:
search Search for a service
browse Browse all available services
records Request all records
add Add local service
del Delete local service
get Get local service
setattr Set/Add attribute to a SDP record
setseq Set/Add attribute sequence to a SDP record

Services:
DID SP DUN LAN FAX OPUSH FTP HS HF SAP NAP GN PANU HID CIP CTP
A2SRC A2SNK SYNCML NOKID PCSUITE SR1

La commande sdptool browse 00:15:A0:XX:XX:XX permettra de lister les services disponibles sur le téléphone mobile (Nokia N70), et ils peuvent parfois s'avérer très nombreux !

La multiplication des services distants les rend évidemment d'autant plus vulnérables. Les arguments add et del permettent d'enregistrer de nouveaux services sur la machine locale.

L'ajout d'un serveur OBEX et de son enregistrement SDP correspondant s'effectue avec :

sdptool add --channel=10 OPUSH
obexserver


rfcomm

rfcomm permet d'établir une communication de type RFCOMM entre 2 périphériques. Le module noyau rfcomm se chargera de créer le lien /dev/rfcomm[X] vers le périphérique si l'argument bind est employé.

Commandes :

bind [channel] Bind device
release Release device
show Show device
connect [channel] Connect device
listen [channel] Listen

* La commande permettant de se connecteur au téléphone Nokia sur le canal 6, via /dev/rfcomm0 est rfcomm bind 0 00:15:A0:XX:XX:XX 6 ;

* La déconnexion est assurée avec rfcomm release 0

Les outils permettant de communiquer sur un lien RS232 sont nombreux, citons notamment minicom ou cu : cu -l /dev/rfcomm0

Le périphérique distant alertera l'utilisateur qu'une connexion entrante tente de s'établir -- lui laissant alors le choix de l'accepter ou de la décliner -- (nous verrons que ce n'est pas toujours le cas...), il s'agit du processus de pairing.


hcidump

hcidump permet, notamment aux développeurs, de suivre les envois et réceptions de paquets à partir du protocole HCI jusqu'à des protocoles de plus haut niveau. Il est analogue, bien que beaucoup moins évolué, à un outil du type tcpdump (sniffer réseau).

Cependant, hcidump ne permet pas d'écouter le trafic ne concernant pas la machine locale car le trafic est filtré de façon matérielle par le chipset Bluetooth. Une écoute passive de trafic est cependant possible en utilisant des chipsets Bluetooth spécifiques (tels que lien ). Voir la requête de type inquiry.


Autres ressources sur la sécurité Bluetooth :

[Dossier Sécurité Bluetooth - partie 1] Introduction aux technologies 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