ymsniper/whisper_bullyDreistufige Bluetooth-BDADDR-Extraktion, DoS & Hijack auf Fast-Pair-Geräten; ungepatchte Primitive außerhalb des CVE-2025-36911-Bereichs (kein Ubertooth erforderlich)
Bluetooth-BDADDR-Extraktion, Denial-of-Service & Hijack-Forschungswerkzeug
© 2026 @Ymsniper — Nur für autorisierte Sicherheitsforschung.
Whisper Bully ist ein dreistufiges Bluetooth-Sicherheitsforschungswerkzeug, das Geräte anvisiert, die Google Fast Pair (Dienst-UUID fe2c) bewerben. Es demonstriert zwei ungepatchte Angriffsprimitive, die außerhalb des Anwendungsbereichs des CVE-2025-36911-Firmware-Patches liegen:
⚠️ Dieses Werkzeug implementiert NICHT das Whisper Pair (Fast Pair GATT)-Protokoll. Es schreibt nie auf die Key-Based Pairing-Charakteristik (UUID 1236) oder Account-Key-Charakteristik (UUID 1238). Die hier beschriebene Angriffsfläche ist getrennt von und nicht adressiert durch den CVE-2025-36911-Pairing-Mode-Check-Patch.
https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11
Grundursache: Wenn eine BLE-Verbindung hergestellt wird, verarbeitet der Linux-BlueZ-Host-Stack das LL_CONNECTION_COMPLETE-Ereignis und löst die auflösbare private Adresse (RPA) des Geräts in seine permanente Identitätsadresse auf, die er in der BlueZ-Gerätetabelle zwischenspeichert. Dies geschieht auf der Link-Layer-/HCI-Ebene, bevor eine GATT-Dienstinteraktion stattfindet. Kein Fast-Pair-Protokoll ist beteiligt.
Was der Code tatsächlich tut:
BleakScanner) nach Geräten durch, die die Fast-Pair-Dienst-UUID fe2c bewerben – wird nur zur Zielidentifikation verwendet, keine ProtokollinteraktionBleakClient.connect() her – keine GATT-Schreibvorgänge jeglicher ArtNoInputNoOutput als Vorbereitung für Schritt 4wb.py)bluetoothctl pair <rpa_addr> aus – Standard-Bluetooth-SMP-Pairing-Versuch, nicht Fast Pairbluetoothctl auf die Ausgabe Bonded: yes, die die gebondete Adresse enthalten kannbluetoothctl devices auf und vergleicht mit der ursprünglichen RPA – jeder Eintrag mit demselben Gerätenamen, aber einer anderen Adresse, ist die permanente Identitätsadresse, die in Schritt 2 von BlueZ preisgegeben wurdeWarum der Patch dies nicht behebt:
Der CVE-2025-36911-Firmware-Fix fügt eine Pairing-Mode-Prüfung zum Fast-Pair-GATT-Key-Based-Pairing-Charakteristik-Handler auf dem Zubehör hinzu. Dieses Werkzeug schreibt nie auf diese Charakteristik. Der Identitätsadressen-Leak tritt auf dem Linux-Host des Angreifers über den eigenen BlueZ-Geräte-Cache auf – vollständig außerhalb der Firmware des Zubehörs.
Wichtige Verhaltenshinweise:
bluetoothctl pair fehlschlägt oder zeitlich ausläuftNoInputNoOutput bedeutet keine Benutzerinteraktion auf beiden Seiten für Just WorksSobald die permanente Adresse bekannt ist, kann optional ein anhaltender L2CAP-Denial-of-Service unter Verwendung einer modifizierten Version von l2flood ausgeführt werden.
Zwei Modi werden im gesamten Werkzeug verwendet:
-R-Flag — EMP-Modus (Stufe 2 Flood)
Stiller Fire-and-Forget-Burst-Reconnect. Alle Threads synchronisieren ihre Connect→Burst→Forced-Close-Zyklen, sodass das Ziel periodisch vollständige ACL-Takedowns erhält, anstatt gestaffeltes L2CAP-Kanal-Shuffling, das es absorbieren könnte. Verwendet SO_LINGER {1,0} für sofortigen RST-Takedown bei jedem Schließen. Erzeugt während des normalen Betriebs keine Ausgabe auf stdout – Verbindungsfehler werden nach stderr unterdrückt und nur periodisch ausgegeben.
Normalmodus (Stufe 3 Hijack-Probe)
Wird ohne -R verwendet, um zu prüfen, ob das Ziel noch antwortet. Dieser Modus wurde ebenfalls verbessert – er behandelt jetzt automatisch Wiederverbindungen und gibt no response from <addr>: id N aus, wenn das Ziel nicht mehr antwortet, was wb.py überwacht, um den Hijack auszulösen.
Ergebnis: Das Zielgerät wird während des aktiven Floods unerreichbar für normale Verbindungsversuche. Das Gerät erholt sich vollständig, wenn der Angriff stoppt – kein dauerhafter Schaden.
Multithread-Verhalten:
Grundursache: Der anhaltende L2CAP-Flood führt dazu, dass der Bluetooth-Stack des Zielgeräts abstürzt oder zurückgesetzt wird. Während des Wiederherstellungsfensters – bevor der Fast-Pair-GATT-Dienst erneut registriert wurde und bevor der Security Manager vollständig neu initialisiert wurde – akzeptiert das Gerät einen standardmäßigen SMP Just Works Bond von NoInputNoOutput, ohne den Fast-Pair-GATT-Handshake zu erfordern, der normalerweise den Bond blockieren würde. Der resultierende Bond ist persistent: Er überlebt BT-Adapter-Resets und zeigt Paired: yes / Bonded: yes in bluetoothctl info an.
Warum dies ein separater Befund von CVE-2025-36911 ist:
Der CVE-2025-36911-Patch erzwingt eine Pairing-Mode-Prüfung im FP-GATT-Key-Based-Pairing-Charakteristik-Handler. Stufe 3 greift nie auf diese Charakteristik zu. Der Bond wird auf der SMP-Ebene während eines Fensters hergestellt, in dem der FP-GATT-Server nicht neu initialisiert wurde, sodass das Fast-Pair-Sicherheitstor nie erreicht wird. Ein vollständig gepatchtes Gerät bleibt dafür anfällig, da der Patch während der Stack-Wiederherstellung keine Sichtbarkeit auf die SMP-Ebene hat.
Was der Code tatsächlich tut:
l2flood -c -1 -t 2), um zu bestätigen, dass das Gerät nicht reagiert – sucht nach no response from <addr>: id N in der Ausgabebluetoothctl connect <permanent_addr> in einer Wiederholungsschleife ausNoInputNoOutput / NoInputNoOutput → Just Works-Assoziationsmodell → Bond wird abgeschlossenbluetoothctl connect gibt bei Erfolg den Exit-Code 0 zurückErfolgswahrscheinlichkeit nach Gerätezustand:
| Gerätezustand | Erwartetes Ergebnis |
|---|---|
| Aktiv im Flood / nicht reagierend | Höchste Erfolgswahrscheinlichkeit – Stack in degradiertem Zustand während der Wiederherstellung |
| Erholung vom Flood | Hohe Erfolgswahrscheinlichkeit – temporäres SM-Neuinitialisierungsfenster |
| Vollständig erholt | Geringere Erfolgswahrscheinlichkeit – normale Sicherheit wiederhergestellt |
| Ausgeschaltet | Fehlschlag |