Whisper Bully

Strumento di ricerca per Estrazione BDADDR Bluetooth, Denial-of-Service e Hijack

© 2026 @Ymsniper — Solo per ricerca di sicurezza autorizzata.

Panoramica

Whisper Bully è uno strumento di ricerca sulla sicurezza Bluetooth in tre fasi che prende di mira i dispositivi che pubblicizzano Google Fast Pair (UUID del servizio fe2c). Dimostra due primitive d'attacco non corrette che sono al di fuori dell'ambito della patch del firmware CVE-2025-36911:

Leak BDADDR non corretto — indirizzo di identità permanente divulgato tramite semplice connessione BLE, nessuna interazione GATT richiesta, funziona su dispositivi completamente patchati
Bypass dell'autenticazione SMP tramite finestra di reset — bond persistente stabilito tramite SMP Just Works standard durante il ripristino dello stack BT dopo L2CAP flood, senza alcun handshake GATT Fast Pair

⚠️ Questo strumento NON implementa il protocollo Whisper Pair (Fast Pair GATT). Non scrive mai sulla caratteristica Key-Based Pairing (UUID 1236) né sulla caratteristica Account Key (UUID 1238). La superficie d'attacco descritta qui è separata dalla patch del controllo della modalità di pairing CVE-2025-36911 e non viene da essa affrontata.

https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11

Fasi dell'Attacco

Fase 1 — Estrazione BDADDR (Divulgazione di Informazioni Non Corretta)

Causa principale: Quando viene stabilita una connessione BLE, lo stack host Linux BlueZ elabora l'evento LL_CONNECTION_COMPLETE e risolve l'indirizzo privato risolvibile (RPA) del dispositivo nel suo indirizzo di identità permanente, memorizzandolo nella tabella dei dispositivi di BlueZ. Ciò avviene a livello di Link Layer / HCI, prima di qualsiasi interazione con i servizi GATT. Non è coinvolto alcun protocollo Fast Pair.

Cosa fa realmente il codice:

Esegue una scansione BLE attiva (BleakScanner) per i dispositivi che pubblicizzano l'UUID del servizio Fast Pair fe2c — utilizzata solo per l'identificazione del target, nessuna interazione con il protocollo
Stabilisce una semplice connessione BLE tramite BleakClient.connect() — nessuna scrittura GATT di alcun tipo
Imposta l'agente BlueZ su NoInputNoOutput in preparazione al passaggio 4
Verifica se il servizio GATT Fast Pair è presente sul target — questo controllo è solo indicativo; lo strumento continua indipendentemente dal risultato (riga 452 di wb.py)
Esegue bluetoothctl pair <rpa_addr> — tentativo di pairing SMP Bluetooth standard, non Fast Pair
Monitora l'output di bluetoothctl per il risultato Bonded: yes, che può contenere l'indirizzo associato
Fallback principale: Chiama bluetoothctl devices e confronta con l'RPA iniziale — qualsiasi voce con lo stesso nome dispositivo ma indirizzo diverso è l'indirizzo di identità permanente, divulgato da BlueZ al passaggio 2

Perché la patch non risolve questo problema:

La correzione firmware CVE-2025-36911 aggiunge un controllo della modalità di pairing al gestore della caratteristica GATT Key-Based Pairing Fast Pair sull'accessorio. Questo strumento non scrive mai su quella caratteristica. Il leak dell'indirizzo di identità avviene sull'host Linux dell'attaccante tramite la cache dei dispositivi di BlueZ — completamente al di fuori del firmware dell'accessorio.

Note chiave sul comportamento:

L'estrazione può riuscire anche se il passaggio bluetoothctl pair fallisce o va in timeout
Il controllo della presenza del servizio GATT FP al passaggio 4 non blocca l'attacco
Non appare alcuna finestra di conferma PIN — NoInputNoOutput significa nessuna interazione utente su entrambi i lati per Just Works

Fase 2 — L2CAP Flooding (Modalità EMP Burst-Reconnect)

Una volta noto l'indirizzo permanente, è possibile eseguire facoltativamente un denial-of-service L2CAP sostenuto utilizzando una versione modificata di l2flood.

Due modalità sono utilizzate nello strumento:

Flag -R — modalità EMP (flood Fase 2) Burst-reconnect silenzioso fire-and-forget. Tutti i thread sincronizzano i loro cicli connect → burst → forced close così che il target riceva periodici teardown ACL completi piuttosto che un rimescolamento scaglionato dei canali L2CAP che può assorbire. Usa SO_LINGER {1,0} per un immediato teardown RST a ogni chiusura. Non produce output stdout durante il normale funzionamento — gli errori di connessione sono soppressi su stderr e stampati solo periodicamente.

Modalità normale (sonda hijack Fase 3) Usata senza -R per verificare se il target risponde ancora. Anche questa modalità è stata migliorata — ora gestisce automaticamente le riconnessioni e mostra no response from <addr>: id N quando il target smette di rispondere, che è ciò che wb.py monitora per attivare l'hijack.

Risultato: Il dispositivo target diventa non reattivo ai normali tentativi di connessione mentre il flood è attivo. Il dispositivo si riprende completamente quando l'attacco si ferma — nessun danno permanente.

Comportamento multithread:

I thread si sincronizzano dopo ogni ciclo di burst così che la pressione colpisca il target simultaneamente
Efficace fino a ~16 thread su hardware tipico; rendimenti decrescenti oltre
È possibile utilizzare più adattatori HCI contemporaneamente per aumentare la pressione

Fase 3 — Hijack tramite SMP Just Works Durante la Finestra di Reset (Auth Bypass Non Corretto)

Causa principale: Il flood L2CAP sostenuto causa il crash o il reset dello stack Bluetooth del dispositivo target. Durante la finestra di ripristino — prima che il servizio GATT Fast Pair si sia ri-registrato e prima che il Security Manager si sia completamente reinizializzato — il dispositivo accetta un bond SMP Just Works standard da NoInputNoOutput senza richiedere l'handshake GATT Fast Pair che normalmente vincolerebbe il bond. Il bond risultante è persistente: sopravvive ai reset dell'adattatore BT e mostra Paired: yes / Bonded: yes in bluetoothctl info.

Perché questo è un risultato separato da CVE-2025-36911:

La patch CVE-2025-36911 impone un controllo della modalità di pairing nel gestore della caratteristica GATT Key-Based Pairing FP. La Fase 3 non tocca mai quella caratteristica. Il bond viene stabilito a livello SMP durante una finestra in cui il server GATT FP non si è reinizializzato, quindi il gate di sicurezza Fast Pair non viene mai nemmeno raggiunto. Un dispositivo completamente patchato rimane vulnerabile a questo perché la patch non ha visibilità sul livello SMP durante il ripristino dello stack.

Cosa fa realmente il codice:

Invia una sonda L2CAP (l2flood -c -1 -t 2) per confermare che il dispositivo non risponde — cerca no response from <addr>: id N nell'output
Una volta confermato lo stato di non risposta, esegue bluetoothctl connect <permanent_addr> in un loop con nuovi tentativi
SMP negozia NoInputNoOutput / NoInputNoOutput → modello di associazione Just Works → il bond si completa
bluetoothctl connect restituisce il codice di uscita 0 in caso di successo
Il bond persiste dopo che l'attacco si ferma

Probabilità di successo in base allo stato del dispositivo:

Stato del Dispositivo	Risultato Atteso
Attivamente in flood / non risponde	Successo più alto — stack in stato degradato durante il ripristino
In ripristino dal flood	Successo alto — finestra temporanea di re-init di SM
Completamente ripristinato	Successo più basso — sicurezza normale ripristinata
Spento	Fallisce

Whisper_Bully

Più Popolari