Claroty Team82 выложила разбор двух CVE в EnOcean SmartServer IoT - шлюзе, через который крутятся HVAC, освещение, СКУД и электроснабжение в бизнес-центрах, дата-центрах и на промышленных площадках. Три UDP-пакета - и ты root на контроллере, который управляет кондиционерами в серверной.
Русскоязычных материалов по безопасности "умных зданий" промышленного класса почти нет. Все пишут про камеры, замки, голосовые ассистенты. А BAS-контроллеры, от которых зависит работоспособность критической инфраструктуры, никто не трогает - ни пентестеры, ни безопасники.
Бизнес-логика атаки на умные здания: физический импакт через цифровой вектор
Зачем атакующему BMS-контроллер? Тут не про кражу данных и не про шифрование. Атаки на системы автоматизации зданий бьют в физику.EnOcean SmartServer IoT - edge-контроллер, который тянет на себе управляющую логику BMS: собирает данные с полевых датчиков по протоколу LonTalk, принимает решения и раздаёт команды исполнительным устройствам. По данным SecurityWeek, платформа стоит в smart buildings, на заводах и в дата-центрах. Через один SmartServer может проходить управление:
- Климатом - HVAC в дата-центрах, где отключение охлаждения на 15-20 минут вызывает каскадный отказ серверного оборудования
- СКУД - электромагнитные замки, турникеты, периметровая защита
- Энергоснабжением - мониторинг и переключение нагрузок, управление ИБП
- Пожарной безопасностью - вентиляция, дымоудаление, противопожарные клапаны
По данным Claroty, BMS-контроллеры обычно сидят под управлением служб эксплуатации здания, а не ИБ-подразделений. Итог - оборудование, управляющее физическими процессами, выпадает из программ управления уязвимостями и реагирования на инциденты. Безопасники про него просто не знают.
Протокольная цепочка LON: промышленные протоколы безопасности и IP-852
Чтобы понять обе CVE, нужно разобраться в протокольном стеке. Он типичный для OT - и типично дырявый.
LonTalk - протокол распределённого управления, Echelon Corporation, 1990-е. Каждый узел (контроллер, датчик, привод) общается с другими по шине LON. Проектировался для изолированных физических сетей. Шифрование? Аутентификация? Нет, не слышали.
CEA-852 - стандарт туннелирования LonTalk-трафика через IP. Классический OT-паттерн: протокол из доверенной изолированной сети получает IP-обёртку ради удалённого управления и облачной интеграции. CEA-852 определяет формат IP-852 пакетов, которые заворачивают LonTalk-сообщения в UDP-датаграммы.
SmartServer IoT - мост между этими мирами: слушает IP-852 UDP-пакеты на портах 1628 и 1629, обрабатывает их через свой LonTalk-стек и транслирует команды полевым устройствам. Обе уязвимости - в парсере входящих IP-852 пакетов.
IP-852 - plain UDP. Никакого TLS, никакой аутентификации сообщений, никакой подписи пакетов. Кто угодно, способный отправить UDP-пакет на порт 1628 SmartServer, может попробовать атаку. Ситуация один в один как с Modbus, где function codes (FC1 - Read Coils, FC3 - Read Holding Registers, FC5 - Write Single Coil, FC6 - Write Single Register) летят без аутентификации. Протоколы из эпохи air-gapped сетей не закладывали злонамеренный трафик - а теперь они торчат в IP.
CVE-2026-20761 - pre-auth RCE: command injection в EnOcean SmartServer
CVE-2026-20761 - CWE-77 (Improper Neutralization of Special Elements used in a Command) в EnOcean SmartServer IoT версии 4.60.009 и ранее. По описанию NVD - удалённое выполнение произвольных команд ОС через специально сформированные IP-852 сообщения.
CVSS: 8.1 (HIGH), вектор CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Что стоит за каждым компонентом вектора:
- AV:N - атака по сети, физический доступ не нужен
- AC:H - высокая сложность: нужно узнать IP-адрес и порт конфигурационного сервера SmartServer
- PR:N - привилегии не нужны (pre-auth)
- UI:N - взаимодействие пользователя не нужно
- C:H/I:H/A:H - полная компрометация конфиденциальности, целостности и доступности
Цепочка атаки: три UDP-пакета до root
По исследованию Claroty Team82, уязвимость сидит в функцииLtSetTimeZone библиотеки libLonStack.so. Функция берёт строку с именем часового пояса из входящего IP-852 пакета, лепит из неё shell-команду и скармливает system() с root-привилегиями. Проверка - только which на бинарник set-timezone. А вот содержимое строки часового пояса никто не валидирует:
Bash:
# Схема конструируемой команды (из исследования Claroty Team82)
# <timezone> - контролируемый атакующим параметр
timedatectl set-timezone '<timezone>'
# Инъекция: timezone = "'; whoami > /tmp/pwned; '"
# Результат: timedatectl set-timezone ''; whoami > /tmp/pwned; ''Шаг 1 - разведка. Атакующий шлёт запрос
PKTTYPE_REQDEVCONFIG (тип пакета 0x63) на UDP-порт 1628. SmartServer отвечает пакетом PKTTYPE_DEVCONFIG (тип 0x71) с IP-адресом и портом конфигурационного сервера. Аутентификация не нужна - это штатное поведение протокола IP-852. Просто спроси - он расскажет.Шаг 2 - имперсонация конфигурационного сервера. Из полученных данных атакующий формирует IP-852 пакет с расширенным CNIP-заголовком (extended header size = 0x03, +12 байт). В расширенный заголовок записываются поля Local IP, NAT IP и IP Port конфигурационного сервера. SmartServer парсит CNIP-заголовок и выставляет флаг
bFromCfgServer = True - пакет считается легитимным.Шаг 3 - command injection. В поле timezone пакета
PKTTYPE_ECHCONFIG (тип 0xF3, vendor code 0x01) вставляется строка, разрывающая shell-кавычки. При установленном флаге bUseTZ SmartServer вызывает LtSetTimeZone, которая передаёт payload в system(). Команда выполняется с root-привилегиями.Деталь, которая заставляет задуматься: функция
LtSetTimeZone отсутствует в open-source коде LonTalk-стека на GitHub EnOcean. Она живёт только в скомпилированной библиотеке libLonStack.so на устройстве. Source code review здесь бесполезен - нужен бинарный анализ прошивки через Ghidra или IDA Pro. Team82 именно так её и нашла.Предусловия и ограничения эксплуатации
Работает если:- SmartServer IoT версии 4.60.009 или ранее
- UDP-порт 1628 или 1629 доступен атакующему
- IP-852 протокол активен (по умолчанию - включён)
- Прошивка обновлена до v4.60.023 или выше
- UDP-порты 1628/1629 закрыты файрволом на периметре или границе BMS-сегмента
- SmartServer в изолированном VLAN без маршрутизации к атакующему
PKTTYPE_REQDEVCONFIG. По сути AC:H тут - формальность.Kill chain и маппинг MITRE ATT&CK для ICS
Полная цепочка от разведки до физического воздействия:| Этап | Техника ATT&CK | Действие |
|---|---|---|
| Разведка | Network Service Discovery (T1046, Discovery) | Сканирование UDP 1628/1629, поиск IP-852-сервисов через Shodan/FOFA |
| Initial Access | Exploit Public-Facing Application (T1190, Initial Access) | Отправка PKTTYPE_REQDEVCONFIG для получения конфигурации |
| Initial Access | External Remote Services (T1133, Initial Access) | Использование IP-852-сервиса как точки входа |
| Execution | Command and Scripting Interpreter (T1059, Execution) | Command injection - root shell через LtSetTimeZone (root получается непосредственно через pre-auth RCE, без отдельного этапа эскалации) |
| Credential Access | Credentials In Files (T1552.001, Credential Access) | Извлечение конфигурационных файлов и ключей с контроллера |
| Lateral Movement | Exploitation of Remote Services (T1210, Lateral Movement) | Перемещение на другие BMS-контроллеры, i.LON-устройства |
| Impact | Transmitted Data Manipulation (T1565.002, Impact); MITRE ATT&CK for ICS matrix: Modify Parameter (T0836), Manipulation of Control (T0831) - идентификаторы из ICS-матрицы, не входят в Enterprise matrix, требуют независимой верификации по Matrix - ICS | MITRE ATT&CK® | Модификация уставок HVAC, отключение СКУД, подавление тревог |
CVE-2026-22885 - утечка памяти и обход ASLR в EnOcean SmartServer
CVE-2026-22885 - CWE-125 (Out-of-bounds Read) в тех же версиях SmartServer IoT. По NVD - утечка памяти из адресного пространства процесса через специально сформированные IP-852 сообщения.CVSS: 3.7 (LOW), вектор CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
3.7 - на первый взгляд ерунда. Но CISA SSVC ставит технический импакт partial (exploitation: none, automatable: no). EPSS - 0.0037 (перцентиль 28.77%).
Механизм: по данным Team82, баг сидит в парсере IP-852 заголовков. Атакующий шлёт пакет синхронизации времени с подкрученным полем extended header size. Нестандартное значение заставляет контроллер читать данные за пределами выделенного буфера на стеке и отправлять их обратно в ответном пакете. Классический OOB read.
Связка двух CVE: усиление RCE через information disclosure
Утёкшие данные могут содержать указатели на функции runtime-библиотек. Зная адрес хотя бы одной функции, атакующий вычисляет базовый адрес библиотеки и обходит ASLR - рандомизацию адресного пространства.По отдельности каждая CVE - ограниченный риск. В связке - другое дело.
В OT-контексте это опаснее, чем в IT: BMS-контроллеры работают годами без перезагрузки. Если процесс SmartServer не перезапускался (обновление, краш, watchdog), layout памяти стабилен - утёкшие адреса остаются актуальными месяцами.
Чем защита BAS отличается от IT: OT безопасность промышленных систем
Системы автоматизации зданий сидят в слепой зоне. Они - OT по всем признакам (управляют физическими процессами, влияют на безопасность людей, работают на legacy-протоколах), но выпадают из scope и IT-безопасности, и классических OT-программ.
| Аспект | IT-инфраструктура | BMS/BAS (OT) |
|---|---|---|
| Протоколы | TLS/HTTPS, Kerberos, LDAP | LonTalk, BACnet, IP-852 - без шифрования и аутентификации |
| Ответственный | IT/ИБ-подразделение | Служба эксплуатации здания |
| Патч-менеджмент | Централизованный (WSUS, SCCM) | Ручной, часто отсутствует |
| Мониторинг | SIEM, EDR, NTA | Как правило, не реализован |
| Жизненный цикл | 3-5 лет | 15-25 лет |
| Последствия компрометации | Утечка данных, шифрование | Физический ущерб, угроза жизни |
Корпоративный EDR - CrowdStrike Falcon, SentinelOne, Kaspersky EDR Expert - не ставится на GNU/Linux-based контроллер SmartServer. SIEM не парсит IP-852 пакеты. Для мониторинга BMS-трафика нужны OT-платформы (Claroty, Nozomi Networks, Dragos), которые умеют разбирать LonTalk, BACnet и смежные промышленные протоколы.
На практике всё ещё хуже. По данным Claroty, у большинства организаций нет полной инвентаризации BMS-устройств. Контроллер, поставленный при строительстве здания 10-15 лет назад, может сидеть в корпоративной сети без сегментации, без мониторинга, с дефолтными учётками на веб-интерфейсе. Сценарий компрометации через скомпрометированную инженерную станцию или ноутбук сотрудника эксплуатации превращает "внутреннюю" атаку в тривиальную задачу: три UDP-пакета из корпоративной сети на порт 1628.
Затронутые устройства и поверхность атаки
По данным Claroty Team82, уязвимости затрагивают:- EnOcean SmartServer IoT - версии 4.60.009 и ранее
- Потенциально legacy-контроллеры Echelon i.LON 100/600 - общий LonTalk-стек, требует подтверждения от вендора
- Устройства, реализующие CEA-852 с проприетарными типами пакетов Echelon
Bash:
# Поиск SmartServer / i.LON через Shodan (пример для демонстрации концепции)
# Примечание: Shodan имеет ограниченную индексацию UDP-сервисов;
# для полной оценки экспозиции комбинировать с активным сканированием
# (nmap -sU -p 1628,1629) и поиском по product-баннерам IP-852/LonTalk
nmap -sU -sV --version-intensity 9 -p 1628,1629 <target_range>
# Для UDP-сервисов без стандартных nmap probes (как IP-852) результат будет open|filtered.
# Для достоверного обнаружения используйте кастомный scapy-скрипт,
# отправляющий PKTTYPE_REQDEVCONFIG (0x63) и анализирующий ответ.
# Shodan: shodan search "port:1628" - вернёт преимущественно TCP-сервисы,
# т.к. IP-852/UDP не входит в стандартную индексацию Shodan
# FOFA: port="1628" && protocol="udp"Чеклист митигации BAS уязвимостей: от немедленных действий до стратегии
EnOcean выпустила SmartServer 4.6 Update 2 (v4.60.023), закрывающее обе уязвимости. Claroty опубликовала технические детали. Ниже - чеклист, пригодный для передачи в эксплуатацию или включения в отчёт по аудиту.Немедленные действия (24-48 часов)
- Обновить SmartServer IoT до v4.60.023 или выше. Pre-auth RCE с опубликованными техническими деталями эксплуатации - промедление тут не вариант
- Провести инвентаризацию BMS-контроллеров. Опросить службу эксплуатации: ИТ-отдел часто не знает, что SmartServer и i.LON вообще есть в инфраструктуре
- Заблокировать UDP 1628/1629 на периметровом файрволе и на границе BMS-сегмента
- Проверить внешнюю экспозицию - просканировать свои IP-диапазоны через Shodan/Censys на IP-852/LonTalk-сервисы
Среднесрочные и стратегические меры
Два CVE в EnOcean SmartServer - не аномалия. Это закономерный результат паттерна, который повторяется в OT уже десятилетие: протокол из 1990-х получает IP-обёртку без криптографии и аутентификации. LonTalk, Modbus, DNP3 - сценарий один.
Я разбирал прошивки BMS-контроллеров на объектах разного масштаба - от бизнес-центров до промышленных площадок. Паттерн стабилен: изолированная физическая шина, потом IP-обёртка, потом облачное управление. Криптография, подпись пакетов - "потом". Но "потом" не наступает, потому что контроллер работает 15 лет без перезагрузки, и его никто не трогает, пока кондиционер подаёт холод.
CVE-2026-20761 показательна ещё в одном: уязвимая функция
LtSetTimeZone отсутствует в open-source коде на GitHub. Она живёт только в скомпилированной библиотеке на устройстве. Source code review бесполезен - нужна Ghidra. Сколько аналогичных "скрытых" функций остаётся в проприетарных прошивках BMS-контроллеров других вендоров - вопрос открытый. Большинство VDP и Bug Bounty программ покрывают веб-приложения и облачную инфраструктуру. BMS firmware - terra incognita.Сетевая сегментация, которую все рекомендуют первым пунктом, необходима, но сама по себе недостаточна. Если атакующий уже во внутренней сети - через скомпрометированную инженерную станцию, фишинг сотрудника эксплуатации, через инсайдера - три UDP-пакета на порт 1628 пройдут без проблем. Нужен мониторинг внутри BMS-сегмента: пассивный анализ IP-852 трафика с детекцией аномальных
PKTTYPE_ECHCONFIG пакетов.
Последнее редактирование модератором:
