ymsniper/whisper_bullyТрехэтапное извлечение Bluetooth BDADDR, DoS и перехват на устройствах Fast Pair; незапатченные примитивы за пределами области CVE-2025-36911 (Ubertooth не требуется)
Инструмент исследования Bluetooth: извлечение BDADDR, отказ в обслуживании и перехват
© 2026 @Ymsniper — Только для авторизованных исследований безопасности.
Whisper Bully — это трёхэтапный инструмент для исследования безопасности Bluetooth, нацеленный на устройства, рекламирующие Google Fast Pair (сервисный UUID fe2c). Он демонстрирует два неисправленных примитива атаки, которые находятся за пределами области действия патча прошивки CVE-2025-36911:
⚠️ Этот инструмент НЕ реализует протокол Whisper Pair (Fast Pair GATT). Он никогда не записывает в характеристику Key-Based Pairing (UUID 1236) или характеристику Account Key (UUID 1238). Описанная здесь поверхность атаки является отдельной и не учтена в патче проверки режима сопряжения CVE-2025-36911.
https://github.com/user-attachments/assets/67f2bcb6-38ad-4ba0-80c5-36dbb54f3f11
Основная причина: При установке BLE-соединения хост-стек Linux BlueZ обрабатывает событие LL_CONNECTION_COMPLETE и преобразует разрешимый приватный адрес (RPA) устройства в его постоянный идентификационный адрес, кэшируя его в таблице устройств BlueZ. Это происходит на уровне Link Layer / HCI, до любого взаимодействия с GATT-сервисом. Протокол Fast Pair не задействован.
Что на самом деле делает код:
BleakScanner) для обнаружения устройств, рекламирующих сервисный UUID Fast Pair fe2c — используется только для идентификации цели, без взаимодействия с протоколомBleakClient.connect() — никаких GATT-записей любого родаNoInputNoOutput в качестве подготовки к шагу 4wb.py)bluetoothctl pair <rpa_addr> — стандартная попытка SMP-сопряжения, а не Fast Pairbluetoothctl на наличие строки Bonded: yes, которая может содержать связанный адресbluetoothctl devices и сравнивает с исходным RPA — любая запись с тем же именем устройства, но другим адресом, является постоянным идентификационным адресом, раскрытым BlueZ на шаге 2Почему патч это не исправляет:
Исправление CVE-2025-36911 добавляет в прошивку аксессуара проверку режима сопряжения в обработчике характеристики Key-Based Pairing GATT Fast Pair. Этот инструмент никогда не записывает в эту характеристику. Утечка идентификационного адреса происходит на хосте атакующего Linux через собственный кэш устройств BlueZ — полностью вне прошивки аксессуара.
Ключевые замечания по поведению:
bluetoothctl pair завершается неудачей или тайм-аутомNoInputNoOutput означает отсутствие взаимодействия с пользователем с обеих сторон для Just WorksПосле получения постоянного адреса можно по желанию выполнить устойчивый L2CAP-флуд типа «отказ в обслуживании», используя модифицированную версию l2flood.
В инструменте используются два режима:
Флаг -R — режим EMP (флуд на этапе 2)
Тихий режим «выстрелил и забыл» с всплесками и переподключением. Все потоки синхронизируют свои циклы «подключение → всплеск → принудительное закрытие», чтобы цель получала периодические полные разрывы ACL, а не перемежающуюся перестановку L2CAP-каналов, которую она может поглотить. Использует SO_LINGER {1,0} для немедленного разрыва RST при каждом закрытии. Не выводит stdout в нормальном режиме работы — ошибки подключения подавляются в stderr и выводятся только периодически.
Обычный режим (зондирование для перехвата на этапе 3)
Используется без -R для проверки, отвечает ли цель ещё. Этот режим также был улучшен — теперь он автоматически выполняет переподключения и выводит no response from <addr>: id N, когда цель перестаёт отвечать, что wb.py отслеживает для запуска перехвата.
Результат: Целевое устройство становится недоступным для обычных попыток подключения, пока активен флуд. Устройство полностью восстанавливается, когда атака прекращается — никакого постоянного повреждения.
Поведение многопоточности:
Основная причина: Устойчивый L2CAP-флуд вызывает сбой или сброс стека Bluetooth целевого устройства. В окне восстановления — до того, как GATT-сервис Fast Pair будет перерегистрирован и Security Manager полностью переинициализируется — устройство принимает стандартную SMP-связку Just Works от NoInputNoOutput, не требуя рукопожатия Fast Pair GATT, которое обычно ограничивает связывание. Полученная связка является постоянной: она переживает сбросы BT-адаптера и показывает Paired: yes / Bonded: yes в bluetoothctl info.
Почему это отдельное открытие, а не часть CVE-2025-36911:
Патч CVE-2025-36911 внедряет проверку режима сопряжения в обработчик характеристики Key-Based Pairing GATT Fast Pair. Этап 3 никогда не обращается к этой характеристике. Связывание устанавливается на уровне SMP в окне, когда GATT-сервер FP ещё не переинициализировался, поэтому шлюз безопасности Fast Pair даже не достигается. Полностью исправленное устройство остаётся уязвимым, потому что патч не имеет видимости уровня SMP во время восстановления стека.
Что на самом деле делает код:
l2flood -c -1 -t 2) для подтверждения, что устройство не отвечает — ищет в выводе no response from <addr>: id Nbluetoothctl connect <permanent_addr>NoInputNoOutput / NoInputNoOutput → модель ассоциации Just Works → связывание завершаетсяbluetoothctl connect возвращает код выхода 0 при успехеВероятность успеха в зависимости от состояния устройства:
| Состояние устройства | Ожидаемый результат |
|---|---|
| Активно под флудом / не отвечает | Наивысший успех — стек в деградированном состоянии во время восстановления |
| Восстанавливается после флуда | Высокий успех — временное окно повторной инициализации SM |
| Полностью восстановилось | Более низкий успех — нормальная безопасность восстановлена |
| Выключено | Сбой |