Un grand nombre d’objets connectés utilisent la technologie Bluetooth Low Energy afin d’offrir une connectivité avec des smartphones. Afin d’évaluer la sécurité de ces derniers, il est nécessaire de pouvoir étudier les communications entre ces smartphones et leurs applications associées et les objets connectés, de façon fiable et pratique. Jusqu’à peu de temps, la seule solution consistait à « sniffer » les communications à l’aide de matériel dédié, mais c’était laborieux et relativement aléatoire. Une alternative possible consiste à réaliser une interception active, avec une approche de l’homme du milieu, ou « man in the middle », mais cette approche était impossible à réaliser faute d’outil adéquat. Cette présentation rappellera les bases du protocole Bluetooth Low Energy, les raisons des échecs rencontrés lors de l’utilisation de sniffers relativement populaires, pour enfin présenter le framework d’interception BtleJuice, permettant de mettre en œuvre une interception active reposant sur une approche man-in-the-middle. Des démonstrations live seront effectuées afin de démontrer l’efficacité et les possibilités offertes par cet outil, en les mettant en œuvre sur différents objets connectés. Enfin, des contre-mesures adaptées seront évoquées afin de limiter ce type d’attaque et d’améliorer la sécurité des objets connectés utilisant ce protocole de communication.

1. BtleJuice, un framework d’interception pour le
Bluetooth Low Energy
Damien "virtualabs" Cauquil
NetSecureDay 2016

2. 2
Qui suis-je ?
• Chercheur en sécurité au CERT-UBIK (Digital Security)
• Responsable R&D
• Focus sur le Bluetooth Smart depuis 2014

3. 3
Sommaire
• Le B-A BA du BLE
• Pourquoi le sniffing est (presque) un échec ?
• Les attaques Man-in-the-Middle sur Bluetooth Smart
• Présentation de BtleJuice
• Démos live 1
1. ou des vidéos si ça loupe

4. Le B-A BA du BLE

5. 5
Le B-A BA du BLE
Beaucoup d’équipements utilisent le BLE
• Equipements médicaux
• Monitoring devices
• Cochlear implants
• Insulin pumps
• Systèmes de contrôle d’accès
• Padlocks
• Locks
• Key dematerialization
• Sex toys

6. 6
Le B-A BA du BLE
Spécifications
• Les spécifications BLE font partie de la norme Bluetooth 4.0+
• Le protocole Bluetooth Low Energy est peu gourmand en
énergie
• BLE est plus léger que le protocole Bluetooth Classic
• BLE est très utilisé dans des équipements connectés

7. 7
Le B-A BA du BLE
Caractéristiques RF
• Utilise la bande de fréquence 2.40 - 2.48 GHz
• La bande est "découpé" en 40 canaux de 2MHz
• 3 canaux d’annonce sont répartis sur la bande de fréquence
• Le protocole utilise du saut de fréquence (FHSS)

8. 8
Le B-A BA du BLE
Couches protocolaires

9. 9
Le B-A BA du BLE
Link Layer et Logical Link Control
• Link layer
• Définit deux rôles : master et slave
• Les Masters gèrent plusieurs connections avec des slaves
• Les Slaves ne supporte généralement qu’une connexion unique
avec un master
• Link layer control
• L2CAP assure le transport des données
• Les fonctionnalités de retransmission et de contrôle de flux sont
désactivées

10. 10
Le B-A BA du BLE
GAP & ATT
• Generic Attribute Profile (GAP)
• Définit quatre rôles dont : central and peripheral
• Attribute Protocol (ATT)
• Fournit les services et leurs characteristics
• Les services et les characteristics sont référencés par un UUID
de 16 ou 128 bits
• Services standards et characteristics (Bluetooth SIG)
• Blood Pressure Profile
• Heart Rate Profile
• Health Thermometer Profile
• etc.
• Opérations supportées : lecture, écriture, notification, indication

11. 11
Le B-A BA du BLE
Fonctions de sécurité
Bluetooth Smart définit des fonctions de sécurité via le Security
Manager Protocol :
• Authentification
• Autorisation
• Integrité
• Confidentialité (chiffrement)

12. 12
Le B-A BA du BLE
Fonctions de sécurité
Ces mécanismes de sécurité sont activés grâce à l’appairage.
1. Chaque équipement communique sur ses caractéristiques
2. Une clé temporelle (TK) est dérivée du PIN ou de transmise
OOB
• Une clé par défaut est utilisé s’il est impossible de
communiquer/saisir un PIN → JustWorks)
3. Mise en accord sur une clé à court terme (Short Term Key),
calculée à partir de TK et de données aléatoires
4. Echange des clés définitives (LTK, IRJK, CSRK)

13. 13
Le B-A BA du BLE
Etablissement d’une connexion
1. L’équipement Peripheral s’annonce sur un des 3 canaux
d’annonce
2. L’équipement Central reçoit l’annonce et envoie un demande
de connexion CONNECT_REQ
3. La connexion est établie et les deux équipements sautent d’un
canal à l’autre de façon synchrone

14. Pourquoi le sniffing est (presque)
un échec ?

15. 15
Pourquoi le sniffing est (presque) un échec ?
Equipements disponibles pour sniffer
BlueFruit LE Sniffer and Ubertooth One

16. 16
Pourquoi le sniffing est (presque) un échec ?
Comment fonctionne un sniffer BLE ?
1. Le sniffer itère sur les canaux d’annonce dans l’attente d’une
réception de demande de connexion sur l’équipement ciblé ;
2. Il se synchronise ensuite avec les paramètres contenus dans la
demande et suit la connexion en utilisant le saut de fréquence.

17. 17
Pourquoi le sniffing est (presque) un échec ?
Les raisons de l’échec probable
Il faut être chanceux pour sniffer une connexion Bluetooth Smart :
• Il faut réussir à intercepter un packet CONNECT_REQ sur le
bon canal d’annonce (1 chance sur 3) ;
• Votre sniffer doit être suffisamment "intelligent" pour ne pas
décoder les packets qui ressemblent à du Bluetooth
Smart (perte de temps).

18. 18
Pourquoi le sniffing est (presque) un échec ?
Je ne suis pas le seul à galérer ...

19. Man-in-the-Middle FTW !

20. 20
Man-in-the-Middle FTW !
MitM vs. Sniffing
Une approche MitM est plus efficace :
• L’assurance que l’équipement central va communiquer avec
notre équipement periphal émulé
• Plus de problème d’appairage
• Pas de matériel spécifique, des dongles USB Bluetooth 4.0+
font l’affaire

21. 21
Man-in-the-Middle FTW !
Le proxy
Il nous faut un proxy dédidé pour réaliser une attaque
Man-in-the-Middle :
• Le proxy se connecte sur l’équipement cible et dresse son
"profil" (informations d’annonce, services et characteristics) ;
• Il crée un périphérique émulé avec les même caractéristiques ;
• On attend une connexion sur le périphérique émulé, le proxy
relaie les opérations vers le véritable équipement.
Ce proxy est similaire aux proxys HTTP(S) proxies comme Burp ou
OWASP Zap.

22. 22
Man-in-the-Middle FTW !
Présentation du framework BtleJuice
• Noble pour le proxy and Bleno pour l’équipement émulé
• Communication websocket entre le core et le proxy
• Fournit un interface web et des bindings

23. 23
Man-in-the-Middle FTW !
Fonctionnalités de BtleJuice
• Sniffing d’opérations GATT et des données échangées
• Interception type Burp permet la manipulation des données
• Interface utilisateur Web
• Export en texte et JSON
• Bindings pour Python (2.X and 2.3)
• Bindings pour Node.js (ES6)

24. 24
Man-in-the-Middle FTW !
Pré-requis système
• 2 machines (ou une machine et une VM)
• Au moins un dongle USB Bluetooth 4.0+ compatible
(Cambridge Silicon Radio, idéalement)
• Node.js version >= 4.3.0

25. 25
Man-in-the-Middle FTW !
Guide d’installation
Facile :
$ sudo apt-get install bluetooth bluez
libbluetooth-dev libudev-dev
$ sudo npm install -g btlejuice

