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

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

---

Résumé : Les attaques connues sont, pour la plupart, dues à des problèmes d'implémentations : il s'agit de bugs logiciels et non de bugs intrinsèques aux différents protocoles régissant les communications Bluetooth. Presque tous les constructeurs sont concernés par ces failles. - Lire l'article



Pourquoi désactiver le Bluetooth ?

Les attaques connues sont, pour la plupart, dues à des problèmes d'implémentations : il s'agit de bugs logiciels et non de bugs intrinsèques aux différents protocoles Bluetooth. Presque tous les constructeurs sont concernés par ces failles.

Les nombreuses publications et présentations récentes liées à la sécurité de ces protocoles ont permis de sensibiliser les utilisateurs aux risques encourus, contraignant de ce fait les constructeurs à plus de sérieux dans le développement et l'intégration du Bluetooth.

Les erreurs commises par ces derniers sont extrêmement graves pour les utilisateurs. La forte concurrence du secteur des télécommunications est sans conteste un des facteurs qui les a conduits à commettre ces nombreuses erreurs.

La nécessité de sortir rapidement de nouveaux modèles, avec de nouvelles fonctionnalités non maîtrisées, y compris par les développeurs, est à l'origine de ces négligences.

Les tendances actuelles du "tout en un" rendent d'autant plus vulnérables les utilisateurs : un appareil photo, un PDA, un téléphone mobile peuvent rapidement se transformer en véritables trojans mobiles.


Présentation de l'outil BSS (Bluetooth Stack Smasher)

BSS (Bluetooth Stack Smasher) est un outil développé initialement dans le cadre de cet article et dont le but est d'effectuer différents tests sur les périphériques Bluetooth. BSS doit pouvoir effectuer ses tests de façon entièrement transparente pour les périphériques audités (aucune demande de pairing).

Une analyse de code (désassemblage, etc.) étant longue et parfois fastidieuse à mener sur des piles Bluetooth propriétaires, comme nous l'avons vu précédemment, l'idée de développer un fuzzer Bluetooth permet d'effectuer de nombreux tests "à l'aveugle", sans informations préalables.

BSS effectue un fuzzing au niveau L2CAP, permettant :

* De tester la couche la plus basse, et donc de recenser les bugs les plus "génériques" ;
* De toucher tous les types d'équipements ;
* De tester les équipements sans nécessiter d'authentification : un fuzzer fonctionnant au niveau RFCOMM, par exemple, est réalisable mais alerterait aussitôt l'équipement (considéré ici comme non vulnérable aux attaques du type BlueBug).

La base du code de BSS a été reprise de l'outil lien permettant d'exploiter des vulnérabilités de type BlueSmack. Il utilise la libbluetooth et est pour l'instant disponible uniquement sous Linux. Les structures sont notamment disponibles dans /usr/include/bluetooth : bluetooth.h, hci.h, l2cap.h, et rfcomm.h.

BSS peut être lancé en spécifiant un mode spécifique -- les paquets seront alors "semi-aléatoires" -- ou en forgeant l'ensemble des trames L2CAP aléatoirement : les 11 commandes principales (L2CAP_COMMAND_REJ, L2CAP_CONN_REQ, L2CAP_ECHO_REQ, etc.) sont supportées. D'autres types de tests sont en cours de développement pour les prochaines versions de BSS.

La dernière version de BSS est disponible sur lien

./bss -s 200 -m 12 00:80:37:ZZ:ZZ:ZZ

Le fuzzer enverra ici des paquets L2CAP entièrements aléatoires (tailles et contenus), d'une taille maximum de 200 octets (fixée par le paramètres).


Périphériques audités et résultats

La base de données Bluetooth device security database créée par Collin Mulliner (cf. lien ) contient des informations relatives à la sécurité de plusieurs périphériques. Il s'agit pour l'instant principalement de téléphones mobiles.

Elle est alimentée par les sorties de l'outil bt_audit ( lien ). L'idée d'un fuzzer Bluetooth est de parvenir à détecter un maximum de bugs "à l'aveugle", sans informations préalables (codes sources, reverse engineering, etc.).

