Небольшое предисловие

Привет, Хабр!

Эта статья является пятой и заключительной в цикле “Диплом специалиста ИБ”, в рамках которого я рассказываю про свой опыт написания выпускной квалификационной работы на программе высшего образования “Компьютерная безопасность”. В предыдущей статье я рассказывал про написание мобильного приложения "Smart Connect" для взаимодействия с ранее разработанными IoT-устройствами (SmartLight и SmartPulse). В данной будем пытаться получить несанкционированный доступ к представленным в дипломной работе устройствам.

Зачем это вообще нужно?

Те, кто успел ознакомиться с первой частью данного цикла статей, помнят, что в ней я рассказывал про методику обеспечения безопасности, в которой предложил выбор наиболее эффективных механизмов защиты IoT-устройств с помощью математической модели на основе многокритериального выбора. Не знаю, у кого как, но у меня возникает вопрос:

"А как вообще практически можно было бы доказать эффективность данной методики?"

На мой взгляд - попробовать провести взлом устройства, которое было защищено в соответствии с ней. Конечно я понимаю, что такого рода методику нужно проверять более комплексно, и одна лишь попытка НСД не дает особой уверенности в ее эффективности. Но в рамках дипломной работы этого было более чем достаточно, а на большее ни времени, ни сил уже не хватало.

Несанкционированный доступ - это ...

Сначала предлагаю разобраться с тем, что вообще подразумевается под понятием "Несанкционированный доступ". Если попробовать поискать информацию об этом в интернете, можно найти различную интерпретацию определения НСД.

Но если выделить основную суть этого процесса и обобщить, получится, что несанкционированным доступом является любое получение доступа к чему-либо без прав на это.

Следовательно, в контексте моей дипломной работы, несанкционированный доступ будет рассматриваться, как получение возможности манипулирования значениями BLE-характеристик (чтение, редактирование, запись значения) устройств без использования мобильного приложения Smart Connect.

То есть, если у кого-то получится подключиться и взаимодействовать с IoT-устройствами с помощью условного nRF сканера или специализированного программного обеспечения, мы будем считать, что произошел несанкционированный доступ.

После того, как расставили все точки над "и", можно приступать к практической реализации всего вышесказанного. Естественно, так как в рамках дипломной работы я рассматривал технологию BLE, то весь процесс получения несанкционированного доступа будет реализовываться применительно к BLE устройствам. Для удобства весь процесс распишу по шагам.

Шаг 1: Устанавливаем программное обеспечение

Для того, чтобы как-то подключиться к BLE устройствам, нужно их сначала найти. То есть, сделать их видимыми для устройства, с которого будем пытаться к ним получить доступ. В этом могут помочь различные сканеры и т.д.

Так как я решил использовать виртуальную машину на Linux Ubuntu 22.04 LTS «Jammy Jellyfish», особого смысла в поиске каких-то специфических приложений не было от слова "совсем". Для этих целей существует вполне удобный опенсорсный пакет BlueZ, в который входят все необходимые службы и утилиты для работы с Bluetooth и BLE устройствами.

Помимо BlueZ, также поставим rfkill, bluetooth и bluez-tools. Устанавливаем все необходимое командой: sudo apt-get install bluetooth bluez bluez-tools rfkill.

Шаг 2: Запускаем Bluetooth

После установки необходимых пакетов, запускаем службу Bluetooth с помощью команды sudo systemctl start bluetooth и устанавливаем автозапуск с загрузкой системы посредством sudo systemctl enable bluetooth.

Далее надо удостовериться, что все работает корректно. Вводим команду sudo systemctl status bluetooth и проверяем статус работы службы.

Шаг 3: Сканируем устройства

Теперь можно приступить к сканированию Bluetooth и BLE устройств, которые находятся поблизости. Для этого воспользуемся командой sudo bluetoothctl, после чего запустим сканирование с помощью power on и scan on.

