Sur les postes, casques, pointeurs et objets connectés, le Bluetooth est souvent activé par défaut. Pourtant il reste rarement dans le périmètre d’un pentest « classique ». Résultat : une couche visible à quelques mètres, mais absente des rapports — et des tableaux de bord réseau.
Introduction
Les missions de test d’intrusion se structurent en général autour du périmètre IP : applications web, API, Active Directory, segmentation réseau. C’est cohérent : c’est là que se concentrent les expositions documentées et les SLA de remédiation.
Le Bluetooth ne figure pas dans les règles de pare-feu classiques. Il ne traverse pas le SI comme un flux TCP. Il s’active au niveau radio, souvent hors des journaux centralisés que le SOC consulte quotidiennement. Pour un attaquant en proximité, c’est une autre porte — pas une « faille miracle », mais une surface réelle quand le contexte le permet.
Le problème
Activation implicite. Beaucoup d’équipements arrivent avec le Bluetooth allumé ; les utilisateurs ne le désactivent pas. Les politiques MDM couvrent souvent Wi‑Fi et VPN, pas toujours l’état fin du module BT sur chaque modèle.
Pentests cadrés sur l’IP. Les cahiers des charges listent des URL, des plages d’adresses, parfois du Wi‑Fi interne. Rarement : « cartographier les périphériques BLE/BT visibles depuis la salle de réunion ou le parking ». Le risque n’est pas « oublié » au sens moral — il est hors scope opérationnel.
Angle mort détection. Sans capteurs ou politiques dédiées, le SOC voit mal ce qui se passe en 2,4 GHz entre un laptop et un casque. L’incident « radio » ne remonte pas comme une alerte IDS sur un segment VLAN.
Risques en environnement entreprise
- Exposition de proximité — salles de réunion, open space, zones d’accueil : un acteur présent physiquement peut interagir avec des appareils émetteurs sans passer par votre DMZ.
- Chaîne de confiance floue — casques, souris, claviers, traceurs : le pairing lie des périphériques aux postes de travail. Une mauvaise habitude utilisateur (accepter une demande de connexion) contourne des contrôles réseau bien architecturés.
- Données et méta-données — noms d’appareils, services annoncés, parfois des identifiants ou des traces d’usage : utiles pour la reconnaissance ciblée, pas pour un exploit « à distance depuis Internet ».
- IoT et matériel hétérogène — firmwares peu suivis, mises à jour irrégulières : la surface logicielle du contrôleur BT rejoint le problème de gestion du parc, pas seulement celui du pentest annuel.
Ce ne sont pas des scénarios « Hollywood ». Ce sont des contraintes physiques et procédurales : portée courte, besoin de présence ou de victime coopérative pour certaines étapes — mais suffisant pour des campagnes ciblées ou des tests internes mal cadrés.
Exemples d’attaques réalistes
Discovery et fingerprinting. L’inquiry et les scans (selon protocole et mode) permettent de lister des équipements visibles, classes de périphériques, parfois des services. C’est de la reconnaissance — la base d’un scénario plus poussé.
Abus du pairing. Lorsque l’utilisateur peut associer de nouveaux périphériques sans garde-fous, ou lorsque des modes historiques faibles sont encore présents sur du matériel ancien, un attaquant de proximité peut tenter de s’insérer dans la relation de confiance (selon protocole et version). Le détail dépend du jeu exact BT/BLE et du matériel — d’où l’intérêt des tests en labo plutôt que des généralisations abusives.
Attaques de proximité. Keyboards et HID via des chemins non USB, relais de courte portée dans certains scénarios documentés en recherche, ou simple test d’acceptation utilisateur (demande de connexion légitime en apparence). Le point commun : proximité et confiance utilisateur, pas une compromission du pare-feu périmétrique.
Outil d’illustration. Pour structurer des tests et de la recherche autour de Bluetooth Low Energy et des scénarios associés, des équipes s’appuient sur des frameworks communautaires comme bluesploit (GitHub) — utile en environnement contrôlé et avec mandat clair, pas sur du matériel tiers sans autorisation.
Recommandations
- Politique — désactiver le Bluetooth là où il n’a pas de justification métier ; le laisser éteint par défaut sur les profils sensibles (accès privilégié, ingénierie, admin).
- MDM / poste — lorsque l’OS et l’outil de gestion le permettent, verrouiller ou restreindre l’ajout de périphériques et documenter les exceptions.
- Pentest — ajouter un volet « radio courte portée » dans le scope quand le risque métier le justifie (sites à forte exposition physique, bureaux partagés, flottes IoT). Formaliser lieux, matériel autorisé et règles de non-dégâts.
- Monitoring — conscience des limites : pas de miracle « IDS Bluetooth » partout. En revanche : inventaire, revue des périphériques approuvés, sensibilisation aux demandes de pairing inattendues.
- Audit — pour les déploiements IoT ou industriels utilisant BLE, inclure la couche radio dans les revues de conception et les tests de régression firmware, comme pour tout autre canal d’accès.
Le Bluetooth n’est pas une « backdoor universelle ». C’est une surface honnête : courte portée, souvent activée, souvent hors scope. L’aligner avec le risque réel de l’organisation — et le traiter comme le reste du périmètre — est le geste le plus mature pour pentesters et SOC.