xg3nesis/rustyinjectorImplémentation en Rust de la preuve de concept d'injection de frappes de Marc Newlin (CVE-2023-45866).
⚠️ Avertissement : À des fins de recherche et d'éducation uniquement
Ce projet est une Preuve de Concept (PoC) démontrant l'injection de frappes Bluetooth, réimplémentée en Rust. Il est destiné strictement à des fins éducatives et de recherche en sécurité.
En téléchargeant, clonant ou utilisant ce code, vous acceptez de l'utiliser de manière responsable et en conformité avec toutes les lois et réglementations applicables.
Bienvenue sur Rusty Injector — une implémentation en Rust inspirée de la Preuve de Concept d'injection de frappes Bluetooth de Marc Newlin, liée aux CVE-2023-45866, CVE-2024-21306 et CVE-2024-0230.
Actuellement, ce dépôt n'implémente que CVE-2023-45866, qui exploite les vulnérabilités d'injection de frappes dans BlueZ sur le système d'exploitation Linux.
Ci-dessous une capture d'écran de la description du NIST, incluant le score CVSS :
Capture 1 : Description NIST de CVE-2023-45866.
Les autres CVE, CVE-2024-21306 et CVE-2024-0230, ne sont pas prévues pour être implémentées par moi-même, mais les contributions sont chaleureusement bienvenues.
Avant d'entrer dans les détails, je vous encourage à regarder la présentation de Marc Newlin à la conférence NullCon 2024, car elle offre une explication claire et approfondie de ces vulnérabilités : Hi, My Name Is keyboard par Marc Newlin..
J'ai également mis à disposition une vidéo qui vulgarise cette vulnérabilité. Vous la trouverez ici : Comment un simple hack Bluetooth peut pirater votre appareil - Hi, my name is keyboard.
📌 Si vous remarquez des points manquants, des domaines qui pourraient être mieux simplifiés, ou des erreurs potentielles dans l'explication ci-dessous, n'hésitez pas à la modifier et à soumettre une demande de fusion. Je serais ravi d'examiner vos contributions et de les intégrer dans le dépôt.
Comme nous n'avons couvert que la vulnérabilité CVE-2023-45866 concernant les systèmes d'exploitation Linux, nous expliquerons uniquement le processus pour parvenir à cette exploitation spécifique ciblant la bibliothèque BlueZ.
Tout d'abord, vous devez comprendre que cette vulnérabilité n'est exploitable que sur Bluetooth BR/EDR car elle cible le profil HID reposant sur cette technologie. Vous savez peut-être que l'implémentation architecturale Bluetooth est divisée en plusieurs couches, comme le modèle OSI pour le protocole Ethernet, comme vous pouvez l'observer sur notre schéma ci-dessous.
Diagramme 1 : Pile Bluetooth BR/EDR (Basic Rate - Enhanced Data Rate) simplifiée. La couche la plus basse de la pile représente la couche physique avec une antenne dédiée, et le niveau le plus élevé représente le niveau applicatif ou ce que l'on peut parfois désigner comme le système d'exploitation. Lorsque deux appareils souhaitent communiquer entre eux, ils traversent ces différentes couches : de haut en bas pour les paquets sortants et de bas en haut pour les paquets Bluetooth entrants.
Après le processus d'inquiry, une fois que les appareils déterminent qu'ils souhaitent établir une connexion, ils procèdent au processus d'appairage. Ce processus permet l'authentification mutuelle entre les appareils et l'établissement d'une clé de chiffrement, utilisée ensuite pour sécuriser la communication.
La spécification Bluetooth offre différents niveaux d'authentification et de sécurité. Selon le mécanisme utilisé pour l'authentification, le niveau de sécurité de la communication peut varier. Les appareils peuvent s'authentifier en fonction des périphériques d'entrée et de sortie qu'ils possèdent, un concept appelé modèles d'association. Vous avez probablement déjà rencontré cela lors de l'appairage de deux appareils—par exemple, lorsqu'on vous demande de saisir un code PIN affiché sur l'autre appareil.
Il existe quatre modèles d'association d'appairage, déterminés par les capacités d'E/S (Entrée/Sortie) des appareils :
Voici un tableau montrant quel modèle d'association est utilisé en fonction des capacités de nos appareils IoT.
Diagramme 2 : Tableau illustrant les modèles d'association Bluetooth BR/EDR inspiré de la spécification Bluetooth Core v5.3 - 2.3.5.1 Selecting key generation method Table 2.8 : Mapping of IO capabilities to key generation method (page 1573). Pour plus d'informations sur les modes de sécurité et les modèles d'association, consultez cet intéressant article de blog publié par Thyrasec : Bluetooth Security : Classic & BLE !
Je suis sûr que vous êtes intrigué par la méthode 'Just Works', qui est précisément là où se trouve notre vulnérabilité. Voici le problème : cette méthode établit l'appairage sans nécessiter de confirmation ou d'interaction de l'utilisateur, ne laissant aucun moyen de vérifier l'authenticité de l'appareil d'appairage. Sur les systèmes Linux, la pile BlueZ, par défaut, acceptait les demandes d'appairage entrantes d'appareils classés comme NoInputNoOutput (pour assurer la rétrocompatibilité). Un choix de conception vraiment "merveilleux", n'est-ce pas ?
Capture 2 : Mise à jour de la configuration par défaut de BlueZ pour activer la sécurité Bluetooth et corriger CVE-2023-45866.