26. 26
Man-in-the-Middle FTW !
Interface utilisateur Web

27. 27
Man-in-the-Middle FTW !
Modification de données à la volée
Le code suivant permet d’émuler une décharge de batterie :
def on_before_read(self, service, characteristic, offset):
if service.lower() == ’180f’ and
characteristic.lower()==’2a19’:
self.batt_level -= 1
if self.batt_level < 0:
self.batt_level = 100
raise HookForceResponse(chr(self.batt_level))
def on_before_subscribe(self, *args, **kwargs):
# dismiss
raise HookForceResponse()

28. 28
Man-in-the-Middle FTW !
Contraintes connues
Il y a tout de même quelques contraintes :
• Pas de support des écritures longues (> 22 bytes)
• Temps de latence induit

29. BtleJUice, BtleJuice, BtleJuice !

30. 30
Démos live
Des données pas si secrètes

31. 31
Démos live
Des données pas si secrètes
Le code PIN est transmis en clair :
Pas d’appairage requis pour communiquer avec le cadenas.

32. 32
Démos live
Fonctions cachées

33. 33
Démos live
Fonctions cachées
Nos tests ont montré que :
• Le robot est identifié mais pas authentifié ;
• Aucun chiffrement n’est utilisé (pas d’appairage) ;
• Plusieurs sons sont inclus dans le firmware mais ne sont pas
utilisés ;
• Aucune protection contre le rejeu n’est implémentée.

34. 34
Démos live
Modification de données à la volée

35. 35
Démos live
Modification de données à la volée
Nos tests ont montré que :
• Ce glucomètre n’est authentifié qu’à partir de son adresse
BD ;
• Aucun chiffrement n’est utilisé (à nouveau, pas d’appairage ;
• Les données ne sont pas signées ni protégées contre les
modification ;
• Les données collectées peuvent être transmises à un service de
télé-santé ;
• Ces attaques nécessitent que l’équipement soit activé par
une action de l’utilisateur.

36. Contre-mesures

37. 37
Contre-mesures
Comment détecter/bloquer BtleJuice ?
• Conserver les connexions BLE actives seulement le temps de
communiquer.
• Détection par timing : si une opération d’écriture ou de
lecture prend plus de temps que nécessaire ;
• Utiliser de l’appairage Out-of-Band ou via PIN code, ça
contre les attaques MitM et c’est fait pour !
• Utiliser un chiffrement applicatif couplé avec une
authentification forte

38. Conclusion

39. 39
Conclusion
Un outil d’analyse de la sécurité
BtleJuice comme outil d’analyse de la sécurité :
• Pratique pour déterminer le comportement d’un équipement
• Capabke de contourner l’authentification par adresse Bluetooth
(BD)
• Permet l’interception, le remplacement à la volée et le rejeu de
données
• Supporte l’appairage JustWorks

40. 40
Conclusion
Un outil d’attaque
BtleJuice comme outil d’attaque :
• Capable de contourner les restrictions par adresse Bluetooth
(BD)
• Peut être scripté afin d’automatiser des attaques
• Nécessite du matériel rudimentaire, mais deux machines
distinctes
• Quelques contraintes et limitations connues
• Ne contourne pas l’appairage par code PIN ou OOB

41. 41
Conclusion
Améliorations possibles
• Résoudre le problème des 2 machines
• Résoudre le bogue des écritures longues
• Améliorer les interfaces utilisateur et programmatiques
• Tester, tester, tester (on a besoin de vous !)

42. 42
Conclusion
Pour aller plus loin
• « Bluetooth : With Low Energy comes Low Security », Mike
Ryan : https://www.usenix.org/system/files/
conference/woot13/woot13-ryan.pdf
• BT Specifications : https://www.bluetooth.com/
specifications/adopted-specifications
• CrackLE : http://lacklustre.net/projects/crackle/
• GATTacker, Slawomir Jasek : http://www.gattack.io/

43. Questions ?

44. 44
Merci !
Merci de votre attention, merci aux orgas !
(et on recrute : stages/postes, viendez !)
Contact : damien.cauquil@digitalsecurity.fr / @virtualabs