Пентест IoT-платформы: как ITG Security проверил безопасность разработки

О Клиенте

Крупнейшая российская электротехническая компания

Особенности реализации

• IoT-специфика приложения - Проверяемое решение было не классическим веб-сервисом, а приложением для управления инфраструктурой. Это означало, что потенциальные уязвимости могли затрагивать не только пользовательские данные, но и процессы взаимодействия с физическими устройствами.
• Два пользовательских контура - При тестировании было важно проверять разграничение данных и полномочий между разными типами участников платформы.
• Наличие физических и виртуальных устройств - В рамках работ использовались как виртуальные устройства для безопасного моделирования сценариев, так и физические устройства. Это позволяло проверять реалистичные сценарии взаимодействия, но требовало аккуратного подхода, чтобы исключить влияние на работоспособность оборудования.
• Обмен данными через WebSocket и IoT-протоколы - В проекте использовались WebSocket и MQTT/WS-сценарии обмена. Для IoT-систем это типовой подход: MQTT часто применяется для обмена сообщениями между устройствами и брокером, а WebSocket — для двустороннего взаимодействия веб-клиента и серверной части или передачи MQTT-сообщений через браузерную среду.
• Необходимость разработки собственного инструмента анализа - Из-за особенностей протокола платформы команде потребовалось разработать собственный плагин для анализа обмена данными через WebSocket. Это позволило корректно интерпретировать сообщения платформы, повторять запросы, анализировать параметры и проверять нестандартные сценарии эксплуатации.
• Предварительное погружение в бизнес-логику - Перед началом активной фазы клиент провел презентацию приложения, рассказал о логике работы, бизнес-ценности и ключевом функционале. Также была предоставлена архитектурная схема: прокси, основные микросервисы, связи между компонентами и контуры взаимодействия.

Решение

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

После этого была проведена сессия погружения в продукт. Клиент продемонстрировал работу приложения, основные пользовательские сценарии, бизнес-логику сервиса, роли пользователей и ценность инфраструктуры. Это позволило выстроить тестирование не только вокруг технических проверок, но и вокруг реальных сценариев использования системы.

Далее специалисты приступили к анализу веб-приложения по модели GrayBox. Проверялись механизмы регистрации и входа, восстановление доступа, ввод СМС-кодов, разграничение прав, обработка пользовательского ввода, загрузка файлов, работа с объектами инфраструктуры и взаимодействие между пользователями разных ролей.

Отдельный блок работ был посвящен анализу API и обмена данными. Так как приложение использовало платформу с нестандартным протоколом взаимодействия, команда разработала собственный плагин для анализа сообщений. Это позволило разбирать структуру WebSocket-обмена, исследовать параметры запросов, повторять действия пользователей и проверять, можно ли через протокол получить несанкционированный доступ к данным или функциям.

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

В ходе тестирования были выявлены уязвимости разного уровня критичности, включая SQL-инъекции, небезопасное использование MQTT и WebSocket, отсутствие ограничений на число попыток входа и ввода СМС-кода, XSS, небезопасную загрузку файлов, расширенный вывод ошибок, CSS-инъекцию, SSRF и перечисление существующих пользователей.

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

Результаты

• Заказчик получил независимую оценку качества разработки - Пентест позволил проверить безопасность разработки веб-приложение, API, бизнес-логику и интеграции с IoT-платформой. Это особенно важно для продукта, который должен работать с пользователями, платежными или учетными сценариями.
• Были выявлены критичные и значимые уязвимости - В ходе проверки были обнаружены две SQL-инъекции высокого уровня риска, а также небезопасное использование MQTT и WebSocket. Такие уязвимости могли иметь серьезные последствия для данных, логики приложения и взаимодействия с компонентами IoT-инфраструктуры.
• Проверены сценарии атак на пользователей и роли - Команда оценила, можно ли злоупотреблять функциональностью приложения от имени разных типов пользователей. Это позволило выявить риски, связанные с разграничением доступа и бизнес-логикой.
• Проверена устойчивость механизмов аутентификации - Были выявлены проблемы с неограниченным числом попыток входа и ввода СМС-кода. Это показало необходимость усилить защиту от подбора учетных данных, автоматизированных атак и злоупотребления механизмами подтверждения.
• Оценена безопасность пользовательского ввода и клиентской части - Несколько XSS-уязвимостей, CSS-инъекция и небезопасная загрузка файлов показали, что отдельные участки приложения требовали доработки в части фильтрации, валидации и безопасной обработки пользовательских данных.
• Проверена безопасность IoT-коммуникаций - За счет анализа WebSocket-обмена и разработки собственного плагина команда смогла проверить не только стандартный веб-интерфейс, но и специфический протокол взаимодействия платформы. Это дало заказчику более полную картину рисков, чем обычный пентест веб-приложения.
   

Выводы для заказчиков

Кейс хорошо показывает, почему пентест веб-приложений для IoT- и инфраструктурных сервисов должен выходить за рамки стандартной проверки форм, страниц и API-запросов.

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

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