Комментарии 8
Выводы из истории несколько замылены, понятно почему так, но все же, если не хочется про крупную отечественную компанию то почему бы не взять девайс от совершенно неизвестного китайского производителя. Собственно, копались уже и в вибраторах и в зубных щетках, но вот что то обошли вниманием - вездеорущие колонки. Естественно с разрешения владелица/владелицы... Можно даже свои купить на известных маркетах :)
Ну и поздравляю с дипломом, все очень достойно, было приятно читать, без фейспалмов - тем более.
В результате можно считать, что у нас получилось реализовать несанкционированный доступ к умному светильнику
Почему же несанкционированый? Если характеристики открыта и автор знает коды управления.
Поэтому я привел в пример историю с коммерческим устройством. То есть, смысл в том, что не обязательно знать коды управления (при наличии времени и желания их можно подобрать), чтобы получить доступ к устройству и как минимум попробовать им управлять. Ну и про открытые характеристики туда же. Хотя звучит, может, и не особо убедительно
Описанная проблема с "несанкционированным" доступом решается элегантнее. Устройству достаточно ожидать, что в течение 10 секунд должна прийти какая-то магическая константа. Если не приходит, то обрубаем соединение и ждем скажем минуту. Можно также сохранить MAC плохого клиента и в принципе не давать больше подключиться. Конечно мак можно и поменять, но какой в этом смысл если, во-первых, вы не можете определить причину дисконнекта, а во-вторых даже если определите, то перебор магического числа займет десятилетия.
А по поводу самого BLE не нужно путать баг и фичу. Очень напоминает историю про badusb когда похекеры вдруг узнали как работает usb, и оказалось система при коннекте отправляет запрос и доверяет ответу от устройства. С BLE точно так-же, это фича, то что можно подключится к любому устройству без родного клиента (имхо, это прекрасно потому что позволяет делать кастомные клиенты, например для умных часов). Защищать же или нет свое устройство от использования базового функционала BLE каждая компания решает сама. Один из вариантов подобных действий описан выше.
Спасибо за идею с более элегантным способом. Я как-то сам до этого не дошел, хотя по сути, способ много где используется.
Ну про фичу согласен. Только на мой взгляд это не должно никоим образом мешать безопасности устройства в целом. С тем же SmartPulse я же не запретил доступ в принципе. Можно спокойно подключиться к нему, можно посмотреть все сервисы и характеристики. То есть, при желании написать кастомный клиент, я предусмотрел эту возможность. Но прочитать что-либо из характеристик или записать в них без первоначального введения временного пин-кода - невозможно (или трудно выполнимо, чтобы не кидаться громкими словами). По сути, смысл всей статьи был в этом.
Огромное спасибо за комментарий!
Вообще стандарт на BLE и GATT как раз разработан так, чтобы была возможна совместная работа разных устройств и зазного ПО, как уже укзал выше @ZEN_LS. А для защиты используется Pairing, которы требует физического доступа к устройству. Pairing в стандарте не самый тривиальный, там целых 4 уровня безопасности предусмотренно в зависимости от того как спаривание произошло. Процедура спаривания с высоким уровнем безопасности подразумевает аутентификацию. Аутентификация в свою очередь требует передачи информации от устройства к устройству минуя BLE, и невозможна без физического доступа к устройству. Типичная реализация аутентификации: считать код с экрана часов и ввести в телефон. Теоретически любую GATT характеристику можно запретить читать и писать неаутентифицированным клиентам, поэтому на уровне стандарта с защищенностью проблем нет.
Ну а если вендор устройства не подумал об аутентификации, это его проблемы. Если у устройства нет ни интерфейса ввода ни интерфейса вывода способного передать 6 цифр с спариванием могут быть сложности. Это снижает защищенность канала связи, потому что 6 цифр нужны не только для аутнтификации но и для генерации ключа, недоступного тем, кто только слушает эфир. Можно сделать спаривание с подтверждением по кнопке (не помню, есть это в стандарте или надо костыли ставить). Но проблема известная, я сам работал когда-то над BLE устройством, и вопрос спаривания и защиты от несанкционированного доступа был отложен менеджментом и техлидом "на потом".
Про аутентификацию я с вами полностью согласен. Как раз в устройстве SmartPulse я реализовывал тот механизм, на который вы ссылаетесь, с генерацией шестизначного рандомного пин-кода и последующим выводом на экран устройства. Доступ к нему предоставляется после введения пин-кода в приложении Smart Connect. То есть, характеристики закрыты до тех пор, пока не произойдет проверка введенного в приложении пин-кода на уровне прошивки устройства.
Про кнопку ничего сказать не могу, я в стандарте этого не видел. По сути, сама проблема безопасности Интернета вещей как концепции и устройств IoT в частности заключается даже не в использовании уязвимостей технологий беспроводной передачи данных и прочего, а просто в нежелании «разработчика» хотя бы мало-мальски постараться над механизмами безопасности своего продукта. С точки зрения человека я могу это понять, потому что мало кто идет проверяться у стоматолога, пока зуб не заболит. Но на мой взгляд это все таки проблема, потому что важно осознавать последствия, которые могут возникать из-за такой халатности.
Спасибо за комментарий!
Диплом специалиста ИБ. Часть №5 — Несанкционированный доступ к IoT-устройствам с BLE