Les équipements Bluetooth, souvent équipés de technologies propriétaires sur lesquelles le reverse engineering n'est pas forcément simple à mettre en oeuvre, les techniques de fuzzing s'appliquent à merveille dans ce contexte.

Les périphériques testés sont présentés ci-dessous. Si certains plantent systématiquement lors de la même phase du fuzzing, d'autres en revanche présentent des comportements difficilement reproductibles : files d'attentes saturées, suites de bugs mineurs, etc.

Il est surprenant de constater que les périphériques qui supportent l'intégralité des tests effectués par le fuzzer sont relativement peu nombreux. Ce n'est cependant pas un gage de sécurité : le Sony/Ericsson T68i a passé ces tests avec plus de succès que certains téléphones plus récents !


Téléphones mobiles

* Sony/Ericsson T68i : Bravo aux développeurs de la couche L2CAP... moins à ceux qui ont repris leur travail... !

Les tests de fuzzing n'ont pas permis de planter le T68i directement, contrairement à beaucoup
d'autres. En revanche, suite à certains tests menés, des anomalies sont apparues, notamment l'impossibilité d'éteindre le périphérique normalement :

- la batterie a parfois dû être enlevée. Ces bugs sont difficilement reproductibles car il est impossible de connaître le paquet (ou la suite de paquets) à l'origine des dyfonctionnements.

* Nokia N70 (S60) : suite à des tests effectués sur plusieurs N70 (un modèle français Orange, ainsi qu'un modèle chinois, leurs comportements se sont avérés différents.

Le modèle français (dont l'OS Symbian a semble-t-il été patché par Orange), est sensible aux paquets de grandes tailles : la pile Bluetooth du téléphone crashe, le rendant ainsi inaccessible :

# 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

# ./bss -m 12 -s 1000 00:15:A0:XX:XX:XX
(... snip ...)

# l2ping -c 1 00:15:A0:XX:XX:XX
Ping: 00:15:A0:XX:XX:XX 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


Figure 5: Crash de la pile Bluetooth du Nokia N70






* En revanche, le modèle chinois ne s'est pas montré faillible à cette dernière attaque.

De la même façon que le T68i, le Nokia N70 a montré un comportement anormal suite à un fuzzing BSS aléatoire (mode 12) de paquets de tailles inférieures à 200 octets. En rallumant le téléphone, plusieurs messages envoyés dans la période entre les tests et le redémarrage du téléphone ont été reçus.

* Samsung E730 : le téléphone a pu être crashé (équivalent du bouton on/off) avec des paquets de petites tailles. Un crash de la pile Bluetooth a également pu être provoqué. En raison d'une temporisation du téléphone, la valeur MAXCRASH dans le fichier bss.c a dû être modifiée. A 0, BSS effectue un scan en boucle infinie sans se soucier des réactions du téléphone.

# hcitool scan
Scanning ...
00:12:47:UU:UU:UU Samsung E730

./bss -s 15 -m 12 00:12:47:UU:UU:UU
(snip)

./bss -s 15 -m 12 00:12:47:UU:UU:UU
connect: host is down

# hcitool scan
Scanning ...

Voir lien pour les failles trouvées à l'aide de BSS sur les téléphones mobiles de la marque Sony/Ericsson, mais également le Déni de Service sur hcidump sur lien


PDA

En raison d'un manque de matériel pour effectuer ces tests sur des PDA (Palm, PocketPC, etc.), il nous a été impossible de faire des comparatifs valables. En revanche, certains vieux iPaq sont vulnérables à des paquets de grandes tailles (attaque bluesmack). BSS, de part son fonctionnement, relève ce type d'erreurs très rapidement


Nouvelles voies à explorer

Il serait intéressant de simuler un serveur sdpd bugué et d'analyser le comportement des périphériques qui le contactent. Des floods RFCOMM peuvent également être intéressants. Une analyse des services L2CAP non documentés pourrait sûrement mener à de nouveaux scénarios : des PSM sont ouverts sur la majorité des équipements.

Une analyse plus en profondeur des piles Bluetooth pourrait également être effectuée en dumpant la mémoire des équipements, soit en exploitant une faille, soit en développant un outil approprié.


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 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