Статья о критической уязвимости в open-source платформе FUXA, найденной с помощью ИИ-инструмента Positive Technologies. Из неё можно узнать о механизме атаки, рисках для промышленных систем и способах устранения.
- Уязвимость в FUXA позволяла злоумышленнику с гостевым токеном получить доступ к административному интерфейсу и API Node-RED.
- ИИ-инструмент Positive Technologies самостоятельно провёл полный цикл проверки безопасности кода: от модели угроз до предложения исправлений.
- Проблема связана с некорректной проверкой прав доступа: гостевой JWT-токен воспринимался как доверенный без проверки роли.
- Через Node-RED можно было читать, изменять и запускать сценарии, а при параметре nodeRedUnsafeModules — выполнять команды в ОС.
- Уязвимость отнесена к типу CWE-862 (Missing Authorization) и получила высокий уровень опасности.
- В версии 1.3.3 разработчики исправили проверку JWT; рекомендуется обновление или временные меры: отключение Node-RED или ограничение доступа через reverse proxy.
- FUXA
- SCADA
- HMI
- JWT
- OPC UA
- Modbus
- MQTT
- Siemens S7
- BACnet
- CWE-862
- PT Application Inspector
Кому полезно: Инженеры АСУ ТП, специалисты по промышленной кибербезопасности, разработчики SCADA-систем.
- Статья Распределённый ПЛК без шкафов автоматики: собираем АСУ ТП на 4diac FORTE, PostgreSQL и FUXA SCADA
- Обучение ПОДКЛЮЧЕНИЕ УСТРОЙСТВ ПО ПРОТОКОЛУ BACNET К SCADA TRACE MODE 7
- Обучение Бесплатный драйвер BACnet к SCADA TRACE MODE
Первоисточник: habr.com
Выжимка составлена редакцией сайта с помощью ИИ по тексту статьи.
ИИ‑инструмент 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. Теперь его могут получить аутентифицированные пользователи или обладатели действующего ключа API. Пользователям рекомендуется обновить FUXA как минимум до версии 1.3.3. До установки исправления можно отключить Node‑RED либо ограничить доступ к /nodered доверенной административной сетью через обратный прокси‑сервер (reverse proxy).
