Исследование безопасности дверного замка Ultraloq

Исследование безопасности дверного замка Ultraloq

Несколько месяцев назад я узнал о дверном замке Ultraloq от компании U-tec. У устройств подобного класса есть ряд действительно полезных функций.

image

Автор: David Lodge


Выдержка с сайта компании:

Умный рычажный замок Ultraloq UL3 позволяет обходиться без ключа. Можно использовать отпечаток пальца, код или ключ. Вы полностью контролируете уровень доступа к замку и можете совместно использовать код, чтобы посетители могли открыть дверь, пока вас нет дома.

…однако сразу возникает вопрос, сможет ли этот замок устоять перед целеустремленным злоумышленником?

Забегая немного вперед

При помощи API из мобильного приложения можно извлечь персональные данные учетной записи пользователя, которых обычно достаточно для обнаружения дома и замка.

Через API можно обнулить пинкод замка, заблокировать пользователя или разблокировать дверь.

Мы можем подойти к замку и открыть дверь через Bluetooth.

Замок также легко открывается при помощи отмычки.

Хочу поблагодарить @cybergibbons и @evstykas. Эти ребята внесли существенный вклад в создание этой статьи.

Получение ключа шифрования в BLE

BLE-пакет шифруется с целью предотвращения сниффинга и воспроизведения управляющего пакета.

Ключ состоит из двух частей:

  • Токена, получаемого из замка.

  • Статической соли.

Эти части соединяются вместе и формируют 16-октетный байтовый массив. Вполне подходящий размер для AES-ключа.

Статическая соль, которую можно получить из приложения, эквивалентна следующей строке:

Anviz.ut

Токен можно получить, запросив характеристики BLE, используя UUID 00007220-0000-1000-8000-00805f9b34fb и дескриптор 0x22:

Поскольку код замка состоит из 6 цифр, возможна реализация брутфорса через BLE-интерфейс.

Аутентификация в API? Ничего подобного

В API аутентификация отсутствует вообще. Данные дважды проходят через обфускацию при помощи base64, но после декодирования выясняется, что авторизация и аутентификация отсутствуют как класс. В итоге злоумышленник может получить данные по всем пользователям и полностью скомпрометировать все замки, подключенные к облачному сервису.

Этот сценарий применим ко всем конечным узлам мобильного приложения ultraloq.

Примеры запросов и ответов:

Получение информации о пользователе

