Сергей Попов
Администратор
- 30.12.2015
- 6 170
- 6 946
- Специализация
- OSINT
- Веб-безопасность
- Статус верификации
- ✓ Verified
В 2026 году исследователи опубликовали аудит XAPI - управляющего демона XCP-ng и Citrix XenServer - и заявили о 89 эксплуатируемых уязвимостях. Восемьдесят девять. Звучит как конец света для всех, кто держит Xen-стек в продакшене. Но реальность интереснее: подтвердились пять. Зато эти пять несут CVSS 9.4 по вектору CVSS:4.0 и открывают прямой путь от пользователя с ролью vm-admin до root-доступа в управляющем домене (dom0). Для инфраструктур в РФ, где Xen-стек используют как альтернативу VMware, три из пяти - CVE-2026-23559, CVE-2026-23560, CVE-2026-23561 - заслуживают детального разбора (идентификаторы БДУ ФСТЭК на момент публикации стоит проверить в bdu.fstec.ru).
Бизнес-логика атаки: зачем атакующему RBAC гипервизора
Контроль над dom0 в Xen-архитектуре - это контроль над всеми виртуальными машинами на хосте: их дисками, оперативной памятью, сетевыми интерфейсами. Root-доступ в dom0 позволяет выполнять произвольный код на хосте, вытаскивать данные из любой VM через прямой доступ к образам дисков (Escape to Host, T1611), а в пуле - перемещаться между хостами.Типичный сценарий: организация подключает XCP-ng/XenServer к Active Directory и выдаёт инженеру виртуализации роль vm-admin. Разумное решение по принципу минимальных привилегий - инженер управляет VM, но не хостами. Всё по учебнику. Только вот по данным runZero, для эксплуатации не нужен exploit-код: хватает одного вызова XAPI API, и стандартные алерты при этом молчат.
Для виртуализированной инфраструктуры (государственные ИС класса К2/К3, ИСПДн с УЗ2/УЗ3) компрометация dom0 ставит под угрозу все размещённые нагрузки. По требованиям приказа ФСТЭК №76 средства виртуализации в таких системах проходят оценку соответствия. CVE-2026-23559 с CVSS 9.4 делает неисправленную инфраструктуру на XCP-ng/XenServer формально несоответствующей.
XAPI RBAC - модель привилегий в XCP-ng и XenServer
XAPI - control plane XCP-ng и XenServer. Демон принимает API-запросы от клиентов (Xen Orchestra, XenCenter, CLI-утилитаxe) и транслирует их в операции над гипервизором Xen. RBAC реализован через предопределённые роли:| Роль | Привилегии | Типичный пользователь |
|---|---|---|
| pool-admin | Полный контроль, SSH как root | Главный администратор |
| pool-operator | Управление хостами, сетями, хранилищами | Инженер инфраструктуры |
| vm-power-admin | Создание, изменение, удаление VM | Администратор VM |
| vm-admin | Управление конфигурацией VM | Ограниченный администратор |
| vm-operator | Запуск, остановка, миграция VM | Оператор |
| read-only | Только чтение | Мониторинг, SOC |
pool-admin даёт SSH в хост как root. Роли ниже - не должны. Именно эту границу ломают CVE-2026-23560, CVE-2026-23561 и смежные уязвимости XenServer повышения привилегий до root.
Деталь, которую многие упускают: RBAC активируется только при подключении пула к Active Directory. Без AD все подключения к XAPI идут от имени локального root, ролевая модель не работает. По данным из advisory XCP-ng (апрель 2026), Xen Orchestra не использует XAPI roles - у неё собственная модель управления доступом. Пользователи XO, управляемые через AD, этим конкретным уязвимостям не подвержены.
CVE-2026-23559, CVE-2026-23560, CVE-2026-23561 - privilege escalation виртуализация через обход RBAC
Механика уязвимостей
Все три CVE относятся к CWE-250 (Execution with Unnecessary Privileges) и получили CVSS 9.4 (CRITICAL) по вектору CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H. Разберём ключевые компоненты вектора:- AV:L - локальный доступ. CNA присвоил AV:L, хотя XAPI API доступен по сети (HTTPS, TCP/443 на management-интерфейсе). Реалистичный вектор - скорее AV:N или AV:A. Выбор AV:L в векторе CNA выглядит как неточность; официального разъяснения CNA не публиковал
- AC:L - низкая сложность, дополнительных защит обходить не нужно
- UI:N - взаимодействие жертвы не требуется
- SC:H/SI:H/SA:H - subsequent scope: воздействие выходит за пределы XAPI на гостевые VM
Map(String,String) в восьми типах XAPI-объектов. Пользователь с ролью vm-admin мог через штатные API-вызовы записывать произвольные данные в конфигурационные поля, что приводило к эскалации до root в dom0 и возможности cross-VM data exfiltration. Конкретный механизм (произвольная запись файлов vs command injection через Map-поля) требует уточнения в XSA-489. По формулировке из аудита, эксплуатация происходила «через single API calls with no exploit code» - без root shell и без срабатывания алертов.По данным исследования, проблема существовала с момента создания кодовой базы XAPI - примерно с 2006 года. Двадцать лет без валидации входных данных в control plane гипервизора. Все версии Citrix XenServer / Hypervisor, XCP-ng и XAPI-based дистрибутивов потенциально затронуты.
Маппинг на MITRE ATT&CK:
- Initial Access: Valid Accounts (T1078) - легитимная учётная запись AD с ролью vm-admin
- Privilege Escalation: Exploitation for Privilege Escalation (T1068) - эксплуатация CWE-250 в XAPI
- Privilege Escalation: Escape to Host (T1611) - из контекста RBAC-роли в root dom0
- Discovery: System Information Discovery (T1082), Permission Groups Discovery (T1069) - сбор информации о пуле и гостевых VM
Предусловия и ограничения
Работает если:- Пул XCP-ng/XenServer подключён к Active Directory
- Пользователю назначена роль vm-admin (или vm-power-admin) через XAPI RBAC
- Управление идёт через XAPI API напрямую
- Управление ведётся через Xen Orchestra - XO реализует собственную ролевую модель
- Пул не интегрирован с AD (все подключения идут от root)
- Пользователь имеет роль pool-admin (и так полный доступ) или read-only (нет прав записи)
Для организаций в РФ ситуация неоднозначная. Большинство инсталляций XCP-ng используют локальную аутентификацию или Xen Orchestra - они не затронуты. Но крупные инсталляции в госсекторе, интегрированные с доменом AD для централизованного управления, попадают в зону риска.
Сопутствующие уязвимости в апрельском обновлении XCP-ng
Патч XCP-ng 8.3 LTS закрыл не только обход привилегий гипервизора через RBAC. Две дополнительные проблемы в Xen-стеке - CVE-2026-23556 (формально CVSS 9.4 CRITICAL, но реальный impact ограничен DoS - об этом ниже) и CVE-2026-23558 (CVSS 7.8 HIGH, реальная угроза изоляции VM) - дополняют картину.CVE-2026-23556 - утечка квот oxenstored
CVSS 9.4 (CRITICAL). CWE-281 (Improper Preservation of Permissions; по описанию дефект ближе к утечке ресурсов - CWE-401/CWE-772). При уничтожении домена (VM) oxenstored очищает данные узлов xenstore, но «теряет» счётчики использования. Когда domain ID переиспользуется для нового домена, тот получает уменьшенную квоту и не может создавать узлы в xenstore.Привилегированный код в гостевой ОС может этим злоупотребить: исчерпать квоту, перезагрузить VM в цикле, ждать переиспользования domain ID. NVD описывает эффект как denial of service (другие VM на хосте перестают запускаться). CVSS-вектор с VC:H/VI:H/VA:H/SC:H/SI:H/SA:H при этом выглядит завышенным - описание NVD ограничивает эффект утечкой счётчиков квот xenstore. Реалистичная оценка - отказ в обслуживании, а не полная компрометация CIA. Классификация CWE-281 тоже не стыкуется с описанным дефектом - по сути это утечка ресурсов, ближе к CWE-401.
Для SOC-аналитика индикатор: если VM внезапно перестают стартовать с ошибками xenstore, а в выводе
xen-dmesg видны повторяющиеся domain ID - проверяйте, не эксплуатируется ли CVE-2026-23556.CVE-2026-23558 - race condition в grant table
CVSS 7.8 (HIGH) по CVSS:3.1 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H). CWE-362 (Race Condition). Исправления для ранних XSA-379 и XSA-387 оказались неполными - race window сохранялось при переключении гостевого домена с grant table v2 на v1 параллельно с маппингом status page через XENMEM_add_to_physmap. Результат - use-after-free: страницы статуса освобождаются, но маппинги остаются в P2M-таблицах гостя.Привилегированный код в HVM или PVH госте может эскалировать привилегии до уровня гипервизора. Компонент S:C (changed scope) в CVSS-векторе подтверждает: эксплуатация из гостя компрометирует хост. Это самая опасная уязвимость с точки зрения изоляции виртуальных машин - T1611 (Escape to Host) непосредственно из гостевой ОС, без участия XAPI. Затронут продукт xen:xen.
Детектирование privilege escalation в XCP-ng: практика для blue team
Проверка конфигурации RBAC
Первый шаг - выяснить, использует ли пул AD-интеграцию с RBAC. На хосте XCP-ng:
Bash:
xe subject-list params=subject-name,roles
# Пустой результат = RBAC не активирован, CVE-2026-23559/23560/23561 неприменимы
# Если есть записи - ищите vm-admin и vm-power-adminxe subject-list - зафиксируйте в отчёте: RBAC через AD не используется, риск эскалации привилегий через XAPI отсутствует. Можно выдохнуть.Индикаторы в логах XAPI
XAPI записывает API-вызовы в/var/log/xensource.log. При эксплуатации аномалия - запись конфигурационных полей объектов от имени пользователя с ограниченной ролью, приводящая к изменению файлов за пределами ожидаемого scope:
Bash:
# NB: xensource.log может не содержать полных значений Map-полей -
# проверьте формат логирования set_other_config в вашей версии XAPI.
# Фильтруйте по session/user_id, а не grep -v по имени роли.
grep -E "(set_other_config|add_to_other_config)" /var/log/xensource.log \
| grep -iE "(\/etc\/|\/root\/|\/var\/spool)"other_config - ищите аномально длинные значения полей или значения, содержащие пути файловой системы dom0 (/etc/passwd, /root/.ssh/, /var/spool/cron/). Если в значении поля торчит путь к authorized_keys - это уже не штатная работа.Мониторинг целостности dom0
Успешная эксплуатация даёт запись в файловую систему dom0. Контролируйте:/etc/passwd,/etc/shadow- добавление пользователей/root/.ssh/authorized_keys- добавление SSH-ключей/etc/cron.d/,/var/spool/cron/- персистенция/etc/xapi.d/plugins/- произвольный код, вызываемый через XAPI
aide (Advanced Intrusion Detection Environment) для baseline-сравнения. На минимальном уровне - хотя бы md5sum критических файлов в cron с отправкой результатов на внешний syslog. Не идеально, но лучше, чем ничего.Чеклист патчинга для защиты виртуализированной инфраструктуры
Нумерованный список действий, готовый к передаче администратору:CVSS 9.4 на уязвимость с такими узкими предусловиями - повод для планового патчинга, а не для аврала в три ночи. Но проблема глубже, чем конкретные CVE. XAPI-кодовая база не валидировала входные данные в writable
Map(String,String) полях с 2006 года - почти двадцать лет. Из 89 заявленных уязвимостей подтвердились пять, но сам факт, что аудит нашёл 89 потенциальных точек - это приговор quality assurance на стороне control plane.Я разбирал пулы XCP-ng в нескольких российских инсталляциях - ни в одной не встретил AD-интеграции с RBAC. Управляют через Xen Orchestra или
xe от root. Но организации, которые реально используют AD с ролями XAPI, могут не подозревать, что границы ролей не так прочны, как следует из документации.Для blue team урок шире: если гипервизор - доверенный компонент модели угроз, его control plane нужно аудировать с тем же вниманием, что и контроллер домена AD. Разница между CVSS 9.4 и реальным импактом «low» от XCP-ng показывает, что ни одна метрика не заменяет контекстный анализ вашей конкретной конфигурации. На codeby.net в тредах по threat hunting в виртуализированных средах разбираем подобные кейсы по мере появления advisory - если в инфраструктуре Xen-стек, стоит заглянуть.
