Как известно многим, каждое устройство Bluetooth имеет уникальный адрес устройства Bluetooth (6 байтов), который очень похож на MAC-адрес интерфейсов Ethernet. Подмена MAC-адресов Ethernet может быть выполнена с помощью стандартных инструментов и может вызывать (не) желаемое поведение в некоторых сетевых компонентах. Адреса устройств Bluetooth также могут быть подделаны.
Как вы можете догадаться, подделка адреса устройства Bluetooth доверенного устройства делает то же самое с ранними версиями Smart Lock. Но чтобы разблокировать устройство Android с помощью Smart Lock, доверенное устройство Bluetooth должно быть подключено к смартфону. Подключение к сопряженному устройству Bluetooth требует наличия действующего ссылочного ключа на обеих сторонах соединения. Ключ связи Bluetooth создается в процессе сопряжения Bluetooth. Процесс сопряжения требует, чтобы пользователь взаимодействовал со смартфоном и - в зависимости от режима сопряжения - с устройством для сопряжения. Предполагая, что ключ связи не может быть легко получен из доверенного устройства, наличие ключа связи на рассматриваемом устройстве действительно проверяет его подлинность для устройства на другой стороне соединения.
Доказательство концепции
Ранние реализации Smart Lock полагаются на неявную аутентичность, основанную на существующем ключе связи, который должен присутствовать для установления зашифрованного соединения. В зависимости от режима устройства Bluetooth и различных служб и профилей, которые предлагает хост Bluetooth, не все соединения должны быть зашифрованы. Чтобы атаковать старые версии Smart Lock, злоумышленникам необходимо установить адрес устройства Bluetooth доверенного устройства и установить незашифрованное соединение с телефоном Android, чтобы разблокировать его.
Как показано в видео, злоумышленник подделывает Bluetooth-гарнитуру, которая установлена в качестве доверенного устройства. Выпустив (незашифрованное) соединение для запроса записей SDP системы, приложение Smart Lock разблокирует устройство. На этом этапе и другие незашифрованные соединения сделали бы свое дело (например, незашифрованное соединение с профилем OBEX Push).
Чтобы подделать адрес доверенного устройства Bluetooth, злоумышленники должны его знать. Это может быть достигнуто путем сканирования видимых устройств или обнаружения устройства (с небольшой удачей) с помощью специализированных инструментов, таких как Ubertooth One Майкла Оссмана ,
Подмена адреса устройства выполняется с помощью инструмента bdaddr, который является частью Стек BlueZ ,
# bdaddr -i hci0 -t -r 00: 11: 22: 33: 44: 55
Используйте bdaddr с параметром -t, чтобы временно установить адрес. Ключ -r выполнит сброс, чтобы вновь настроенный BDADDR вступил в силу немедленно. В этом примере BDADDR 00: 11: 22: 33: 44: 55 является адресом доверенного устройства Bluetooth. Не каждый набор микросхем поддерживается инструментом bdaddr. Средство, как известно, работает с чипами производителя КСО ,
Чтобы установить незашифрованное соединение, можно использовать следующую команду.
# sdptool records 00: 11: 22: FF: FF: FF
В приведенном выше примере 00: 11: 22: FF: FF: FF - это адрес атакованного телефона. Команда sdptool records устанавливает незашифрованное соединение со смартфоном и перебирает все возможные сервисные номера. Используя все возможные дескрипторы, команда выполняется дольше, чем команда «sdptool browse», что увеличивает время, когда злоумышленник может разблокировать телефон без PIN-кода.
Кроме того, злоумышленники могут установить незашифрованное соединение с push-профилем OBEX, что приведет к увеличению временного окна, которое позволяет разблокировать без PIN-кода.
Формальный рейтинг серьезности (SCAP)
Базовый балл CVSS v2 рассчитывается с 6,8 ( AV-L / AC: L / Au: S / C, C / I: С / А: С )
Затронутые продукты:
cpe: / a: google: play_services_sdk: 7.3.26 (и более ранние версии)
на
CPE: / о: Google: Android: 5.0.0
CPE: / о: Google: Android: 5.0.1
CPE: / о: Google: Android: 5.0.2
CVE ID: в ожидании
Решение
Проблема здесь в том, что ранние версии Smart Lock не проверяют, было ли зашифровано соединение Bluetooth с доверенного устройства или нет. Другими словами: неявная аутентичность подключенного устройства не проверяется. Чтобы решить эту проблему, были необходимы две модификации:
- Необходимо было расширить API Bluetooth, чтобы проверить, зашифровано ли соединение Bluetooth ( Android 5.1 Changelog (строка 8883) )
- Платформа Google Play Services также должна была претерпеть некоторые изменения (фиксированная версия: Google Play Services 7.3.27)
Ответственное раскрытие
Уязвимость была раскрыта в Google ( Программа вознаграждений за уязвимости Google ) в конце января 2015 г. Группа безопасности Google предоставила исправление к началу апреля 2015 г.