Как две уязвимости в Xen Orchestra открыли путь к захвату XCP-ng?

Французская компания Vates VMS сообщила об активной эксплуатации критической уязвимости Xen Orchestra под номером VSA-2026-062. Она позволяет обойти вход в систему и получить права Admin. Скомпрометированный аккаунт способен выполнять действия в управляемых пулах, запускать код и потенциально захватить узел XCP-ng с правами root.
Для атаки достаточно специально сформированного REST-cookie с параметром authenticationToken=j:%7B%7D или authenticationToken=j:{}. Сервер разбирает его как пустой объект {} и передаёт провайдеру токенов, не проверив, что значение должно быть строкой. Коллекция токенов воспринимает пустой объект как запрос без фильтра и возвращает первый найденный токен. Если тот ещё действителен, запрос проходит от имени его владельца.
После обхода входа атакующий может обратиться к маршруту /rest/v0/users/me/authentication_tokens и получить идентификаторы повторно используемых токенов входа. Это превращает ошибку разбора cookie в практический способ закрепиться в системе и действовать с чужими полномочиями. Когда началась эксплуатация и использовали ли уязвимость как zero-day до раскрытия, Vates не уточнила. На момент уведомления CVE-идентификатор уязвимости не был назначен.
Исправления для VSA-2026-062 выпущены в Xen Orchestra 6.9.1 и 6.10.0, а также в xo-server 5.211.2 и 5.213.1. Администраторам следует установить подходящую версию и проверить журналы запросов на оба варианта cookie с пустым объектом.
Vates также раскрыла вторую проблему, VSA-2026-063, которую атакующие используют вместе с обходом аутентификации. Она связана с импортом виртуальных машин: пользователь без привилегий администратора мог загрузить вредоносную машину в формате XVA, передав специально сформированный параметр keys, и скомпрометировать узел XCP-ng. Уязвимы Xen Orchestra Appliance и Xen Orchestra версий 6.10.1 и более ранних; на момент уведомления исправление ещё разрабатывалось.
По объяснению Vates, Xen Orchestra обращается к XAPI от имени pool-admin. Эта роль обладает широкими полномочиями, а при импорте Xen Orchestra пересылает поток данных в XAPI, не читая и не изменяя файл ova.xml. В описании атаки упомянуты параметры vm.other_config:backend-local, VM.other-config:is_system_domain и VM.platform:hvm_serial.
До выхода исправления Vates рекомендует разрешить импорт виртуальных машин только пользователю Admin. Также следует отключить пользователей, которым назначены привилегии vm.import, sr/import:vm, network/action:create или network/action:update. Такой доступ может оказаться достаточным для создания вредоносной конфигурации даже без полного набора административных прав.
В качестве признаков компрометации компания перечисляет запросы с authenticationToken=j:%7B%7D или authenticationToken=j:{}, запущенную виртуальную машину с именем pivot2 и машины, у которых задано hvm_serial: file. Проверить стоит и наличие файлов /etc/cron.d/zz-ustar2, /etc/cron.d/zz-ustar, /.ustar5 и /.ustar6.
В материалах Vates фигурируют адрес 211.251[.]112:8001, который VirusTotal определил как сервер управления RedLine Stealer, и Tor-адрес ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid[.]onion:3333. При описании цепочки атаки с использованием VSA-2026-063 компания указала другой IP: 91.211.251[.]112:8001, сохранив тот же адрес .onion. В сообщении сказано, что злоумышленник изначально действовал с этих источников, используя права Admin, полученные через VSA-2026-062. Два IP в опубликованных данных различаются, поэтому при расследовании стоит учитывать оба.