После сканирования останавливаем данный процесс командой scan off. Среди найденных устройств замечаем SmartLight. Для получения НСД скопируем его адрес - 10:76:2A:61:BE:38.

Аналогичным способом получим информацию об адресе пульсомера SmartPulse (10:7F:B0:5:93:17), в процессе разработки которого были реализованы наиболее приоритетные механизмы защиты из предложенной методики обеспечения безопасности.

Шаг 4: Подключаемся к устройству

После обнародования адресов искомых устройств воспользуемся утилитой gatt tool, чтобы посмотреть всю доступную информацию о них в контексте BLE. На примере SmartLight, используем команду sudo gatttool -b 10:76:2A:61:BE:38 - I, а затем подключимся к устройству с помощью connect.

Теперь мы можем посмотреть информацию о сервисах и характеристиках SmartLight. Сервисы можно открыть посредством primary, а характеристики – командой characteristics.

Таким же образом найдем сервисы и характеристики устройства SmartPulse по адресу 10:7F:B0:5:93:17.

Шаг 5: Читаем и пишем значения BLE характеристик

Для того, чтобы прочитать информацию об уровне освещенности с помощью SmartLight, воспользуемся командой char-read-hnd, добавляя значение char value handle нужной характеристики (в данном случае 0x0003).

После применения команды получим данные об уровне освещенности, которые равны 40%. Для перевода устройства в ручной режим используем команду char-write-req 0×0008 с последующей передачей значения 00 в характеристику. Получаем уведомление об успешной записи значения в нужную характеристику.

В результате можно считать, что у нас получилось реализовать несанкционированный доступ к умному светильнику SmartLight с помощью базового пакета Linux для работы с Bluetooth и адреса устройства. Теперь попробуем проделать то же самое с защищенным устройством SmartPulse.

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

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

Демонстрация НСД

Для наглядности проведения попыток несанкционированного доступа, я решил запечатлеть все на видео.

Чтобы смотрелось эпичнее, в процессе записи значения в характеристику SmartLight, я запустил на устройстве бегущую строку с надписью "I hacked you" с помощью команды char-write-req 0x000e 49206861636b656420796f75, где закодировал передаваемое сообщение в HEX.

Ну получил ты НСД к своему же устройству и что?

Я понимаю, что после прочтения данной статьи можно подумать, что она в целом не имеет никакого смысла. Потому что "собрать два устройства, на одном из которых реализовать разные механизмы защиты, а на другом не сделать даже банальный пин-код, после чего радоваться, что получили НСД к незащищенному устройству" - это сильно. Но айсберг, что называется, намного больше, чем кажется.

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

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

Итак, мне удалось обнаружить умное устройство моего знакомого в процессе одного из многочисленных сканирований. Недолго думая я решил "почему бы не попробовать к нему подключиться?". Я обычно доверяю тем, с кем общаюсь. Но попасть под 272 статью УК РФ как-то не было желания. Поэтому я решил спросить разрешение на подключение. Знакомый оказался не против. В итоге я не просто подключился к его устройству, но еще и смог отправить несколько записей в BLE-характеристики.

Мне не хотелось бы обвинять кого-либо или подробно разбираться в данном вопросе, но данный случай отнюдь не единичен. Это служит доказательством того, что коммерческие продукты от крупных и известных компаний, использующих BLE или Bluetooth для передачи данных, зачастую либо плохо защищены, либо незащищенны вовсе.

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

Вместо заключения

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

Я с радостью выслушаю мнение и предложения людей, которые осилили и прочитали эту и другие статьи цикла "Диплом специалиста ИБ", о том, как можно было бы улучшить методику и мое исследование в целом. Также мне хотелось бы поблагодарить всех, кто уделил время для прочтения данной статьи. Был бы безумно рад получить фидбек в виде комментариев, чтобы улучшать качество материала будущих статей.

P.S. Диплом защитил на 5 и получил несколько предложений о работе в сфере IIoT и инфобеза от членов комиссии.