Vulnérabilité d’injection de frappes Bluetooth sur Android, Linux, macOS et iOS
(github.com/skysafe)- CVE-2023-45866 est une vulnérabilité de contournement d’authentification dans les piles Bluetooth de plusieurs systèmes d’exploitation, permettant de connecter un faux clavier et d’injecter des frappes sans confirmation de l’utilisateur
- Un attaquant à proximité peut tenter des actions comme l’installation d’apps, l’exécution de commandes arbitraires ou l’envoi de messages avec seulement un ordinateur Linux et un adaptateur Bluetooth standard, sans matériel spécialisé
- Les conditions d’exploitation varient selon la plateforme : sur Android, l’élément clé est l’activation du Bluetooth ; sur Linux/BlueZ, l’état discoverable/connectable ; sur iOS et macOS, l’appairage d’un Magic Keyboard
- Android 11 à 14 sont atténués par le niveau de correctif de sécurité 2023-12-05, mais Android 4.2.2 à 10 n’ont pas de correctif, et le correctif BlueZ de 2020 était désactivé par défaut
- Les actions nécessitant un mot de passe ou une authentification biométrique ne peuvent pas être réalisées par la seule injection de frappes, mais les appareils non corrigés peuvent rester exposés à des attaques Bluetooth de proximité
Injection de frappes Bluetooth sans authentification
- CVE-2023-45866 est une vulnérabilité permettant l’injection de frappes Bluetooth sans authentification sur Android, Linux, macOS et iOS
- Plusieurs piles Bluetooth permettent un contournement d’authentification par lequel un attaquant peut se connecter à un hôte discoverable sans confirmation de l’utilisateur et injecter des frappes
- Un attaquant à proximité peut établir une connexion Bluetooth non authentifiée avec l’appareil vulnérable et effectuer les actions suivantes via des frappes :
- installation d’apps
- exécution de commandes arbitraires
- envoi de messages
- L’attaque ne nécessite pas de matériel spécialisé et peut être menée avec un ordinateur Linux et un adaptateur Bluetooth standard
- Les détails complets de l’exploit et les scripts PoC doivent être publiés pendant la semaine du ShmooCon, du 12 au 14 janvier
Conditions d’attaque selon la plateforme
- La vulnérabilité fonctionne en trompant la machine d’état de l’hôte Bluetooth pour lui faire appairer un faux clavier sans confirmation de l’utilisateur
- Le mécanisme d’appairage sans authentification sous-jacent existe dans la spécification Bluetooth, et des bugs d’implémentation l’exposent comme surface d’attaque
- Les conditions requises sur un appareil non corrigé varient selon le système d’exploitation
- Android : vulnérable si le Bluetooth est activé
- Linux/BlueZ : le Bluetooth doit être en état discoverable/connectable
- iOS et macOS : vulnérables si le Bluetooth est activé et qu’un Magic Keyboard est appairé avec le téléphone ou l’ordinateur
- Une fois l’appairage effectué avec le téléphone ou l’ordinateur ciblé, l’attaquant peut injecter des frappes avec les privilèges de la victime
- Les actions nécessitant un mot de passe ou une authentification biométrique ne peuvent pas être effectuées par la seule injection de frappes
Une ancienne vulnérabilité mise en lumière après MouseJack
- L’étude MouseJack, publiée en 2016, visait des protocoles radio propriétaires de périphériques, et non le Bluetooth
- Cette nouvelle recherche a commencé en examinant le Bluetooth et l’écosystème Apple autour de l’Apple Magic Keyboard
- Sur macOS et iOS, une injection de frappes Bluetooth sans authentification a été découverte, et l’exploitation restait possible sur les deux plateformes même en Lockdown Mode
- Ensuite, des vulnérabilités similaires ont été confirmées sur Linux et Android, ce qui laissait penser à un défaut proche d’un problème de protocole plus qu’à un simple bug d’implémentation ; l’examen de la spécification Bluetooth HID a montré qu’il s’agissait des deux
- Certaines vulnérabilités sont plus anciennes que MouseJack, et l’injection de frappes a pu être reproduite jusqu’à Android 4.2.2
Impact sur Android et état des correctifs
- Les appareils et versions Android confirmés comme vulnérables lors des tests sont les suivants
- Pixel 7, Android 14
- Pixel 6, Android 13
- Pixel 4a (5G), Android 13
- Pixel 2, Android 11
- Pixel 2, Android 10
- Nexus 5, Android 6.0.1
- BLU DASH 3.5, Android 4.2.2
- Le niveau de correctif de sécurité 2023-12-05 atténue la vulnérabilité sur Android 11 à 14
- Aucun correctif n’est disponible pour Android 4.2.2 à 10
- Le calendrier de divulgation est le suivant
- 2023-08-05 : signalement de la vulnérabilité à Google
- 2023-12-06 : divulgation publique
- Google indique qu’un correctif pour le problème affectant Android 11 à 14 a été fourni aux OEM concernés et que tous les appareils Pixel encore pris en charge sont corrigés via la mise à jour OTA de décembre
Impact sur Linux/BlueZ et correctifs
- Les versions d’Ubuntu confirmées comme vulnérables lors des tests sont 18.04, 20.04, 22.04 et 23.10
- Selon Google, ChromeOS n’est pas vulnérable ; sans avoir été testé directement, sa configuration BlueZ semble atténuer la vulnérabilité
- La vulnérabilité Linux a été corrigée en 2020 sous CVE-2020-0556, mais ce correctif était désactivé par défaut
- ChromeOS est connu comme le seul OS basé sur Linux à avoir activé ce correctif
- Le correctif BlueZ pour CVE-2023-45866 active par défaut le correctif de 2020
- Correctif BlueZ associé :
- Informations Ubuntu :
- Informations Debian :
- Informations Fedora :
- Le calendrier de divulgation est le suivant
- 2023-08-10 : signalement de la vulnérabilité à Canonical
- 2023-09-25 : signalement de la vulnérabilité au Bluetooth SIG
- 2023-10-02 : ouverture d’un dossier auprès du CERT/CC
- 2023-12-06 : divulgation publique
Impact sur macOS et iOS
- Les appareils testés sur macOS et confirmés comme vulnérables sont les suivants
- MacBook Pro 2022, macOS 13.3.3, M2
- MacBook Air 2017, macOS 12.6.7, Intel
- Le Lockdown Mode de macOS ne bloque pas l’attaque
- macOS Sonoma 14.2 corrige la vulnérabilité
- Le calendrier de divulgation pour macOS est le suivant
- 2023-08-01 : signalement de la vulnérabilité à Apple
- 2023-12-06 : divulgation publique
- Sur iOS, l’appareil testé et confirmé comme vulnérable est un iPhone SE exécutant iOS 16.6
- Le Lockdown Mode d’iOS ne bloque pas non plus l’attaque
- Le calendrier de divulgation pour iOS est le suivant
- 2023-08-04 : signalement de la vulnérabilité à Apple
- 2023-12-06 : divulgation publique
1 commentaires
Avis sur Hacker News
J’ai dû faire quelques recherches pour vérifier ça, mais pour rester en sécurité, sur Android il vaut mieux désactiver le Bluetooth quand on ne l’utilise pas. En revanche, on reste vulnérable pendant qu’on l’utilise.
Mon Pixel a reçu la mise à jour de sécurité du 05/12/2023 et ce problème y est corrigé, mais je ne sais pas trop pour les appareils qui ne sont pas des Pixel.
Sous Linux, il faut ouvrir
/etc/bluetooth/input.confet définirClassicBondedOnly=true. Dans mon cas, je n’ai pas eu besoin de l’ajouter, il a suffi de décommenter la ligne. Dans la prochaine version debluetoothd, la valeur par défaut devrait passer àtrue, mais on peut déjà la définir soi-même dès maintenant, puis redémarrer le service Bluetooth.Pour macOS ou iOS, je ne sais pas, je n’ai pas ces appareils.
Le Wi-Fi aussi est dans un état façon gruyère : on ne peut pas l’éteindre complètement depuis le Centre de contrôle.
truedepuis le 7 décembre.$ rpm -q --changelog bluez | grep CVE-2023-45866 -C1* Thu Dec 07 2023 Peter Robinson - 5.70-4- Add mitigation for CVE-2023-45866Après être passé d’Android à iOS, j’ai essayé pendant un moment, puis j’ai fini par abandonner.
Si on verrouille activement son téléphone quand on ne l’utilise pas, et que les frappes envoyées pendant qu’on l’utilise apparaissent à l’écran, garder le Bluetooth activé ne me paraît pas si catastrophique.
Si GrapheneOS l’a corrigé, ce serait enfin une bonne raison de passer dessus, mais comme mon téléphone actuel fonctionne très bien, il est difficile de justifier l’achat d’un nouveau.
Je suis intrigué par l’absence totale de mention de Windows. À première vue, ça ressemble à une bonne nouvelle, mais il faudrait savoir pourquoi Windows n’est effectivement pas affecté pour pouvoir évaluer le risque.
Par exemple, si la pile Bluetooth de Windows possède une structure équivalente au
ClassicBondedOnly=falsede BlueZ, on pourrait en conclure que, dans les environnements à durcir, il faut surveiller que cette valeur soit àtrue.Ou alors la pile fonctionne de manière complètement différente, et les points à prendre en compte sont eux aussi totalement différents.
J’attends avec intérêt la vidéo avec le PoC et beaucoup de démos, mais Windows a une grosse part de marché et de nombreux administrateurs système risquent d’être pris au dépourvu, donc ce serait utile d’avoir des infos. Même « nous n’avons pas encore essayé d’attaquer Windows » serait une information utile.
Mais si on crée un périphérique Bluetooth avec un Flipper Zero, dès qu’un client Windows s’y connecte, il le reconnaît comme un clavier et on peut lui faire exécuter les commandes PowerShell souhaitées. Personnellement, je ne l’ai utilisé que pour ouvrir YouTube et faire un RickRoll, je n’ai rien tenté d’illégal.
Désormais, j’ai désactivé tout le Bluetooth, mais je ne sais pas comment supprimer bluez sans casser Linux.
ClassicBondedOnly=falsede BlueZ ; tu voulais peut-être direClassicBondedOnly=true?Maintenant que l’industrie a supprimé les connexions audio physiques des téléphones et poussé tout le monde vers le sans-fil, c’est vraiment réjouissant de voir ce genre de nouvelle. Bravo.
[1] https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/pr...
Cette vulnérabilité fonctionne en trompant la machine à états de l’hôte Bluetooth pour l’amener à s’appairer avec un faux clavier sans validation de l’utilisateur. Le mécanisme sous-jacent d’appairage sans authentification est défini dans la spécification Bluetooth, et des bugs propres aux implémentations l’exposent à l’attaquant.
Mais pourquoi avoir voulu permettre un appairage silencieux ? J’aimerais en savoir plus sur l’objectif prévu du mécanisme en cause.
En pratique, je ne sais pas pourquoi les appareils affectés étaient configurés ainsi.
Ce problème a été corrigé dans macOS 14.2 et iOS 17.2.
https://support.apple.com/en-us/HT214036
https://support.apple.com/en-us/HT214035
Sur Arch Linux, c’est corrigé depuis bluez 5.70-2 [1]
[1]: https://gitlab.archlinux.org/archlinux/packaging/packages/bl...
Le passage où il dit qu’« à l’époque, Bluetooth était intimidant, donc j’ai simplement supposé que c’était sûr » résonne particulièrement. On dirait que cette mythologie selon laquelle, quelque part au-dessus d’une pile technique complexe, il y aurait des gens qui savent vraiment ce qu’ils font, et que le château n’est pas construit sur du sable et soutenu par des bâtons, naît justement de cette impression d’intimidation.
Je doute que ce soit très pratique contre un téléphone ou un ordinateur, mais si l’on est chargé d’empêcher quiconque de toucher à un kiosque, la vie vient de devenir un peu plus intéressante.
Il suffit de réussir à installer une seule backdoor pour pouvoir travailler ensuite.
Dans le cas d’une attaque ciblée, envoyer une pression sur la touche Maj toutes les minutes pour empêcher le verrouillage de l’écran, puis venir plus tard physiquement devant la machine pour faire quelque chose, pourrait suffire.
sudoou unsuempoisonné et de l’ajouter au$PATH.L’USB, c’est pareil. Si l’on branche un clavier sur un port « charge uniquement », il fonctionne. Je l’ai testé directement sur Android, et on m’a réprimandé ici en me disant que ce n’était pas exploitable en pratique.
Cela dit, je ne considère pas ça comme une vulnérabilité. C’est simplement une fonctionnalité utile. Le problème ici, c’est que quelqu’un peut le faire sans que l’utilisateur s’en rende compte, même pendant des opérations sensibles.
Le chouette projet publié hier, https://mitxela.com/projects/smsc, pouvait lui aussi être utilisé de cette façon avec un téléphone.
La vulnérabilité Linux a été corrigée en 2020 (CVE-2020-0556), mais le correctif est resté désactivé par défaut. Seul ChromeOS est connu pour l’avoir activé, même si Ubuntu, Debian, Fedora, Gentoo, Arch et Alpine avaient publié des avis.
Mais si l’avis de la distribution dit qu’une simple mise à niveau corrige le problème[2], je ne comprends pas ce que signifie « le correctif était désactivé par défaut ». Cela veut-il dire qu’après la mise à niveau, il faut encore modifier la configuration manuellement ? Le correctif NixOS semble inverser la valeur par défaut.
Si cela veut dire que les utilisateurs qui ont explicitement défini
ClassicBondedOnly=falsedoivent le changer, cela aurait pu être formulé beaucoup plus clairement.[1] https://github.com/NixOS/nixpkgs/blob/3dda6d5ed56af34534dd4c...
[2] https://ubuntu.com/security/notices/USN-4311-1