Vates раскрыла критическую уязвимость VSA-2026-062 в Xen Orchestra и Xen Orchestra Appliance. Ошибка позволяет обойти аутентификацию и выполнять действия с правами администратора; по данным вендора, её уже эксплуатирует реальный злоумышленник, работающий с 91.211.251.112:8001 и через Tor-сервис.
{По данным Vates}, REST-парсер cookie превращает специально сформированное значение authenticationToken в пустой объект. Этот объект передаётся провайдеру токенов без проверки строки, а хранилище трактует его как запрос без фильтра и возвращает первый токен. Если токен не истёк, запрос аутентифицируется как его владелец. Через маршрут /rest/v0/users/me/authentication_tokens затем можно получить многоразовые идентификаторы токенов.
Последствия зависят от прав владельца токена. При административной учётной записи компрометация Xen Orchestra может привести к выполнению кода на управляемых пулах и полному захвату узла XCP-ng с правами root. Вендор отдельно отмечает, что успешная эксплуатация не оставляет записи о неаутентифицированном доступе, поэтому обнаружить её по обычным логам нельзя.
Исправлены версии Xen Orchestra 6.9.1 и 6.10.0; пакеты xo-server 5.211.2 для stable и 5.213.1 для latest. XOA обновляется через XOA > Updates. Если Xen Orchestra была доступна из интернета, нужно считать её потенциально скомпрометированной: сменить пароли и секреты VMS, отозвать сессии и API-токены, проверить узлы XCP-ng и при подтверждённом взломе переустановить систему.
Vates также опубликовала индикаторы: IP 91.211.251.112, onion-адрес ustar3rqxgnskzgnwkgpofgtvxevm6cx3lxdbwt4mndtveqyaohid.onion, VM с именем pivot2, параметр hvm_serial: file, файлы /etc/cron.d/zz-ustar*, /.ustar5, /.ustar6 и /etc/ld.so.preload. Для детекта нужно искать HTTP-запросы с authenticationToken=j:%7B%7D или authenticationToken=j:{}.
Ссылки
