Посты
Сезам, откройся
10 июня 2025 г. в 20:06•Max Knyazev is typing…Пост из Telegram
Сезам, откройся? 
Есть устройства, которые прям просятся на взлом. Смарт-замки вполне логично к ним относятся. Они должны быть максимально защищены, но при этом удобны. А в попытках сделать удобно производители часто забывают, что безопасность ≠ UX
Недавно прочитал шикарную статью от Теодороса Даноса (а вот тут перевод статьи на Хабре), где он спокойненько взломал коммерческий Bluetooth-замок с поддержкой отпечатка пальца. Без физического доступа. Без сложных эксплойтов. Просто API, BLE и немного терпения
Вот как это было
Исследователь заметил, что мобильное приложение привязывает замок к аккаунту через обычный POST-запрос, где достаточно указать MAC-адрес устройства.
Никакой проверки, рядом ли замок. Никакой аутентификации пользователя или устройства. Просто:
И замок у тебя в аккаунте. Даже если он висит на чьей-то двери на другом конце города
После привязки, приложение получает из API зашифрованные данные замка (encryptedData). Что внутри? Пароль, ключ шифрования, MAC. Всё, что нужно, чтобы дать команду на открытие
И вот тут важный момент:
В приложении был жестко прописан AES-ключ (58966742920123314112157843194045 ), который использовался для расшифровки данных. Один ключ — на всех. Алгоритм — ECB. Padding — отсутствует. Звучит, как инструкция «как не делать крипту в 2025 году» 
BLE-протокол был симпатично устроен:
Шифруются 16-байтные команды через тот же lockKey, что мы вытащили. А это просто великолепно, потому что можно один раз поймать команду и повторять ее когда угодно
Исследователь использовал фреймворк BLE:Bit, чтобы перехватывать трафик и отправлять его повторно. Захватил unlock-команду → ушёл → вернулся → отправил → замок открылся
Никакой сессии. Никакой аутентификации. Просто BLE и кнопка "повторить"...
Что пошло не так:
Ну поугарали, да и хватит. Мы же тут умненькие. Давайте подумаем, как все это можно было бы починить. Я напишу свой вариант решения ниже в посте, а вы используйте комментарии под постом. Очень интересно послушать другое мнение
Что советую я в качестве решения? Ну во-первых, делать привязку только при физической близости через BLE. Это как минимум звучит логично. Зачем нужна возможность привязки устройства, которое находится от тебя в километре? Во-вторых, нужно бы перейти с ECB на что-то вменяемое (например, AES-GCM). ECB один из самых простых вариантов реализации AES, а такое плохо для безопасности. Ну и в третьих, обфусцировать приложение и защититься от Frida (а еще добавить защиту от replay было бы здорово)
И важно помнить, что нельзя надеяться на шифрование, если всё вокруг него — решето. Безопасность начинается не с AES, а с архитектуры
#интернет_вещей
#информационная_безопасность
Есть устройства, которые прям просятся на взлом. Смарт-замки вполне логично к ним относятся. Они должны быть максимально защищены, но при этом удобны. А в попытках сделать удобно производители часто забывают, что безопасность ≠ UX
Недавно прочитал шикарную статью от Теодороса Даноса (а вот тут перевод статьи на Хабре), где он спокойненько взломал коммерческий Bluetooth-замок с поддержкой отпечатка пальца. Без физического доступа. Без сложных эксплойтов. Просто API, BLE и немного терпения
Вот как это было
Исследователь заметил, что мобильное приложение привязывает замок к аккаунту через обычный POST-запрос, где достаточно указать MAC-адрес устройства.
Никакой проверки, рядом ли замок. Никакой аутентификации пользователя или устройства. Просто:
POST /lock/bind
{ "mac": "xx:xx:xx:xx:xx", "userId": 123 }
И замок у тебя в аккаунте. Даже если он висит на чьей-то двери на другом конце города
После привязки, приложение получает из API зашифрованные данные замка (encryptedData). Что внутри? Пароль, ключ шифрования, MAC. Всё, что нужно, чтобы дать команду на открытие
И вот тут важный момент:
В приложении был жестко прописан AES-ключ (
BLE-протокол был симпатично устроен:
— 0x36f5 — команда «в замок»
— 0x36f6 — ответ «из замка»
Шифруются 16-байтные команды через тот же lockKey, что мы вытащили. А это просто великолепно, потому что можно один раз поймать команду и повторять ее когда угодно
Исследователь использовал фреймворк BLE:Bit, чтобы перехватывать трафик и отправлять его повторно. Захватил unlock-команду → ушёл → вернулся → отправил → замок открылся
Никакой сессии. Никакой аутентификации. Просто BLE и кнопка "повторить"...
Что пошло не так:— API разрешал привязку по MAC без проверки рядом ли замок
— Ключ был жёстко прошит в приложении
— AES/ECB/NoPadding
— BLE-протокол без MAC, nonce, handshake и всего, что делает его безопасным
— Приложение без обфускации, вся логика на ладони
Ну поугарали, да и хватит. Мы же тут умненькие. Давайте подумаем, как все это можно было бы починить. Я напишу свой вариант решения ниже в посте, а вы используйте комментарии под постом. Очень интересно послушать другое мнение
Что советую я в качестве решения? Ну во-первых, делать привязку только при физической близости через BLE. Это как минимум звучит логично. Зачем нужна возможность привязки устройства, которое находится от тебя в километре? Во-вторых, нужно бы перейти с ECB на что-то вменяемое (например, AES-GCM). ECB один из самых простых вариантов реализации AES, а такое плохо для безопасности. Ну и в третьих, обфусцировать приложение и защититься от Frida (а еще добавить защиту от replay было бы здорово)
И важно помнить, что нельзя надеяться на шифрование, если всё вокруг него — решето. Безопасность начинается не с AES, а с архитектуры
#интернет_вещей
#информационная_безопасность
…
КомментарииЕсть вопрос или дополнение? Обсудить материал
Комментарии доступны только подтверждённым email-подписчикам
Подключиться к обсуждению
Введите ту же почту, которую вы уже использовали для подписки на сайт