Статья CVE-2026-56451: JWT Algorithm Confusion в Siemens Opcenter X - обход аутентификации и захват MES

CVSS 10.0 из 10.0. Атака по сети, без привилегий, без взаимодействия с пользователем, автоматизируемая. CVE-2026-56451 в Siemens Opcenter X набрала максимальный балл не из-за маркетинга - вектор реально убойный. Некорректная валидация алгоритма в JWT-заголовке позволяет неаутентифицированному атакующему подделать токен, выдать себя за администратора MES-системы и получить полный контроль над приложением, которое управляет производственными операциями. Разбираю механику, условия эксплуатации и то, что должен проверить пентестер в OT-среде после этого бюллетеня.

CVE-2026-56451 - анатомия уязвимости с максимальным CVSS​

Согласно бюллетеню Siemens ProductCERT (точный номер SSA и дату публикации верифицируйте на cert-portal.siemens.com), уязвимость затрагивает все версии Opcenter X ниже V2604. Opcenter X - облачная MES-платформа (Manufacturing Execution System): планирование, диспетчеризация, контроль качества, прослеживаемость партий. Компрометация такой системы - это не утечка данных из блога, а вмешательство в производственный процесс.

Что именно сломано​

Уязвимость классифицирована как CWE-347 (Improper Verification of Cryptographic Signature). Определение прямое: продукт не верифицирует или некорректно верифицирует криптографическую подпись данных. Последствие: Access Control - Gain Privileges or Assume Identity.

В Opcenter X приложение не валидирует алгоритм, указанный в заголовке JWT. Атакующий подменяет значение в поле alg - и сервер принимает поддельный токен как легитимный. Ошибка уровня 2015 года, но в проде промышленного вендора в 2026-м.

Разбор CVSS-вектора​

Вектор CVSS 4.0: AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:L/SC:L/SI:H/SA:H

Ключевые компоненты:

Компонент	Значение	Что это значит
AV:N	Network	Атака по сети, включая интернет
AC:L	Low	Никаких специальных условий
PR:N	None	Привилегии не нужны
UI:N	None	Действия пользователя не требуются
VC:H / VI:H	High	Полная потеря конфиденциальности и целостности уязвимой системы
VA:L	Low	Низкий импакт на доступность уязвимой системы
SC:L	Low	Низкий импакт на конфиденциальность смежных систем (Subsequent System)
SI:H / SA:H	High	Высокий импакт на целостность и доступность смежных систем

В CVSS 4.0 концепция Scope заменена метриками Subsequent System (SC/SI/SA). SI:H и SA:H здесь - про MES, интегрированную с SCADA/ERP. Компрометация Opcenter X открывает путь к данным производственных процессов и смежным системам.

По CISA-ADP (SSVC): Exploitation - none (публичных эксплойтов нет), Automatable - yes, Technical Impact - total. Публичных эксплойтов пока нет, но класс уязвимости воспроизводим стандартным инструментарием пентестера - jwt_tool и немного терпения.

Как сервер решает, каким алгоритмом проверять токен​

JWT: Header, Payload, Signature. В Header поле alg указывает алгоритм подписи. Проблема - когда сервер берёт алгоритм из самого токена вместо фиксированного на бэкенде. PentesterLab в руководстве по JWT-уязвимостям описывает два подхода к верификации: захардкодить алгоритм (безопаснее) или взять значение из JWT-заголовка (контролируется атакующим - и это ровно то, что здесь произошло).

Вариант 1: атака alg:none​

[Применимо: внешний и внутренний пентест, Opcenter X < V2604]

Спецификация JWT допускает значение none в поле alg - "подпись не требуется". Ранние JWT-библиотеки принимали такие токены как валидные. Атака:

1. Перехватить легитимный JWT из HTTP-заголовка Authorization
2. Декодировать Header, заменить "alg": "RS256" на "alg": "none"
3. Модифицировать Payload - подставить claims администратора
4. Собрать токен: base64url(header).base64url(payload). (с пустой подписью)
5. Отправить запрос с поддельным токеном

Сервер не отклоняет alg: none на уровне парсера - токен принимается без верификации подписи. Вот так просто.

Вариант 2: RS256 -> HS256 confusion​

[Применимо: внешний пентест, среды с асимметричной подписью JWT]

Тут интереснее. При RS256 сервер подписывает токены приватным ключом RSA, верифицирует публичным. При HS256 один секрет для подписи и верификации. Если сервер доверяет полю alg из токена:

1. Атакующий меняет alg с RS256 на HS256
2. Берёт публичный ключ RSA сервера (часто доступен через /.well-known/jwks.json, TLS-сертификат или JWKS-эндпоинт)
3. Подписывает модифицированный Payload как HMAC, используя публичный RSA-ключ в качестве HMAC-секрета
4. Сервер проверяет подпись HS256 этим же публичным ключом - токен проходит верификацию

Тот же принцип работает для ECDSA (ES256) -> HS256 confusion, где публичный ECDSA-ключ используется как HMAC-секрет.

Формулировка бюллетеня указывает на корневую причину - сервер принимает алгоритм из заголовка токена без проверки против ожидаемого. Конкретный вариант (none, RS256->HS256 или оба) не детализирован, но класс однозначен - CWE-347, algorithm confusion.

Эксплуатация в лабораторной среде - подход пентестера​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

для kid injection - чтобы не флудить запросами и не поднимать алерты в SIEM/IDS. Если эндпоинт возвращает 200 вместо 401 на модифицированный токен - уязвимость подтверждена.

Шаг 3: ручная подделка токена​

Для целенаправленной проверки alg:none - декодируем JWT, модифицируем Header и Payload вручную:

import base64, json

header = {"alg": "none", "typ": "JWT"}
payload = {"sub": "admin", "role": "administrator"}
h = base64.urlsafe_b64encode(json.dumps(header).encode()).rstrip(b'=')
p = base64.urlsafe_b64encode(json.dumps(payload).encode()).rstrip(b'=')
token = h.decode() + '.' + p.decode() + '.'
print(token)

Полученный токен подставляется в заголовок Authorization. Если сервер возвращает данные, доступные только администратору - CWE-347 подтверждена. Десять строк кода - и ты admin MES-системы.

Ограничения техники в современных средах​

Не каждый Opcenter X < V2604 эксплуатируется одинаково:

• WAF / API Gateway: ModSecurity, AWS WAF, F5 ASM с правилами валидации JWT могут блокировать подменённые токены на уровне reverse proxy. На практике правила для JWT-алгоритмов встречаются редко, но проверить стоит
• Сетевая сегментация: в зрелых OT-средах MES-системы сидят в изолированном VLAN (уровень 3 по модели Purdue), и сетевой доступ из корпоративной сети требует дополнительных шагов - VPN-компрометация или pivot через скомпрометированный хост
• Мониторинг: при логировании JWT-валидации аномальные значения alg вызовут алерт в SIEM до закрепления. Но я редко видел настроенный парсинг JWT-заголовков в промышленных SIEM
• Версия JWT-библиотеки: PyJWT 2.4+, jose4j, nimbus-jose-jwt в актуальных конфигурациях отклоняют alg: none. Но legacy-реализации и кастомные парсеры этой защиты могут не иметь - а в OT-продуктах кастом встречается чаще, чем хотелось бы

Место в kill chain - от initial access до захвата MES​

CVE-2026-56451 - не изолированная техническая ошибка. По MITRE ATT&CK она встраивается в цепочку атаки на промышленное предприятие.

MITRE ATT&CK маппинг​

Этап	Техника	Роль CVE-2026-56451
Initial Access	Exploit Public-Facing Application (T1190)	Прямая эксплуатация веб-интерфейса Opcenter X
Credential Access	Exploitation for Credential Access (T1212)	Получение административного JWT без знания пароля
Lateral Movement	Application Access Token (T1550.001)	Поддельный JWT для доступа к API смежных сервисов
Persistence	Valid Accounts (T1078)	Имперсонация легитимного админа, действия неотличимы от штатных

Цепочка для OT-среды: атакующий получает сетевой доступ к веб-интерфейсу Opcenter X (VPN-компрометация, фишинг, прямое подключение при плохой сегментации) -> эксплуатирует CVE-2026-56451 для получения admin-токена -> через MES-интерфейс получает доступ к данным производственных заказов, рецептур, параметров качества -> может модифицировать производственные параметры или остановить выполнение заказов.

Чем OT-контекст отличается от IT​

В обычном веб-приложении JWT algorithm confusion - утечка данных и захват аккаунтов. В MES-системе последствия другие:

Физический импакт. Opcenter X управляет производственными операциями. Модификация параметров заказа или рецептуры через API с admin-правами может привести к выпуску бракованной продукции или остановке линии. В фармацевтике или пищевой промышленности это прямая угроза безопасности продукции - не абстрактная, а с конкретными пострадавшими.

Отсутствие стандартных IT-защит в OT-сегменте. Самоподписанные сертификаты, отсутствие WAF перед внутренними сервисами, legacy-версии протоколов. EDR-агенты на серверах MES в legacy-окружениях - редкость. На одном проекте я видел Opcenter, к которому можно было достучаться из гостевого Wi-Fi. Без шуток.

