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

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

---

Résumé : Présentation des différentes attaques génériques éxistantes (BlueBug, Helomoto, BlueSmack), du fonctionnement des processus de pairing ainsi que de différents outils comme Btscanner, mais aussi Bloover II & BTBrowser pour Symbian Os. - Lire l'article



Présentation des différentes attaques génériques éxistantes (BlueBug, Helomoto, BlueSmack), du fonctionnement des processus de pairing ainsi que de différents outils comme Btscanner, mais aussi Bloover II & BTBrowser pour Symbian Os.


Détection de périphériques

Les périphériques en mode non détectable peuvent être recensés par une "attaque" de bruteforce sur l'adresse Bluetooth : ceux-ci ne répondent pas aux diffusions de type inquiry (broadcasts) mais peuvent cependant être identifiés directement.

Si l'attaque semble irréaliste sur une plage allant de 00:00:00:00:00:00 à FF:FF:FF:FF:FF:FF avec un seul dongle (environ 11 heures), elle est cependant imaginable sur de plus petites plages (plages de constructeurs par exemple, ce qui réduit le scan à, au plus, 3 octets), ou en parallélisant le scan à l'aide de plusieurs dongles Bluetooth (90 minutes environ avec 8 dongles). L'outil redfang permet d'effectuer ces recherches de périphériques.

btscanner (cf. lien ) permet de lister les périphériques disponibles et fournit également diverses informations les concernant :


Figure 3: Détection de périphériques avec btscanner





lien pour aggrandir


Processus de pairing

Le pairing -- processus permettant d'autoriser, ou non, un périphérique distant à se connecter sur un service local -- peut prendre plusieurs formes :

* Demande explicite sur le terminal distant, souvent sous la forme d'un message d'avertissement contenant le nom Bluetooth du périphérique tentant d'établir la connexion : "BlueEvil tente de se connecter à votre périphérique, voulez-vous accepter la connexion ?" ;

* Aucune demande, il s'agit bien souvent de PIN Bluetooth prédéfinis par les constructeurs. En effet, tous les périphériques ne possèdent pas d'écran et/ou d'interface de saisie : celui-ci est alors attribué par le constructeur. Dans le meilleur des cas, le constructeur génère les PIN de façon aléatoire, et le notifie sur le manuel d'utilisation, par exemple. En revanche, certains constructeurs continuent (encore!) à attribuer des PIN par défaut (1234, 0000, etc...) : il est donc facile pour un attaquant de se connecter sur le périphérique distant.

Le multi-pairing permet à plusieurs terminaux de se connecter simultanément sur un même service. Bien souvent, le multi-pairing est nocif à la sécurité de l'équipement, comme cela a pu être démontré avec l'outil carwhisperer (cf. lien ).

Il exploite 2 graves erreurs de certains modèles d'oreillettes Bluetooth que sont le multi-pairing et la définition de PIN par défaut. carwhisperer permet alors d'écouter le flux audio de façon entièrement transparente, et également d'en injecter via le port RFCOMM concerné.


Figure 4: Oreillette Bluetooth






Il est en effet bien souvent inutile d'autoriser le multi-pairing, même si cela ne constitue pas en soi un défaut de sécurité majeur.

D'autres attaques, passives ou actives, concernant le processus de pairing existent, notamment des attaques permettant de casser un PIN avec une écoute passive d'association entre 2 périphériques (cf. lien ).

Nous ne détaillerons pas cette dernière attaque qui relève plus de la cryptologie que de notre étude. Il n'existe pas encore à l'heure actuelle de PoC (Proof of Concept) public.


BlueBug

Le BlueBug est sûrement la faille pouvant se révéler la plus lourde de conséquences pour une victime. Elle consiste à se connecter sur un port RFCOMM ne nécessitant aucune authentification (pas de pairing) permettant l'accès à un set de commandes AT*. Ces commandes permettent un contrôle (quasi) intégral au téléphone, à ses paramètres, sa configuration, etc.

De nombreux scénarios peuvent être imaginés. La simplicité de cette attaque est redoutable face aux conséquences qu'elle peut avoir (factures de téléphone astronomiques, compromission de données sensibles, etc.). Il suffit de sniffer rapidement les équipements présents dans un lieu public pour se rendre compte de son réalisme et de la simplicité de sa mise de en oeuvre.


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






