19.11.2019 | Исследование безопасности дверного замка Ultraloq | ||||||||||||||||
Автор: David Lodge
Выдержка с сайта компании: Умный рычажный замок Ultraloq UL3 позволяет обходиться без ключа. Можно использовать отпечаток пальца, код или ключ. Вы полностью контролируете уровень доступа к замку и можете совместно использовать код, чтобы посетители могли открыть дверь, пока вас нет дома. …однако сразу возникает вопрос, сможет ли этот замок устоять перед целеустремленным злоумышленником? Забегая немного впередПри помощи API из мобильного приложения можно извлечь персональные данные учетной записи пользователя, которых обычно достаточно для обнаружения дома и замка. Через API можно обнулить пинкод замка, заблокировать пользователя или разблокировать дверь. Мы можем подойти к замку и открыть дверь через Bluetooth. Замок также легко открывается при помощи отмычки. Хочу поблагодарить @cybergibbons и @evstykas . Эти ребята внесли существенный вклад в создание этой статьи. Получение ключа шифрования в BLEBLE-пакет шифруется с целью предотвращения сниффинга и воспроизведения управляющего пакета. Ключ состоит из двух частей:
Эти части соединяются вместе и формируют 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 имеет схожий формат, что и BLE-пакет. Каждая запись состоит из 16 байт:
Что хранится по адресу 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 отправлен запрос о текущем состоянии дел и просьбу дать комментарии для статьи о проблеме. Ответа до сих пор нет. |
|||||||||||||||||
Проверить безопасность сайта
