Обход аутентификации Xen Orchestra уже эксплуатируют в реальных атаках: специально сформированный cookie позволяет удалённому пользователю войти в консоль управления без пароля и получить административные права. Для компаний, где XCP-ng обслуживает критичные виртуальные машины, это не очередной баг веб-интерфейса, а риск захвата всей виртуализационной площадки.
Уязвимость получила идентификатор VSA-2026-062. CVE и оценка CVSS для неё пока не назначены, однако разработчик Vates классифицирует проблему как критическую. Как сообщает BleepingComputer, атака затрагивает Xen Orchestra и готовый образ Xen Orchestra Appliance (XOA) — веб-платформы для управления хостами, пулами и виртуальными машинами XCP-ng.
Причина — обработка токенов аутентификации в REST API. Злоумышленнику достаточно передать cookie authenticationToken=j:%7B%7D, то есть пустой JSON-объект в закодированном виде. Из-за ошибки Xen Orchestra может подобрать существующий токен авторизации и открыть сессию от имени его владельца. Реальные учётные данные при этом не требуются.
Дальше сценарий становится особенно неприятным для инфраструктурной команды. Уже войдя в систему, атакующий способен запросить через endpoint /rest/v0/users/me/authentication_tokens идентификаторы повторно используемых токенов входа. Это даёт возможность закрепиться в панели управления, а права администратора Xen Orchestra позволяют выполнять действия над управляемыми пулами. По предупреждению Vates, компрометация платформы может привести к выполнению произвольного кода на пулах и захвату узла XCP-ng с правами root.
Иными словами, граница атаки проходит не по самой гостевой VM. Если интерфейс Xen Orchestra доступен атакующему по сети, под угрозой оказываются хосты, конфигурации и все виртуальные машины, которыми управляет этот экземпляр. Это классический пример того, почему консоль виртуализации нельзя считать обычным внутренним веб-сервисом: её компрометация масштабируется быстрее, чем инцидент на одном сервере.
Vates уже выпустила исправления: Xen Orchestra 6.9.1 в стабильной ветке и 6.10.0 в latest-ветке. В них включены исправленные пакеты xo-server 5.211.2 и 5.213.1 соответственно. Компания рекомендует установить обновление немедленно. Если обновление требует окна работ или проверки совместимости, временной мерой остаётся изоляция интерфейса Xen Orchestra в выделенной сети администрирования и ограничение доступа к нему по спискам разрешённых адресов.
Уязвимость обнаружили исследователи Filip Magic и Christoffer Olsen из TDC NET Security. Vates подтверждает, что атаки уже идут, и опубликовала индикаторы компрометации. Среди них — соединения с адресом 91.211.251.112:8001 и onion-адресом на порту 3333, виртуальная машина с именем pivot2, а также VM с параметром hvm_serial: file. На скомпрометированных узлах могут появиться файлы /etc/cron.d/zz-ustar, /etc/cron.d/zz-ustar2, /.ustar5 и /.ustar6.
Администраторам стоит проверить настройки виртуальных машин и журналы XCP-ng. Vates предлагает искать VM с серийным портом, перенаправленным в файл, командой xe vm-list params=name-label,platform | grep -B1 'hvm_serial: file', а в логах — параметры запуска с -serial file:. Отдельно нужно проверить наличие подозрительных cron-задач, файлов .ustar и содержимого /etc/ld.so.preload. Эти признаки полезны для расследования уже известной кампании, но не являются универсальной сигнатурой: другой оператор может сменить и имена VM, и способ закрепления.
Есть важное ограничение для детектирования. Сам факт использования вредоносного cookie не оставляет характерного следа в логах Xen Orchestra. Проверять нужно HTTP-мониторинг перед интерфейсом управления: reverse proxy, WAF, сетевой сенсор или журналы балансировщика. Запросы с authenticationToken=j:%7B%7D и незакодированным вариантом authenticationToken=j:{} следует считать поводом для немедленного расследования, а не просто странностью старого клиента.
Если признаки компрометации уже обнаружены, одним обновлением дело не ограничивается. Vates советует сменить пароли и секреты, связанные с виртуализационной средой. Практически это означает отзыв и перевыпуск токенов, проверку учётных записей администраторов, аудит созданных VM и задач, а также поиск изменений в сетевых настройках и механизмах запуска хоста. Обход аутентификации Xen Orchestra мог дать атакующему права, достаточные для сохранения доступа за пределами одной веб-сессии.
Для российских команд, использующих XCP-ng как альтернативу более дорогим стеком виртуализации, инцидент напоминает о неприятной закономерности: экономия на лицензиях не отменяет стоимости защищённого контура управления. После установки патча стоит пересмотреть, кто и откуда видит Xen Orchestra, есть ли MFA и сегментация, насколько быстро собираются HTTP-логи и можно ли восстановить хост из доверенной конфигурации. В ближайшие дни именно эти вопросы отделят обычное патч-менеджмент окно от полноценного реагирования на возможный захват инфраструктуры.
