Preuve de concept des vulnérabilités Sweyntooth Bluetooth Low Energy (BLE).
Ce dépôt fait partie des résultats de recherche du ASSET Research Group.
SweynTooth regroupe une famille de 18 vulnérabilités dans différents kits de développement logiciels (SDK) Bluetooth Low Energy (BLE) de six grands fournisseurs de systèmes sur puce (SoC). Ces vulnérabilités exposent des défauts dans des implémentations BLE SoC spécifiques qui permettent à un attaquant à portée radio de déclencher des interblocages, des crashs et des dépassements de tampon ou de contourner complètement la sécurité selon les circonstances. (Mise à jour) Nous avons également inclus un script de test pour vérifier les appareils contre la variante BLE KNOB.
Vous pouvez trouver plus d'informations sur les vulnérabilités, les correctifs disponibles et les appareils concernés sur le site de divulgation SweynTooth de l'ASSET Research Group.
Fitbit, August Smart Lock, Eve Energy, CubiTag ainsi que d'autres objets « intelligents » sont concernés.
Ce PoC utilise des bibliothèques bien maintenues telles que Scapy et Colorama. La construction et l'analyse des paquets BLE sont réalisées via des couches de protocole Scapy personnalisées (bluetooth4LE et bluetooth.py). Une fusion est en cours pour inclure nos ajouts dans le dépôt principal de Scapy.
Tout d'abord, vous devez vous assurer d'avoir Python2.7 sur votre système ainsi que les paquets Python listés dans le fichier requirements.txt.
Si vous utilisez Ubuntu, exécutez les commandes suivantes :
sudo apt-get install python2.7
sudo pip install -r requirements.txt
Ensuite, SweynTooth utilise le Dongle Nordic nRF52840 pour envoyer/recevoir des paquets bruts de la couche de liaison vers et depuis le périphérique vulnérable par radio. Il est nécessaire de flasher le firmware du pilote sur la carte avant de lancer les scripts Python 2.7.
Le binaire de notre code firmware se trouve dans le fichier nRF52_driver_firmware.zip. Vous devez installer l'outil nrfutil pour flasher le firmware sur la carte. N'oubliez pas de mettre le nRF52840 en mode DFU avant de flasher (réinitialisez la clé USB pendant qu'elle est connectée à votre PC en appuyant sur le petit bouton de réinitialisation).
Vous pouvez exécuter les commandes suivantes pour installer les dépendances Python et flasher le firmware :
python -m pip install nrfutil pyserial pycryptodome
nrfutil dfu usb-serial -p COM_PORT -pkg nRF52_driver_firmware.zip
Les scripts fonctionnent sur Linux ou Windows. Il vous suffit de modifier le paramètre COM_PORT pour qu'il corresponde au nom du port du nRF52840.
Si la méthode de flashage précédente n'a pas fonctionné, vous pouvez également flasher le firmware à l'aide de l'application nRF Connect for Desktop, qui offre une interface agréable pour flasher le firmware hex (nRF52_driver_firmware.hex).
Une fois les prérequis installés, vous pouvez exécuter un script d'exploitation en lançant la commande suivante :
python Telink_key_size_overflow.py COM7 A4:C1:38:D8:AD:A9
Le premier argument est le nom du port série (généralement /dev/ttyACM0 sous Linux) et le second est l'adresse du périphérique BLE vulnérable. Vous pouvez utiliser n'importe quel scanner BLE ou l'application nRF Connect pour découvrir cette adresse.
En prenant l'exemple de la vulnérabilité Key Size Overflow, le script produit la sortie suivante si le périphérique vulnérable se bloque après le crash :
Si vous souhaitez utiliser SweynTooth via une image Docker pour éviter d'installer les dépendances Python, vous pouvez utiliser le script d'assistance docker.sh pour construire et exécuter l'instance Docker, ou télécharger l'image Docker préconstruite (lien) disponible sur la page des releases. L'utilisation de docker.sh est décrite ci-dessous.
--------- HELP -------------
sudo ./docker run <script_name> <serial_port> <ble_target_address> - Start any sweyntooth script by its name (<script_name>)
sudo ./docker build - Build docker container
sudo ./docker build release - Build docker container and create compressed image for release
sudo ./docker shell - Start docker container shell
---------- EXAMPLE ----------
./docker.sh run extras/Microchip_and_others_non_compliant_connection.py /dev/ttyACM0 f0:f8:f2:da:09:63
Chaque script d'exploitation correspond à une faille. Le tableau récapitulatif suivant montre la correspondance entre la vulnérabilité et le script permettant de l'exploiter sur les SoC concernés.
En général, les produits utilisant les SoC concernés disposent d'un chien de garde (watchdog) qui redémarre automatiquement le SoC BLE en cas de défaut. Par conséquent, tous les produits ne peuvent pas être bloqués. Néanmoins, il devrait être possible d'obtenir une indication visuelle ou sonore du produit si celui-ci plante et redémarre.
La vulnérabilité SweynTooth la plus critique est l'installation d'une LTK nulle (Zero LTK Installation), qui permet à un attaquant de contourner complètement la dernière procédure d'appairage Bluetooth (connexions sécurisées) en forçant une procédure de configuration de chiffrement avec une LTK remplie de zéros. Pour tester votre appareil contre cette vulnérabilité, l'appareil doit accepter ou prendre en charge les connexions sécurisées comme méthode d'appairage. Vous pouvez exécuter la preuve de concept comme suit :
python Telink_zero_ltk_installation.py COM7 A4:C1:38:D8:AD:A9
Notez que les arguments COM7 et A4:C1:38:D8:AD:A9 diffèrent selon votre configuration. Si l'appareil est vulnérable, la preuve de concept affiche ce qui suit :
Le script LLID Deadlock efface le champ LLID lors de l'envoi de demandes de version ou de demandes d'appairage de manière alternative à chaque reconnexion avec le périphérique. Cela est fait pour déclencher la vulnérabilité sur les SoC vulnérables de NXP et Cypress. Lors de l'exécution du script contre le KW41Z vulnérable, la pile est bloquée et est censée envoyer des paquets de couche de liaison hors séquence. Le script tente de détecter quand la pile est bloquée et affiche la sortie suivante pour les appareils KW41Z vulnérables :
Les appareils Cypress vulnérables désactivent généralement leurs publicités après l'attaque. Vous devriez donc voir un message d'erreur indiquant qu'un crash a été détecté. En testant ce script contre une Fitbit Inspire vulnérable, la montre connectée soit plante immédiatement, soit désactive temporairement ses publicités. Des attaques intermittentes contre cet appareil devraient provoquer un dysfonctionnement BLE permanent, obligeant l'utilisateur à redémarrer manuellement la Fitbit Inspire.
Bien que KNOB ait principalement affecté les appareils Bluetooth Classic en raison de la réduction de la taille de la clé à 1 octet, il est toujours possible de réduire l'entropie de la clé des appareils Bluetooth Low Energy à 7 octets (taille de clé minimale conforme) pendant la procédure d'appairage SMP. L'implication d'une telle réduction d'entropie BLE conforme a été discutée dans "Low Entropy Key Negotiation Attacks on Bluetooth and Bluetooth Low Energy" by Antonioli, Daniele et. al.
Nous avons mis à disposition un script simple pour vérifier quelles tailles de clé sont acceptables par un périphérique BLE. Vous pouvez exécuter le testeur BLE KNOB comme suit :
# Windows
python extras\knob_tester_ble.py COM6 a4:c1:38:d8:ad:a9
# Linux
python extras/knob_tester_ble.py /dev/ttyACM0 a4:c1:38:d8:ad:a9
N'oubliez pas de remplacer COM6 et a4:c1:38:d8:ad:a9 par d'autres valeurs en fonction du port série du dongle nRF52 (généralement /dev/ttyACM0 sous Linux) et de l'adresse du périphérique BLE testé. Si l'outil détecte que le périphérique accepte des tailles de clé autres que 16 octets, il les listera comme indiqué ci-dessous :
Le dossier captures contient quelques exemples de captures pour chaque vulnérabilité. Nous avons également ajouté certains cas de non-conformité détectés dans certains SoC.
Le dossier extras contient d'autres scripts liés aux non-conformités et à certaines variantes de SweynTooth. Consultez le tableau des scripts extras dans extras/README.md pour plus d'informations.
Cette recherche a été partiellement soutenue par Keysight Technologies.
| Vulnérabilité | CVE(s) | Vendeur | Fichier de script |
|---|