POST /index.php/user/get_userinfo_ex HTTP/1.1
Content-Length: 107
Content-Type: application/x-www-form-urlencoded
Host: app.service.u-tec.com
Connection: close
User-Agent: thinkandroid/1.1 (http://www.thinkandroid.cn)
Accept-Encoding: gzip, deflate
 
data=ZXlKd1lYSmhiWE1pT25zaWRYTmxjbWxrSWphMDRiNGIxZGJlZjI3Mzhlb2lNelkyTWpJaWZYMD0K%0A&token=8453661149ac73b2

Мы можем декодировать параметр data, дважды используя base64:

ZXlKd1lYSmhiWE1pT25zaWRYTmxjbWxrSWphMDRiNGIxZGJlZjI3Mzhlb2lNelkyTWpJaWZYMD0K%0A ->
{"params":{"userid"36622"}}

По результатам расшифровки видно, что userid целочисленного типа и, скорее всего, идет по порядку. Соответственно, мы можем использовать последовательные значения.

Получение информации о замках пользователя

POST /index.php/user/get_userinfo_ex HTTP/1.1
Content-Length: 107
Content-Type: application/x-www-form-urlencoded
Host: app.service.u-tec.com
Connection: close
User-Agent: thinkandroid/1.1 (http://www.thinkandroid.cn)
Accept-Encoding: gzip, deflate
 
data=ZXlKd1lYSmhiWE1pT25zaWRYTmxjbWxrSWphMDRiNGIxZGJlZjI3Mzhlb2lNelkyTWpJaWZYMD0K%0A&token=8453661149ac73b2

Как и в предыдущем примере, мы можем декодировать параметр data, дважды используя base64:

ZXlKd1lYSmhiWE1pT25zaWRYTmxjbWxrSWphMDRiNGIxZGJlZjI3Mzhlb2lNelkyTWpJaWZYMD0K%0A ->

{"params":{"userid"36622"}}

Получается, что мы теоретически можем получить последовательность всех замков у всех пользователей. В теле ответа этого запроса мы можем получить ключ шифрования для BLE и возможно все пользовательские пины. Также возможно изменение этих значений. Самый простой способ компрометирования – перехват во время авторизации и изменение userid у авторизированного юзера. Затем приложение будет функционировать от имени пользователя с указанными нами идентификатором и полным контролем над всеми замками.

Возможен ли физический взлом? Да, возможен

Устройство позволяет вставить тонкий стержень для заклинивания внутреннего механизма и открытия замка вручную.

Рисунок 1: Открытие замка при помощи отмычки

В Ultraloq есть запасной замок с ключом в основании устройства на случай, если электронная начинка выйдет из строя. И этот замок легко откроет даже начинающий без особых усилий при помощи поддевания обычной булавкой или заколкой. Конечно, подобные «фитчи» не очень уместны в замках, предназначенных для входных дверей.

Кроме того, возможно вставить тонкий инструмент (модифицированную отмычку) в нижней части боковой поверхности замка и вручную привести в движение защелку. Простой трюк, от которого нужна защита.

Остается пожелать удачи в обновлении прошивки для исправления этих недочетов.

Незашифрованное хранилище

В случае доступа к задней («защищенной») части, устройство можно быстро разобрать и добраться до внешнего SPI флэш чипа, с которого менее чем за минуту считывается вся информация при помощи Raspberry Pi и клипсы SOIC-8.

Рисунок 2: SPI флэш чип (не обращайте внимания на провода)

После выгрузки информации выяснилось, что большая часть памяти была пустой (была заполнена байтами 0xff), но кое-что все же нашлось:

Адрес

Содержимое

0x10000

Пользовательские данные и пин коды

0x20000

Пользовательские данные и информация об отпечатках

Информация по адресу 0x10000 имеет схожий формат, что и BLE-пакет. Каждая запись состоит из 16 байт:

00 00 00 F0

Номер пользователя, хранимый в виде 4-октетного значения с порядком байтов от младшего к старшему (в этом случае – 240)

3F 42 0F

Пин, хранимый в виде 3-октетного значения с порядком байтов от младшего к старшему (в этом случае – 999999)

60 00 00 00 00

Неизвестное поле (похоже на роль пользователя).

FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

Пустые данные

D9 DF C1 21

Неизвестно (похоже на контрольную сумму)

Что хранится по адресу 0x20000 выяснить не удалось, однако присутствует очевидный паттерн: три порции данных, занимающих 0x400 октета.

Заключение

В конечно итоге в компании U-tec признали проблему и исправили API, однако остался не решенным вопрос, связанный с защитой от брутфорса. Кроме того, клиентов не предупредили о риске механического взлома через запасной замок.

Не очень красиво.

Хронология событий

9 апреля 2019 года: отправлен первый отчет об уязвимостях в U-tec.

9 апреля 2019 года: быстрый ответ из U-tec с просьбой прояснить ситуацию.

10 апреля 2019 года: разъяснения предоставлены.

12 апреля 2019 года: по запросу предоставлены дополнительные разъяснения.

15 апреля 2019 года: получено электронное письмо с заверением, что «проблема будет быстро исправлена».

16 апреля 2019 года: еще один вопрос об отключении уязвимого API.

22 апреля 2019 года: получен ответ, что проблема будет решена к 29 апреля, и запрос об отсрочке раскрытия проблемы.

24 апреля 2019 года: от U-tec получен запрос на разъяснение проблемы, связанной с определением местонахождении замка.

29 апреля 2019 года: в U-tec отправлен запрос о текущем состоянии дел.

1 мая 2019 года: уязвимость в API исправлена. В U-tec отправлен запрос, когда будет исправлена проблема в BLE.

13 мая 2019 года: отправлен повторный запрос о проблеме с BLE.

28 мая 2019 года: U-tec просит еще месяц на исправление проблемы с BLE.

18 июня 2019 года: в U-tec отправлен запрос о текущем состоянии дел и просьбу дать комментарии для статьи о проблеме. Ответа до сих пор нет.

Подписывайтесь на каналы "SecurityLab" в TelegramTelegram и Яндекс.ДзенЯндекс.Дзен, чтобы первыми узнавать о новостях и эксклюзивных материалах по информационной безопасности.