невзлом

Срочно · Siemens SIMATIC IoT2050

SIMATIC IoT2050 Node-RED — CVE-2026-58115 (CVSS 10), ≥V4.3.4-1

· CVE-2026-58115

← Простая версия для всех

Суть

CWE-306: на устройствах SIMATIC IoT2050 с Industrial OS и установленным Node-RED HTTP-интерфейс Node-RED не требует аутентификации. Атакующий из сети может создавать потоки с узлами, выполняющими команды ОС, и получить код с максимальными привилегиями (формулировка Siemens). CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) и CVSS 4.0 10.0 — CNA productcert@siemens.com. Без Node-RED сценарий advisory не применяется.

Затронуто и исправлено

МодельMLFBУязвимыИсправление
IoT2050 Advanced6ES7647-0BA00-1YA2< V4.3.4-1 + Industrial OS + Node-RED≥ V4.3.4-1
IoT2050 Basic6ES7647-0BA00-0YA2то же≥ V4.3.4-1
IoT2050 M.26ES7647-0BB00-1YA2то же≥ V4.3.4-1
IoT2050 SM6ES7647-0CA00-1AA2то же≥ V4.3.4-1

Пакет/образ: Siemens Industry Online Support, статья 109741799 — брать ссылку из блока Remediation в SSA (прямую URL SIOS в текст не ставим: часто Access Denied без кабинета). Порог V4.3.4-1 рекомендован с публикации SSA V1.0 (11.08.2026); V1.1 (04.11.2026) уточнила список продуктов, title и summary — не дату появления патча. Не путать с «голым» Node-RED на чужом железе — advisory только про эту линейку Siemens. Фонового автообновления под этот SSA ждать нельзя — ставят вручную.

Эксплуатация

  • Siemens SSA: формулировки «exploited» / «in the wild» нет.
  • CISA KEV: нет.
  • Вторично: VulnCheck (через СМИ 03.11.2026) — попытки на honeypot с ~30.10.2026 (боты / удалённый доступ через потоки Node-RED). Детали запросов и IoC из СМИ в текст не переносим.
  • Публичный PoC не подтверждён.

Как проверить

  • Инвентарь: MLFB с этикетки / в SIOS-проекте; факт Industrial OS; установлен ли Node-RED.
  • Версия — ПО / образ IoT2050 (экран сведений о системе или штатная процедура образа), не номер пакета Node-RED. Целевой порог ≥ V4.3.4-1. После обновления смотреть тем же способом.
  • Сеть: на граничном firewall/роутере нет DNAT/WAN/VPN «в лоб» и UPnP на HTTP(S) Node-RED хоста IoT2050; порт — из документации образа. Кто в L2/L3 видит редактор/API.
  • После патча: версия ≥ V4.3.4-1; при снятии Node-RED — сервис отсутствует; эталонный список flows; HTTP редактора не на WAN.

Точный пункт RU-меню версии в SSA не назван — документация образа / интегратор.

Как исправить

  1. Выгрузить flows и конфиг Node-RED вне устройства (бэкап до обновления).
  2. Из SSA-834709 перейти к пакету/образу ≥ V4.3.4-1 (SIOS 109741799; часто нужна учётка Siemens или партнёр) → обновить по процедуре Siemens для IoT2050 (окно обслуживания, откат-план, не рвать питание mid-update). Сторонние образы не заливать; при сорванном обновлении — только Siemens/SIOS или интегратор.
  3. Парк из нескольких узлов: инвентарь всех MLFB + версия + Node-RED → пилот на одном → раскатка; не весь цех одной сменой без проверки.
  4. Если Node-RED не нужен — удалить по документации Industrial OS / пакета для образа (конкретной one-liner команды в SSA нет). Критерий: сервис отсутствует.
  5. Если Node-RED нужен — harden по официальному Node-RED User Guide на сайте проекта Node-RED (аутентификация editor/admin API; не оставлять открытый HTTP без учёток). Вторичные пересказы СМИ сверять с User Guide, не с блогом.
  6. Сегментация: Node-RED только в mgmt/OT VLAN, без интернета и гостевого доступа. Если раньше был WAN/DNAT на Node-RED — до known-good ≥ V4.3.4-1 считать узел скомпрометированным и пройти «Признаки взлома».

Подводные камни: кастомные flows после обновления образа; зависимости от старых нод; доступ к SIOS из РФ через учётку партнёра.

Если обновить нельзя

Официально: uninstall Node-RED; harden Node-RED; Siemens operational guidelines for Industrial Security: https://www.siemens.com/cert/operational-guidelines-industrial-security (закрыть сетевой доступ). Это снижает риск, но не заменяет V4.3.4-1 при установленном уязвимом Node-RED с открытым HTTP. Вне поддержки — изоляция + план замены.

Признаки взлома и что делать

IoC в SSA Siemens нет. При подозрении (в т.ч. бывший WAN на Node-RED): изолировать шлюз от продуктивной OT; сохранить образ/flows для разбора; сверить flows с эталоном; переустановить known-good ≥ V4.3.4-1; ротировать учётные данные OT/VPN; проверить соседние хосты в том же сегменте. Одного патча после компрометации мало.

Источники