Как хакеры видят ваш умный дом: обнаружение Zigbee-устройств без взлома шифрования

Zigbee — это популярный беспроводной протокол для умного дома, который по умолчанию шифрует сетевой трафик. Шифрование защищает содержимое пакетов, но не метаданные: длину пакетов, межпакетные интервалы, периодичность служебных отчётов и шаблоны событий. Каждое устройство имеет уникальные fingerprints, заданные производителем для экономии батареи. Пассивный перехват радиосигнала позволяет злоумышленнику по этим признакам определить тип устройства, производителя, время активности в доме и даже события без расшифровки — точность идентификации по данным реальных стендов достигает 94–99% для известных моделей.

Как это выглядит на практике?

В лабораторных условиях собраны три разных набора устройств: Xiaomi, Sonoff, Home Assistant, и проанализирован их трафик. Предполагается сеть Zigbee, аналогичная представленной на Рисунке, в которой интеллектуальный концентратор ZC соединен с несколькими популярными устройствами Zigbee ZR и ZED. Концентратор подключен к IP-шлюзу для обновления состояний устройств в облаке и интеллектуальном приложении пользователя.

Жильцы умного дома выполняют повседневные дела и могут управлять устройствами через приложение практически из любого места. Пассивный злоумышленник c помощью USB-сниффера Zigbee, например, TI CC2531, представленном на Рисунке, может перехватывать трафик работы вашего умного дома.

Злоумышленник может пассивно анализировать Zigbee-трафик, распознавая события и устройства по логике команд или шаблонам отчетов — без ключей. В начале строится карта Zigbee-сети. Чтобы сэкономить место в кадрах, Zigbee использует логические адреса для маршрутизации вместо MAC-адресов назначения. Это значит, что для точной идентификации устройств нужно сопоставлять логические адреса с их MAC-адресами и типами узлов. Координатор всегда имеет адрес 0x0000, а дальше всё просто: устройства с батарейками (ZED) периодически отправляют запросы данных IEEE 802.15.4, а маршрутизаторы (ZR) их не отправляют, но становятся получателями таких запросов (кроме самого координатора). Кстати, ZR легко узнать по другим признакам: он обрабатывает кадры с метаданными маршрутизации и сам генерирует команды NWK вроде статуса соединения или отчётов о сети. По этим паттернам можно точно определить роль каждого устройства, даже если трафик зашифрован. Когда в сети происходит событие, например, открылась дверь, хакер ловит специфичные APL-команды и понимает и тип события, и что за устройство сработало. Производителя можно вычислить по MAC-адресу, а тип устройства определяется по логике его работы и особенностям метаданных. Эти особенности возникают из-за встроенных в Zigbee алгоритмов экономии энергии. Ещё злоумышленник ловит ритм устройств: по шаблонам и интервалам отчётов создаёт уникальные «цифровые отпечатки». Сверяет эти отпечатки с трафиком в целевой сети. Если таких шаблонов нет — ждёт любого события. Впервые такая идея появилась в статье Zleaks: Passive inference attacks on Zigbee based smart homes.

Как работать с событиями?

Умные устройства ведут себя предсказуемо: все лампочки используют одни и те же APL-команды для включения или смены цвета. Производители следуют стандартным Zigbee для совместимости. Однако в зашифрованном трафике команды с одинаковой длиной полезной нагрузки могут выглядеть одинаково, так как в Zigbee больше сотни APL-команд. Для разработки правила для команды с конкретной функциональностью используются форматы кадров, чтобы сначала идентифицировать все команды, которые имеют перекрывающуюся длину полезной нагрузки и направление пакета с целевой командой и ее ответной командой, например, запрос на запирание/разблокировку двери и ответ. Далее запускается тестовое событие и перекрывающиеся команды различаются на основе типа логического устройства и вариаций метаданных.

Например, команда APL с длиной полезной нагрузки 11 байт, отправленная от ZC к ZED, имеет вид «Заблокировать/разблокировать», если размер ответного пакета от ZED до ZC составляет 12 или 21 байт. Поскольку одни и те же функциональные устройства используют одни и те же команды, специфичные для функциональности, правила, созданные для определенного устройства, также справедливы и для устройств других производителей. Для статуса зоны наблюдались поведенческие закономерности, которые позволили различать различные типы датчиков. Для открытия двери статус зоны появляется только один раз, а для датчиков движения один и тот же набор пакетов повторяется через определенные интервалы времени секунд

Для полного анализа трафика берётся весь трафик от одного узла, например, 0xabcd и вычленяются из него все APL-команды — всё остальное отбрасываем. Главное правило: команда, которая реально отвечает за функцию устройства, всегда идёт первой в событии. Так что ловим первый пакет после события — и уже понимаем, что именно произошло.

Как работать со служебными пакетами?

В отличие от пакетов событий, пакеты отчетов не имеют команды APL, специфичной для функциональности, и не раскрывают напрямую тип устройства. Как показано на рисунке, чтобы разработать fingerprint периодических отчетов устройства, устройство переводится в состояние ожидания и фильтруются все команды APL, которыми обмениваются устройство и ZC. После отбрасывания лишних пакетов мы анализируем трафик, для определения как минимум трех пакетов с одинаковым шаблоном отчетов и интервалом времени.

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

Результаты на реальном стенде

Чтобы провести верификацию подхода и подтверждения его эффективности в условиях, приближенных к реальной эксплуатации, был развернут физический испытательный стенд. В его состав вошли беспроводные устройства трех наиболее распространенных на потребительском рынке вендоров: Xiaomi, Sonoff и Home Assistant. Выбор именно этих производителей обусловлен их доминирующим положением в сегменте «умного дома». Сбор трафика осуществлялся поканально с помощью утилиты командной строки whsniff. Для каждого из используемых Zigbee-каналов выполнялась команда:

sudo whsniff -c ZIGBEE_CHANNEL_NUMBER | ( gzip -c > "zigbee_sniff_$(date +"%FT%H%M%S").pcap".gz & )

Это обеспечило захват радиопакетов на уровне MAC и сетевого уровня стека Zigbee. В процессе записи мы искусственно инициировали срабатывания датчиков в строго фиксированные моменты времени, чтобы затем верифицировать корректность выделения событий. Итогом каждого сеанса стали файлы формата .pcap, содержащие полные дампы эфирной активности. Полученные дампы были поданы на вход доработанного нами программного анализатора. При его доработке мы учли все ключевые особенности протокола Zigbee, описанные в теоретической части. На Рисунках отображены результаты работы анализатора для записанного трафика датчиков xiaomi, sonoff и Home Assistant соответственно.

Анализатор выводит устройства, которые он смог выделить из трафика, и логический тип этих устройств. Затем выводятся логи событий, которые были выделены в трафике, например, сработки датчика движения или сработка датчика открытия закрытия. Сравнение полученного лога с заранее известным расписанием инициированных срабатываний показало, что точность идентификации и классификации устройств достигает 94-98%. При этом система не требует вычислительно мощных аппаратных ресурсов или глубоких экспертных знаний от конечного пользователя – все этапы от захвата трафика до построения логической карты сети полностью автоматизированы.