ИИ-инструмент Positive Technologies помог найти опасную уязвимость в промышленной платформе FUXA

Команда AppSec Research Positive Technologies обнаружила критически опасную уязвимость в FUXA — open-source-платформе для создания SCADA-, HMI- и других промышленных систем. Ошибка в механизме авторизации позволяла злоумышленнику с гостевым токеном получить функции, которые должны быть доступны только авторизованным пользователям: изменять и запускать сценарии автоматизации, обращаться к доступным приложению файлам и сети, а при определенной конфигурации — выполнять команды в операционной системе с правами процесса FUXA. Для промышленной среды это создавало риск вмешательства в работу приложения, изменения его конфигурации и воздействия на подключенные устройства.

Масштаб проекта делает проблему заметной: FUXA скачали более 100 тыс. раз, а его репозиторий на GitHub получил более чем 5 тыс. звезд и был скопирован разработчиками более 1,3 тыс. раз для дальнейшего улучшения и применения в собственных проектах. В числе пользователей — промышленные компании России. 

Найти и проверить уязвимость помог собственный ИИ-инструмент, который сейчас тестирует команда AppSec Research Positive Technologies. Он самостоятельно прошел цельный цикл проверки безопасности кода: построил модель угроз, нашел потенциальную уязвимость, проверил возможность ее эксплуатации и предложил исправления. То есть выполнил последовательность задач, которую обычно проходит AppSec-специалист при анализе защищенности приложения. Такой подход опирается на экспертизу разработчиков анализатора кода PT Application Inspector: их знания и практический опыт заложены в логику работы ИИ-инструмента.

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

Александр Халиков, старший специалист AppSec Research, Positive Technologies

Сама задача была связана с некорректной проверкой прав доступа в FUXA. Один из доступных без аутентификации механизмов выдавал гостевому пользователю подписанный сервером JWT-токен. При обращении к Node-RED система определяла токен как доверенный, но не проверяла роль и практические привилегии. В результате гостевой токен открывал доступ к административному интерфейсу и api Node-RED.

После обхода авторизации злоумышленник получал функция ознакомиться, изменять и запускать произвольные сценарии Node-RED (flows), выполняемые внутри серверного процесса FUXA. Через них можно было обращаться к доступным приложению файлам и сетям, а при включенном параметре nodeRedUnsafeModules — выполнять произвольные команды с правами процесса FUXA.

Для промышленных компаний последствия такой атаки могли выходить за пределы компрометации самого веб-интерфейса. FUXA используется для управления промышленными системами и их мониторинга и поддерживает OPC UA, Modbus, MQTT, Siemens S7, BACnet и другие протоколы. В зависимости от конфигурации среды атакующий потенциально мог изменить параметры проекта и серверные скрипты, нарушить работу приложения, получить доступ к файлам или воздействовать на подключенные устройства.

Задача возникала в конфигурациях, где администратор включал Node-RED и рассчитывал, что механизм аутентификации FUXA ограничивает доступ к нему. Уязвимость отнесена к типу «Отсутствие проверки авторизации» (CWE-862, Missing Authorization) и получила высокий уровень опасности.

В версии 1.3.3 разработчики FUXA изменили механизм проверки JWT: гостевые токены и токены обновления больше не дают доступ к Node-RED. Теперь его могут получить аутентифицированные пользователи или обладатели действующего ключа программный интерфейс. Пользователям рекомендуется апдейтнуть FUXA как минимум до версии 1.3.3. До установки исправления можно отключить Node-RED либо ограничить доступ к /nodered доверенной административной сетью через обратный прокси-сервер (reverse proxy).