CVE-2026-7411 в Eclipse BaSyx Java Server SDK - из тех багов, которые заставляют задуматься о состоянии безопасности во всём стеке Industry 4.0. Неаутентифицированный атакующий через один HTTP-запрос к Submodel API записывает файлы в произвольные директории хоста и получает полное выполнение кода. CISA-ADP (SSVC) классифицировала эксплуатацию: automatable=yes, technical impact=total, exploitation=poc. EPSS-скор 0.0368 (88-й перцентиль) - вероятность активной эксплуатации выше, чем у 88% всех зарегистрированных CVE. Ниже - полный разбор уязвимости, пошаговая методология эксплуатации и контрмеры для тех, кто пентестит промышленные API.
Бизнес-логика атаки: зачем ломать Asset Administration Shell
Eclipse BaSyx - open-source реализация Asset Administration Shell (AAS), одного из центральных компонентов стека Industry 4.0. AAS - это цифровой двойник физического актива: станка с ЧПУ, промышленного робота, конвейерной линии. Через AAS-интерфейс ERP-системы и инженерные рабочие станции управляют производственными процессами, читают телеметрию, обновляют конфигурации оборудования.Компрометация BaSyx-сервера - не "ещё один взломанный веб-сервис". Атакующий получает:
- произвольную запись файлов на хост, где крутится Java-процесс BaSyx
- потенциальный pivot в OT-сегмент, если BaSyx развёрнут на шлюзе между IT и OT
- возможность подменить параметры цифрового двойника, что в production-среде может привести к физическому воздействию на оборудование
Eclipse BaSyx и Submodel HTTP API: архитектура точки входа
BaSyx реализует спецификацию AAS, определённую Industrial Digital Twin Association (IDTA). Основные компоненты:- AAS Server - хранит описания активов (Asset Administration Shells)
- Submodel Server - хранит данные подмоделей: параметры, файлы, конфигурации оборудования
- Registry - каталог всех AAS и подмоделей, позволяющий обнаруживать их по сети
fileName для указания имени сохраняемого файла.В типичном deployment BaSyx работает как Docker-контейнер или standalone Java-приложение на стандартных HTTP-портах. На промышленных пентестах я регулярно нахожу такие инстансы в конфигурации "из коробки" - без аутентификации на API, с аргументом "внутренняя сеть, кто сюда полезет". Обнаружение через Shodan по характерным JSON-структурам AAS-ответа - дело нескольких минут.
Техническая анатомия CVE-2026-7411 Eclipse BaSyx уязвимости
CVSS 10.0 и CWE-22 - разбор вектора
Уязвимость классифицирована как CWE-22 (Improper Limitation of a Pathname to a Restricted Directory). По каталогу MITRE CWE - базовый тип слабости со статусом Stable и высокой вероятностью эксплуатации. Зафиксированные последствия: Execute Unauthorized Code or Commands, Modify Files or Directories, Read Files or Directories.CVSS-вектор:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:HРазберём каждый компонент:
- AV:N (Network) - атака по сети, физический доступ не нужен
- AC:L (Low Complexity) - специальных условий или конфигураций не требуется
- PR:N (No Privileges) - аутентификация не нужна
- UI:N (No User Interaction) - жертва не должна делать ничего
- S:C (Changed Scope) - атака выходит за границы уязвимого компонента, из BaSyx SDK на хостовую ОС
- C:H/I:H/A:H - полная компрометация конфиденциальности, целостности и доступности
Исправление доступно начиная с версии 2.0.0-milestone-10.
Корневая причина: fileName без нормализации путей
В уязвимых версиях при обработке file upload в Submodel HTTP API значение параметраfileName не проходит нормализацию. Java-код не вызывает File.getCanonicalPath() для приведения пути к каноническому виду и не проверяет, что результирующий путь остаётся внутри целевой директории хранения.Атакующий подставляет в
fileName последовательности ../ и выходит за границы директории хранения. Файл записывается в любое место файловой системы, к которому имеет доступ Java-процесс.Классический паттерн, аналогичный CVE-2021-41381 - directory traversal в Payara Micro Community 5.2021.6 (CVSS 7.5, CWE-22). Принципиальная разница: в BaSyx речь о записи, а не о чтении. Arbitrary file write напрямую конвертируется в RCE - и это критически опаснее.
Для обхода возможной фильтрации на WAF или reverse proxy применяются стандартные техники кодирования (описанные в OWASP Testing Guide): URL-encoding
%2e%2e%2f вместо ../, double encoding %252e%252e%252f, mixed slashes ..\/..\/ для Windows-хостов, overlong UTF-8 последовательности.Место CVE-2026-7411 в цепочке атаки
Маппинг на MITRE ATT&CK показывает, что эксплуатация CVE-2026-7411 покрывает сразу несколько этапов kill chain минимальным количеством действий:| Этап | Техника ATT&CK | Применение в контексте BaSyx |
|---|---|---|
| Разведка | Network Service Discovery (T1046, Discovery) | Обнаружение BaSyx-инстансов сканированием и fingerprinting AAS API |
| Первичный доступ | Exploit Public-Facing Application (T1190, Initial Access) | Эксплуатация path traversal через Submodel HTTP API |
| Выполнение | Unix Shell (T1059.004, Execution) | Команды через загруженный web shell или cron job |
| Закрепление | Web Shell (T1505.003, Persistence) | JSP/WAR shell в доступной директории servlet-контейнера |
| Сбор данных | Data from Local System (T1005, Collection) | Конфигурации BaSyx, ключи, данные AAS, креды БД |
Обратите внимание: CVE-2026-7411 закрывает Initial Access, Persistence и Execution за два HTTP-запроса. Нет промежуточных шагов, нет необходимости в привилегиях, нет взаимодействия с пользователем. По оценке CISA-ADP, техническое воздействие - total, эксплуатация автоматизируема (automatable: yes).
Эксплуатация Eclipse BaSyx path traversal: от directory traversal до RCE
Требования к окружению
Для воспроизведения на тестовом стенде:- ОС: GNU/Linux (Ubuntu 22.04+) или Windows 10/11 с Docker
- RAM: минимум 4 ГБ (2 ГБ для Docker-контейнера BaSyx + инструменты атакующего)
- Софт: Docker, curl, nmap или masscan, Burp Suite (опционально для ручной инспекции)
- Версия цели: Eclipse BaSyx Java Server SDK < 2.0.0-milestone-10
- Сеть: прямой сетевой доступ к HTTP-порту BaSyx (online-режим)
Обнаружение BaSyx-инстансов
На внешнем пентесте BaSyx обнаруживается через Shodan по характерным HTTP-заголовкам. На внутреннем - черезnmap с определением сервисов:
Bash:
nmap -sV --script http-title -p 80,443,8080-8082 target_range/24/shells и /submodels. Fingerprinting по структуре ответа надёжнее, чем по конкретному порту - на реальных пентестах BaSyx часто живёт за reverse proxy на стандартных портах.Path traversal через file upload
Суть эксплуатации: отправить multipart file upload запрос к эндпоинту загрузки вложений Submodel API, подменивfileName на путь с ../ последовательностями. Конкретный URL эндпоинта зависит от версии и конфигурации BaSyx - его нужно определить на этапе разведки через изучение API-ответов.
Bash:
# fileName передаётся как отдельное form-поле в multipart body (согласно AAS Submodel API spec)
curl -X POST "http://target/submodels/{id}/submodel-elements/{elem}/attachment" -F "fileName=../../../tmp/proof.txt" -F "file=@payload.txt"proof.txt появился в /tmp/ на хосте - path traversal подтверждён. Дальше атакующий выбирает вектор эскалации до RCE.От записи файлов к выполнению кода
Arbitrary file write в Java-окружении конвертируется в RCE несколькими путями. Выбор зависит от конфигурации развёртывания:| Метод RCE | Надёжность | Скрытность | Предусловия |
|---|---|---|---|
| JSP web shell | Высокая | Низкая (артефакт в webapps) | Servlet-контейнер (Tomcat, Jetty) |
| Cron job | Средняя | Средняя | GNU/Linux, Java-процесс от root (редко в контейнерах) |
| SSH authorized_keys | Высокая | Высокая | SSH-сервер + home-директория с .ssh/ у пользователя Java-процесса |
| Подмена конфигурации | Низкая (нужен рестарт) | Высокая | Знание формата конфигурации BaSyx |
Наиболее прямой вектор: если BaSyx работает поверх Tomcat или Jetty, запись
.jsp-файла в директорию webapps даёт выполнение произвольного кода при обращении к этому файлу по HTTP. Самый универсальный вектор для GNU/Linux-хостов - запись скрипта в /etc/cron.d/ или SSH-ключа в ~/.ssh/authorized_keys пользователя Java-процесса.Предусловия и ограничения техники
Работает если:- Eclipse BaSyx Java Server SDK версии < 2.0.0-milestone-10
- Submodel HTTP API доступен по сети без аутентификации
- Java-процесс имеет права записи в целевую директорию на хосте
- Нет WAF с активными правилами на path traversal в multipart body
- Версия SDK >= 2.0.0-milestone-10 (патч нормализации путей применён)
- Docker-контейнер запущен с флагом
--read-only(read-only filesystem) - AppArmor или SELinux ограничивают запись Java-процесса за пределами рабочей директории
- Reverse proxy (Nginx, Apache) нормализует пути до передачи запроса в бэкенд
- API Gateway добавляет обязательную аутентификацию поверх BaSyx
--read-only, без AppArmor, и API торчал наружу без аутентификации - стандартный Docker Compose из GitHub-репозитория BaSyx без единого изменения в конфиге. Просто скопировали docker-compose.yml и запустили. Работает? Работает. В продакшн.Чем OT-контекст отличается от IT при эксплуатации
Для пентестеров, которые работают преимущественно с корпоративными сетями, промышленная среда с BaSyx - другая планета.Протоколы без аутентификации. BaSyx часто взаимодействует с OPC UA серверами и MQTT-брокерами в OT-сегменте. OPC UA в промышленных сетях нередко настроен с Security Mode "None". MQTT-брокеры работают без TLS и аутентификации. Компрометация BaSyx даёт атакующему доступ к этим протоколам: чтение и запись тегов PLC, включая Modbus-регистры (FC3 Read Holding Registers, FC16 Write Multiple Registers), если BaSyx выступает шлюзом.
Физический импакт. В IT компрометация сервера - утечка данных или шифрование. В OT - подмена уставок давления, температуры, скорости вращения. TRITON (2017, атака на Safety Instrumented Systems нефтехимического предприятия на Ближнем Востоке) и Industroyer (2016, атака на энергосистему Украины) показали: кибератаки на OT приводят к физическим последствиям, вплоть до угрозы жизни персонала.
Патчинг невозможен по расписанию IT. Обновление BaSyx в промышленной среде может потребовать остановки производственной линии, согласования с вендором АСУТП и проведения FAT/SAT-тестирования. Тут не "apt upgrade в ночное окно".
Сегментация на бумаге. Модель Purdue разделяет IT (Level 4-5) и OT (Level 0-3). На практике BaSyx часто размещают в DMZ между Level 3 (Operations) и Level 4 (Business) - для интеграции ERP с производственным оборудованием. Это делает BaSyx идеальной pivot-точкой из корпоративной сети в OT-сегмент. На одном проекте мы обнаружили, что через BaSyx в DMZ можно было дотянуться до Modbus-устройств напрямую - сегментация существовала только в документации.
Детектирование попыток эксплуатации
Логи reverse proxy и BaSyx. Искать запросы к file upload эндпоинтам Submodel API, где параметрfileName содержит последовательности ../, %2e%2e, %252e. Любой запрос с такими паттернами в теле multipart-запроса - индикатор попытки эксплуатации.WAF. Правила на path traversal для multipart form data. Стандартные правила OWASP CRS (группа 930 - LFI) покрывают базовые паттерны, но требуют адаптации под multipart upload - по умолчанию многие WAF не инспектируют тело multipart-запросов. Это больное место: я видел, как ModSecurity с CRS 3.x пропускал
../ в multipart body при дефолтной конфигурации.Хостовый мониторинг. Auditd с правилом на операции
write от пользователя, под которым работает Java-процесс BaSyx, за пределами рабочей директории. Появление новых файлов в /etc/cron.d/, /tmp/, ~/.ssh/ от процесса BaSyx - прямой IoC.SIEM-корреляция. HTTP POST к BaSyx API + создание нового файла Java-процессом за пределами штатной директории хранения данных - генерировать алерт высокого приоритета.
Чеклист: действия после прочтения
CVE-2026-7411 с CVSS 10.0 - не аномалия, а закономерный результат того, как устроена безопасность в стеке Industry 4.0. Я провожу пентесты промышленных API с 2022 года, и каждый проект подтверждает одну закономерность: чем ближе компонент к физическому оборудованию, тем меньше к нему внимания со стороны ИБ. BaSyx ставят интеграторы, которые думают о совместимости с SAP и MES, а не о CWE-22. Его разворачивают из
docker-compose.yml напрямую из GitHub без изменения единой строчки конфигурации. И его никто не пентестит, потому что "это же внутренний сервис для AAS".Спецификация IDTA не предписывает конкретных мер безопасности на уровне API, оставляя это на усмотрение разработчиков реализаций. Пока это не изменится, уязвимости уровня path traversal будут регулярно давать полный контроль над хостом в промышленных средах. Мой прогноз: в ближайшие полтора года появятся ещё несколько CVE подобного класса в других реализациях AAS - потому что архитектура цифровых двойников проектировалась для удобства интеграции, а не для противостояния атакующему. Если хочется разобраться, как тестировать подобные цепочки path traversal -> RCE на веб-API в реальных условиях - на WAPT разбирают именно такие вектора с лабами на каждый сценарий.
Последнее редактирование модератором:
