ymsniper/whisper_bullyExtraction de BDADDR Bluetooth en trois étapes, DoS et détournement sur les appareils Fast Pair ; primitives non corrigées hors du périmètre de CVE-2025-36911 (aucun Ubertooth requis)
Outil de recherche sur l'extraction BDADDR Bluetooth, le déni de service et le détournement
© 2026 @Ymsniper — Pour la recherche en sécurité autorisée uniquement.
Whisper Bully est un outil de recherche en sécurité Bluetooth en trois étapes qui cible les appareils annonçant Google Fast Pair (UUID de service fe2c). Il démontre deux primitives d'attaque non corrigées qui sont hors du périmètre du correctif firmware CVE-2025-36911 :
⚠️ Cet outil n'implémente PAS le protocole Whisper Pair (GATT Fast Pair). Il n'écrit jamais sur la caractéristique Key-Based Pairing (UUID 1236) ni sur la caractéristique Account Key (UUID 1238). La surface d'attaque décrite ici est distincte du correctif de vérification du mode d'appairage CVE-2025-36911 et n'est pas traitée par celui-ci.
https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11
Cause racine : Lorsqu'une connexion BLE est établie, la pile hôte BlueZ de Linux traite l'événement LL_CONNECTION_COMPLETE et résout l'adresse privée résoluble (RPA) de l'appareil vers son adresse d'identité permanente, en la mettant en cache dans la table des appareils BlueZ. Cela se produit au niveau de la couche liaison / HCI, avant toute interaction avec les services GATT. Aucun protocole Fast Pair n'est impliqué.
Ce que fait réellement le code :
BleakScanner) pour les appareils annonçant l'UUID de service Fast Pair fe2c — utilisé uniquement pour l'identification des cibles, aucune interaction protocolaireBleakClient.connect() — aucune écriture GATT d'aucune sorteNoInputNoOutput en préparation de l'étape 4wb.py)bluetoothctl pair <rpa_addr> — tentative d'appairage SMP Bluetooth standard, pas Fast Pairbluetoothctl pour la sortie Bonded: yes, qui peut contenir l'adresse liéebluetoothctl devices et compare avec la RPA initiale — toute entrée avec le même nom d'appareil mais une adresse différente est l'adresse d'identité permanente, divulguée par BlueZ à l'étape 2Pourquoi le correctif ne résout pas ce problème :
Le correctif firmware CVE-2025-36911 ajoute une vérification du mode d'appairage au gestionnaire de la caractéristique GATT Key-Based Pairing Fast Pair sur l'accessoire. Cet outil n'écrit jamais sur cette caractéristique. La fuite d'adresse d'identité se produit sur l'hôte Linux de l'attaquant via le cache d'appareils de BlueZ lui-même — entièrement en dehors du firmware de l'accessoire.
Points clés de comportement :
bluetoothctl pair échoue ou expireNoInputNoOutput signifie aucune interaction utilisateur des deux côtés pour Just WorksUne fois l'adresse permanente connue, exécutez facultativement un déni de service L2CAP soutenu à l'aide d'une version modifiée de l2flood.
Deux modes sont utilisés dans l'outil :
Option -R — mode EMP (flood de l'étape 2)
Reconnexion en rafales silencieuse de type « fire-and-forget ». Tous les threads synchronisent leurs cycles connect → burst → fermeture forcée afin que la cible reçoive des démontages ACL complets périodiques plutôt que des réorganisations de canaux L2CAP échelonnées qu'elle peut absorber. Utilise SO_LINGER {1,0} pour un démontage RST immédiat à chaque fermeture. Ne produit aucune sortie stdout pendant le fonctionnement normal — les erreurs de connexion sont envoyées vers stderr et imprimées périodiquement uniquement.
Mode normal (sonde de détournement de l'étape 3)
Utilisé sans -R pour vérifier si la cible répond encore. Ce mode a également été amélioré — il gère désormais les reconnexions automatiquement et émet no response from <addr>: id N lorsque la cible cesse de répondre, c'est ce que wb.py surveille pour déclencher le détournement.
Résultat : L'appareil cible devient non réactif aux tentatives de connexion normales pendant que le flood est actif. L'appareil récupère complètement lorsque l'attaque s'arrête — aucun dommage permanent.
Comportement multithread :
Cause racine : Le flood L2CAP soutenu provoque le crash ou la réinitialisation de la pile Bluetooth de l'appareil cible. Pendant la fenêtre de récupération — avant que le service GATT Fast Pair ne soit ré-enregistré et avant que le Security Manager ne soit complètement ré-initialisé — l'appareil accepte une liaison SMP Just Works standard de NoInputNoOutput sans exiger la poignée de main GATT Fast Pair qui conditionnerait normalement la liaison. La liaison résultante est persistante : elle survit aux réinitialisations de l'adaptateur BT et affiche Paired: yes / Bonded: yes dans bluetoothctl info.
Pourquoi cette découverte est distincte de CVE-2025-36911 :
Le correctif CVE-2025-36911 impose une vérification du mode d'appairage dans le gestionnaire de la caractéristique GATT Key-Based Pairing FP. L'étape 3 ne touche jamais à cette caractéristique. La liaison est établie au niveau de la couche SMP pendant une fenêtre où le serveur GATT FP ne s'est pas ré-initialisé, donc la barrière de sécurité Fast Pair n'est même jamais atteinte. Un appareil entièrement corrigé reste vulnérable à cette attaque car le correctif n'a aucune visibilité sur la couche SMP pendant la récupération de la pile.
Ce que fait réellement le code :
l2flood -c -1 -t 2) pour confirmer que l'appareil est non réactif — recherche no response from <addr>: id N dans la sortiebluetoothctl connect <permanent_addr> dans une boucle de tentativesNoInputNoOutput / NoInputNoOutput → modèle d'association Just Works → la liaison aboutitbluetoothctl connect renvoie le code de sortie 0 en cas de succèsProbabilité de succès selon l'état de l'appareil :
| État de l'appareil | Résultat attendu |
|---|---|
| Activement en flood / non réactif | Succès le plus élevé — pile dans un état dégradé pendant la récupération |
| En cours de récupération après le flood | Succès élevé — fenêtre temporaire de ré-initialisation du SM |
| Entièrement récupéré | Succès plus faible — sécurité normale rétablie |
| Éteint | Échec |