15 октября 2026 / время чтения: 3 мин. / всего просмотров: 18

ИИ от PT помог найти брешь в промышленной платформе FUXA


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

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

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

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

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

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

После обхода авторизации злоумышленник получал возможность читать, изменять и запускать произвольные сценарии Node-RED (flows), выполняемые внутри серверного процесса FUXA. Через них можно было обращаться к доступным приложению файлам и сетям, а при включенном параметре node Red Unsafe Modules — выполнять произвольные команды с правами процесса 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).

 

Похожие новости

Новость

РУТЕСТ сократил нагрузочное тестирование сетевого оборудования

Новость

Разработан стандарт практических проверок безопасности Kubernetes

Новость

Российские компании теряют до 1,5 млрд рублей из-за вымогателей

Новость

Потери банков от сбоев и фрода сократились вдвое

  1. 05 «ИнфоТеКС» на Форуме ВБА-2026
  2. 06 Форум «ФинТех х10» собрал в зале более 500 человек
  3. 07 ARinteg на PSD представит взгляд интегратора на киберразведку в эпоху ИИ
  4. 08 «ИнфоБЕРЕГ'2026»: определены приоритеты ИБ до 2030 года
  5. 09 Айдентити Конф 2026: новые правила безопасности доступа
  6. 10 Кибертурнир Кубок CTF России открывает путь новичкам
ИИ-ассистент BISонлайн
Привет! Я помогу разобраться в материалах журнала. Хотите, перескажу текущую статью за 20 секунд?
Рекомендую прочитать
«Как построить SOC в 2026»