Интернет вещей давно перестал быть экзотикой: тысячи устройств собирают данные, анализируют их и взаимодействуют между собой без участия человека. Но за внешней простотой IoT скрывается архитектура, где уязвимость в одном элементе способна обрушить всю систему. Чтобы понять, где именно появляются риски, достаточно рассмотреть три базовых узла: устройство, брокер и edge-платформу.
Автор: Алексей Космачев, ведущий специалист по тестированию приложений, BI.ZONE
Практическая сторона безопасности IoT, включая и затронутую в этой статье тему, обсуждалась на OFFZONE – международной конференции по практической кибербезопасности, сосредоточенной не на общих концепциях, а на конкретных технических подходах. В этом году мероприятие объединило несколько тысяч участников и более сотни экспертов, которые представили результаты своих исследований и поделились опытом из реальных проектов.
Три кита IoT
Большинство IoT-систем используют протокол MQTT – это легкий способ передавать данные по принципу publish–subscribe. Можно представить его как корпоративную рассылку: брокер – это почтовый сервер, а темы (топики) – списки рассылки. Одни устройства публикуют данные в теме, другие – подписываются и получают обновления.
Загвоздка в том, что MQTT изначально проектировался для доверенных сетей, где безопасность считалась второстепенной. В результате – минимум встроенных ограничений и обилие ошибок конфигурации. Например, если подписаться на универсальный топик #, брокер будет передавать все сообщения подряд, включая служебные. И если администратор не настроил аутентификацию, злоумышленник может подслушать весь массив передаваемых данных.
Когда устройств становится слишком много, часть обработки переносят ближе к источнику данных. Это и есть edge – программный слой или устройство, которое принимает данные с сенсоров, фильтрует их, агрегирует и передает дальше: в хранилище, облако или управляющие системы. Edge часто воспринимают как внутренний компонент, работающий в доверенной сети. Поэтому веб-интерфейсы, API и менеджеры правил в таких решениях редко проходят полноценный аудит безопасности. На практике edge – это мини-сервер с доступом ко всей телеметрии и логике управления, и его компрометация равна потере контроля над производственным процессом.
Модель угроз и потоки данных
Чтобы понять, как единичная ошибка в системе интернета вещей превращается в полноценную атаку, достаточно взглянуть на то, как в ней движутся данные (рис. 1). На принципиальной схеме все выглядит просто: сенсор собирает информацию, отправляет ее брокеру, брокер пересылает сообщения на edge-платформу, а та уже решает, что делать дальше – сохранить, обработать или передать в облако. Именно здесь чаще всего прячутся классические веб-уязвимости – SQL-инъекции, XSS, обходы авторизации, уязвимости вроде SSRF, встроенные в логику приложения.
Если изобразить эту архитектуру в виде диаграммы потоков данных, окажется, что самые опасные зоны – там, где пересекаются доверие и границы. Между сенсором и брокером нет шифрования, между брокером и edge нет строгой авторизации, а между edge и облаком часто устанавливается ненадежный канал внешней связи, через который данные могут утечь. Любая из этих точек может стать входом в систему, а вместе они формируют цепочку, которая ломается при первом же злонамеренном воздействии.
Система, задуманная как автономная и безопасная, в реальности живет на доверии и предположениях. А доверие в кибербезопасности, как известно, работает до первого инцидента.
Три ключевые поверхности атаки
Важно понять: уязвимость в любом из этих трех мест IoT-цепочки – уже не локальная беда. Компрометация датчика позволяет подслушивать и фальсифицировать данные; компрометация брокера раскрывает карту взаимодействий и дает широкую панораму системы; компрометация edge превращает его в инструмент управления. Вместе они образуют не просто набор точек риска, а единую поверхность атаки, где одна ошибка умножает эффект другой. Именно поэтому безопасность IoT – это не только про устройства или только про сеть, это про целостность архитектуры и строгость контроля на каждом стыке.
Проще всего понять угрозу на примере: возьмем типовую edge-платформу, работающую с MQTT-брокером и набором сенсоров. Сцена привычна: датчики шлют телеметрию, брокер маршрутизирует сообщения, edge принимает поток, применяет правила и решает, куда дальше уйдет информация или команда. В этой, на первый взгляд, банальной цепочке несколько распространенных мисконфигураций превращают информационную проблему в инструмент, с помощью которого можно управлять уже не только данными, но и физикой процесса.
Первый шаг злоумышленника зачастую начинается с классики – SQL-инъекции. Здесь нет никакой магии: в поле ввода, в котором не фильтруются значения, попадает SQL-запрос – и вы получаете доступ к конфигурации, спискам сущностей, внутренним идентификаторам. В изолированном веб-приложении это неприятно, а на edge-платформе это – дверь в административные сущности: параметры правил, маршруты данных, привязки к устройствам. С помощью одной инъекции можно увидеть страницу конфигурации и найти, где расположены секреты и узлы управления – а это отправная точка для эскалации.
Второй распространенный вектор – path traversal. Проще говоря, приложение принимает от пользователя часть пути к файлу и без должной нормализации склеивает его с системным путем. В результате атакующий может добраться до файлов за пределами директорий, допустимых для внешних пользователей: прочитать закрытые ключи и конфиги или перезаписать скрипт и положить туда свою команду.
Получается, что баг, который на первый взгляд влияет только на данные или интерфейс, превращается в средство изменения поведения самого устройства – легитимная функциональность становится серьезной уязвимостью, которая может привести к удаленному исполнению кода.
Третья группа – варианты XSS в админских интерфейсах. На первый взгляд это не кажется страшным: типичный self-XSS требует, чтобы администратор сам вставил вредоносный фрагмент, а значит, риск вроде бы невелик. Но на практике детали парсинга и кодировок меняют дело: если приложение неправильно декодирует URL-encoded-символы, по-особому обрабатывает Unicode или выполняет нетривиальные подстановки символов, то вредоносную нагрузку можно протащить внутрь механизма создания правил. В итоге интерфейс, который должен только управлять настройками, сам по себе превращается в исполнителя кода – и уже достаточно цепочки небольших обходов, чтобы скрипт запустился без прямого участия администратора.
Четвертый, особенно коварный сценарий – уязвимость типа SSRF, которая изначально возникает в функционале, задуманном как удобный механизм для интеграций. Edge-платформа позволяет указать внешний адрес (endpoint, метод, путь) и автоматически отправлять на него данные из MQTT. Это удобно, пока платформа делает запросы только туда, куда вы задумывали. Проблема в том, что такой механизм позволяет злоупотребить доверием и отправить запрос к какой-нибудь внутренней системе. Сама по себе слепая SSRF, когда вы не видите ответ, мало чем полезна, но если атакующий имеет возможность влиять на конфигурации правил в edge, он может перенаправлять ответы от внутренних сервисов, к которым был послан запрос, себе (лог, callback, DNS-запросы). Так удобная интеграция превращается в канал разведки и утечки – от доступа к внутренним сервисам и сканирования портов до эксфильтрации данных через запросы к контролируемому домену. Это значительно усиливает возможности злоумышленника в компрометации всей внутренней инфраструктуры.
Наконец, системные ошибки в построении IoT-архитектуры усугубляют все предыдущие проблемы: ключевые конфигурации и секреты хранятся локально в менеджере устройств, а защита либо отключена по умолчанию, либо спрятана глубоко в настройках. В таких условиях любой, кто получил даже минимальный доступ к локальной сети, может поднять свою копию менеджера и перехватить устройства либо подобрать слабый аккаунт – и получить контроль над инфраструктурой.
Но основной смысл не в экзотических PoC-скриптах (Proof of Concept), а в сочетании всех перечисленных уязвимостей в одном проекте. SQL-инъекция дает доступ к конфигам, path traversal – возможность изменить файлы, XSS – удаленное исполнение в интерфейсе, SSRF – выход в сеть и сбор откликов. В результате злоумышленник получает контроль над системой и физическими устройствами.
Как защищаться?
Понимание логики атаки помогает сформировать защиту. Сегментация сети, строгие ACL на брокере, запрет универсальных подписок, обязательная авторизация и шифрование, валидация и нормализация входных данных, защита админ-интерфейсов и контроль за тем, где и как хранятся конфигурации и секреты, – это простые, но системные меры. Они разрушают конвейер эскалации и лишают атакующего возможности превратить одну ошибку в контроль над процессом.
Такими могут быть первоочередные меры для снижения окна эксплоита:
- Выделите брокеры и edge-устройства в отдельную зону с жесткими правилами доступа: только определенные хосты/подсети должны иметь доступ к портам брокера и интерфейсам управления.
- Отключите публичные подписки на # и доступ к $SYS. На уровне брокера введите политики, запрещающие универсальные подписки извне и доступ к системным темам посторонним клиентам.
- По возможности включите TLS и обязательную аутентификацию клиентов; если устройство не поддерживает TLS – временно блокируйте его внешние каналы.
- Убедитесь, что интерфейсы управления недоступны из общедоступных сетей; смените дефолтные пароли; проверьте наличие базовых механизмов защиты (CSRF-токены, rate limit).
- Настройте простые алерты: всплески подписок, массовые публикации, известные аномальные паттерны по времени или трафику.
Конечно, эти меры не устранят все уязвимости, но значительно уменьшат вероятность простых массовых взломов и снизят шанс того, что инциденты перерастут в более серьезные проблемы.
Редакция благодарит организаторов OFFZONE 2025 за содействие в подготовке материала.