La figure 1 en atteste : en moins de 5 minutes, un premier T610 vulnérable à cette attaque était déjà détecté, suivi de nombreux Nokia 6310!

# Connexion sur le canal RFCOMM 17
rfcomm bind 0 00:80:37:ZZ:ZZ:ZZ 17

# Communication série :
cu -l /dev/rfcomm0

connected
> ATI
OK
(ctrl-c)

rfcomm release 0


Le scénario décrit sur lien présente la compromission d'un téléphone Sony/Ericsson T68i le transformant en microphone de poche à l'insu de son propriétaire. L'outil rfcomm_scan de la "suite" bt_audit lien permet de détecter rapidement les équipements vulnérables à cette attaques :

rfcomm_scan -o -s 1 -e 4 XX:XX:XX:XX:XX:XX
rfcomm: 01 open
rfcomm: 02 open
rfcomm: 03 open
rfcomm: 04 open

Il est possible de récupérer le carnet d'adresses avec les commandes AT : btxml (cf. lien ) permet d'automatiser ces commandes et propose une sortie XML du carnet d'adresses distant. Le canal RFCOMM 17 est utilisé par défaut :

bacpy(&req.src, BDADDR_ANY);
bacpy(&req.dst, bdaddr);
req.channel = 17;

Les spécifications techniques des commandes AT Nokia sont disponibles sur lien (cliquer sur "try again" quand vous serez sur la page du lien) et sur lien pour les modèles Sony/Ericsson.


Helomoto

Comme son nom l'indique ironiquement, Helomoto ( lien ) est une attaque visant les téléphones mobiles Motorola. Elle consiste à initier l'envoi d'un objet OBEX (à la façon du BlueJacking). Celui-ci, volontairement interrompu, permet de placer l'attaquant dans la liste des périphériques de confiance.

Une fois ajouté, l'attaquant peut se connecter en RFCOMM (BlueBug) sur le service RFCOMM Headset de l'appareil sans authentification préalable. La suite est une attaque type BlueBug classique...


BlueSmack

BlueSmack est une attaque visant à bloquer les périphériques Bluetooth (crash de la pile ou du système d'exploitation distant) via une requête l2ping anormalement longue ou via de très nombreuses requêtes (flood ping).

Une description plus détaillée de l'attaque est disponible sur lien : les PDA iPaqs plantent avec des pings L2CAP d'une taille supérieure à 600 octets.

Certains équipements limitent la taille des trames L2CAP reçues, réduisant ainsi les risques de congestion au niveau de leurs files d'attente :

# l2ping -c 1 -s 247 00:80:37:ZZ:ZZ:ZZ
Ping: 00:80:37:ZZ:ZZ:ZZ from 00:20:E0:75:83:DA (data size 247) ...
0 bytes from 00:80:37:ZZ:ZZ:ZZ id 0 time 60.86ms
1 sent, 1 received, 0% loss

# l2ping -c 1 -s 248 00:80:37:ZZ:ZZ:ZZ
Ping: 00:80:37:ZZ:ZZ:ZZ from 00:20:E0:75:83:DA (data size 248) ...
no response from 00:80:37:ZZ:ZZ:ZZ id 0
1 sent, 0 received, 100% loss

Il n'existe pas de norme pour le MTU (Max Transmission Unit) des paquets L2CAP. Des trames forgées semi-aléatoires peuvent cependant conduire à un déni de service (cf. lien ).


Outils Symbian

Des outils permettant d'évaluer la sécurité de périphériques Bluetooth existent pour l'OS embarqué Symbian présent sur de nombreux téléphones mobiles :

Blooover II (cf. lien ) développé par le groupe Trifinite permet de tester différentes attaques (BlueBug, BlueSnarf/BlueSnarf++, BlueSmack, etc.). Il se révèle très pratique dans le cadre de tests d'intrusion permettant d'établir un premier diagnostic rapide. Certaines piles sont cependant incompatibles entre elles.

BTBrowser (cf. lien ) permet de lister les périphériques disponibles ainsi que les services qui leur sont associés via des requêtes SDP.


Autres ressources sur la sécurité Bluetooth :

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

[Dossier Sécurité Bluetooth - partie 2] Présentation des utilitaires Bluetooth 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