Журнал "Information Security/ Информационная безопасность" #5, 2025

Получается, что баг, который на первый взгляд влияет только на данные или интерфейс, превращается в средство изменения поведения самого устрой- ства – легитимная функциональность становится серьезной уязвимостью, которая может привести к удаленному исполнению кода. Третья группа – варианты XSS в админских интерфейсах. На первый взгляд это не кажется страшным: типич- ный self-XSS требует, чтобы админи- стратор сам вставил вредоносный фраг- мент, а значит, риск вроде бы невелик. Но на практике детали парсинга и коди- ровок меняют дело: если приложение неправильно декодирует URL-encoded- символы, по-особому обрабатывает Uni- code или выполняет нетривиальные подстановки символов, то вредоносную нагрузку можно протащить внутрь меха- низма создания правил. В итоге интер- фейс, который должен только управ- лять настройками, сам по себе превра- щается в исполнителя кода – и уже достаточно цепочки небольших обхо- дов, чтобы скрипт запустился без пря- мого участия администратора. Четвертый, особенно коварный сце- нарий – уязвимость типа SSRF, которая изначально возникает в функционале, задуманном как удобный механизм для интеграций. Edge-платформа позволяет указать внешний адрес (endpoint, метод, путь) и автоматически отправлять на него данные из MQTT. Это удобно, пока платформа делает запросы только туда, куда вы задумывали. Проблема в том, что такой механизм позволяет злоупотребить доверием и отправить запрос к какой-нибудь внутренней системе. Сама по себе слепая SSRF, когда вы не видите ответ, мало чем полезна, но если атакующий имеет возможность влиять на конфигурации правил в edge, он может перенаправ- лять ответы от внутренних сервисов, к которым был послан запрос, себе (лог, callback, DNS-запросы). Так удоб- ная интеграция превращается в канал разведки и утечки – от доступа к внут- ренним сервисам и сканирования пор- тов до эксфильтрации данных через запросы к контролируемому домену. Это значительно усиливает возможно- сти злоумышленника в компрометации всей внутренней инфраструктуры. Наконец, системные ошибки в построении IoT-архитектуры усугубляют все предыдущие проблемы: ключевые конфигурации и секреты хранятся локально в менеджере устройств, а защита либо отключена по умолча- нию, либо спрятана глубоко в настрой- ках. В таких условиях любой, кто полу- чил даже минимальный доступ к локальной сети, может поднять свою копию менеджера и перехватить устройства либо подобрать слабый аккаунт – и получить контроль над инфраструктурой. Но основной смысл не в экзотических PoC-скриптах (Proof of Concept), а в сочетании всех перечисленных уязви- мостей в одном проекте. SQL-инъекция дает доступ к конфигам, path traversal – возможность изменить файлы, XSS – удаленное исполнение в интерфейсе, SSRF – выход в сеть и сбор откликов. В резуль- тате злоумышленник получает контроль над системой и физическими устройствами. Как защищаться? Понимание логики атаки помогает сформи- ровать защиту. Сегмента- ция сети, строгие ACL на брокере, запрет универ- сальных подписок, обяза- тельная авторизация и шифрование, валидация и нормализация входных данных, защита админ- интерфейсов и контроль за тем, где и как хранятся конфигурации и секреты, – это простые, но систем- ные меры. Они разрушают конвейер эскалации и лишают атакующего воз- можности превратить одну ошибку в контроль над процессом. Такими могут быть пер- воочередные меры для снижения окна эксплоита: 1. Выделите брокеры и edge-устройства в отдельную зону с жесткими правилами доступа: только определенные хосты/подсети должны иметь доступ к портам брокера и интер- фейсам управления. 2. Отключите публичные подписки на # и доступ к $SYS. На уровне броке- ра введите политики, запрещающие универсальные подписки извне и доступ к системным темам посторонним кли- ентам. 3. По возможности включите TLS и обязательную аутентификацию кли- ентов; если устройство не поддержи- вает TLS – временно блокируйте его внешние каналы. 4. Убедитесь, что интерфейсы управ- ления недоступны из общедоступных сетей; смените дефолтные пароли; про- верьте наличие базовых механизмов защиты (CSRF-токены, rate limit). 5. Настройте простые алерты: всплес- ки подписок, массовые публикации, известные аномальные паттерны по времени или трафику. Конечно, эти меры не устранят все уязвимости, но значительно уменьшат вероятность простых массовых взломов и снизят шанс того, что инциденты перерастут в более серьезные пробле- мы. l Редакция благодарит организаторов OFFZONE 2025 за содействие в подго- товке материала. • 55 БЕЗОПАСНАЯ РАЗРАБОТКА ДЛЯ АСУ ТП И IOT www.itsec.ru Рис. 1. Схема движения данных в IoT-архитектуре Фото: BI.ZONE Ваше мнение и вопросы присылайте по адресу is@groteck.ru