Доверительная модель. MES-системы интегрируются с SCADA/PLC-уровнем (Siemens SIMATIC, Opcenter Intelligence). Компрометация MES через JWT может стать pivot-точкой для доступа к нижележащим системам управления. Протоколы Modbus TCP (function codes FC1, FC3, FC5, FC6, FC15, FC16) и S7comm не имеют встроенной аутентификации на уровне отдельных команд - если ты уже в сети, можешь читать и писать регистры напрямую.

Для сравнения: инцидент TRITON (2017) показал, что атака на систему безопасности (SIS) Schneider Electric Triconex начиналась с компрометации инженерной рабочей станции через IT-вектор. Путь "компрометация MES через JWT -> pivot в OT-сеть" - реалистичен для предприятий с плоской сегментацией.

Детекция и митигация JWT-атак в промышленных средах​

Обнаружение попыток эксплуатации​

Что искать в логах:

• JWT с alg: none, alg: None, alg: NONE, alg: nOnE - любая вариация. JWT-заголовок передаётся в base64url-кодировке, поэтому детекция на уровне raw HTTP требует декодирования первого сегмента JWT или матчинга base64url-паттернов (eyJhbGciOiJub25lI для none, eyJhbGciOiJOb25lI для None). Grep по plaintext-строке alg: none в HTTP-трафике не сработает - частая ошибка при написании правил
• Резкая смена алгоритма: приложение штатно использует RS256, а в логах появляется HS256 - аномалия
• JWT без сегмента подписи (токен заканчивается на точку)
• Серия запросов с разными значениями alg от одного IP - кто-то гоняет jwt_tool с -M at

Если Opcenter X интегрирован с корпоративным SIEM, правило детекции строится на парсинге JWT из HTTP-заголовков и алертинге на нестандартные значения alg.

Чеклист для аудита JWT-реализации​

Готовый список - можно передать команде эксплуатации как есть:

1. До обновления: ограничить сетевой доступ к веб-интерфейсу Opcenter X - только доверенные IP, через firewall или ACL на сетевом оборудовании
2. Обновить до V2604+ - это закрывает корневую причину
3. Настроить reverse proxy (nginx, HAProxy) перед Opcenter X с явной валидацией JWT: whitelist допустимых алгоритмов, отклонение токенов с alg: none
4. Включить подробное логирование HTTP-запросов к API Opcenter X, особенно заголовков Authorization
5. Настроить мониторинг аномалий JWT в SIEM: алерт на смену алгоритма, на токены без подписи, на массовые 401/403 с последующим 200 от одного источника
6. Проверить сегментацию: MES-сервер не должен сидеть в одном VLAN с рабочими станциями общего назначения
7. Провести ревизию интеграций: если Opcenter X передаёт JWT в смежные системы (Opcenter Intelligence, SIMATIC IT) - те системы тоже должны валидировать алгоритм на своей стороне
8. Закрыть доступ к JWKS-эндпоинтам из внешних сетей - если публичный ключ RSA доступен без аутентификации, атака RS256->HS256 упрощается

Бизнес-логика атаки - зачем это злоумышленнику​

Атакующий с admin-доступом к MES может преследовать несколько целей: промышленный шпионаж (рецептуры, параметры производства, данные о заказах и контрагентах), саботаж (модификация параметров качества, остановка заказов), вымогательство (шифрование данных MES при отсутствии бэкапов), или pivot глубже в OT-инфраструктуру. CISA-ADP оценивает уязвимость как автоматизируемую (Automatable: yes) - при появлении публичного эксплойта массовое сканирование экземпляров Opcenter X в интернете станет тривиальной задачей для любого скрипт-кидди.

EPSS пока показывает 0.0038, percentile ~30% - отражает отсутствие публичных PoC и ограниченную видимость Opcenter X в интернете. Но для предприятий, где Opcenter X доступен из корпоративной сети (а это стандартная конфигурация), угроза реальна уже сейчас.

Три года работы с промышленными веб-интерфейсами научили меня одному: JWT-реализации в OT-продуктах отстают от IT-стандартов на поколение. В обычных SaaS жёсткий whitelist алгоритмов и обязательная верификация подписи - уже стандарт. Промышленные вендоры продолжают допускать ошибки уровня 2015 года. Вкладываются в сертификации IEC 62443 и красивые диаграммы Defense-in-Depth, а корневая ошибка - alg из заголовка токена вместо серверной конфигурации - сидит в проде, пока кто-то не напишет advisory. Думаю, в ближайшие пару лет мы увидим аналогичные CVE в MES-платформах других вендоров - архитектурный паттерн один и тот же, а пентест OT-веб-интерфейсов до сих пор не входит в стандартный скоуп промышленного аудита. Проверьте свой - может, уже пора.