Ошибки авторизации и сопоставления имён в Azure Arc позволяют удалённо повысить привилегии

Две уязвимости в программном средстве подключения локальной инфраструктуры Azure Arc дают возможность злоумышленнику, действующему по сети, повысить свои привилегии. Обе проблемы затрагивают компонент, который связывает серверы за пределами облака Microsoft с управлением Azure. Через этот канал организации подключают машины, раздают расширения и получают сведения о конфигурации парка. По шкале CVSS проблемам присвоены максимальные оценки - 10,0 балла по версии 3.1. Производитель подтвердил обе уязвимости, а исправления уже доступны.

Детали уязвимостей

Первая уязвимость, BDU:2026-15590, связана с недостатками процедуры авторизации. Проще говоря, служба неверно определяет, какие действия разрешены обратившейся стороне. Из-за этого злоумышленник выполняет операцию, на которую у него нет прав. Тип ошибки в описании указан как неправильная авторизация (CWE-863). Атака не требует учётной записи и не зависит от действий пользователя: всё происходит по сети. Класс проблемы определён как уязвимость архитектуры. Дефект заложен в логике разграничения доступа, а не в отдельной строке кода.

Вторая уязвимость, BDU:2026-15595, относится к использованию имени с неправильной ссылкой. Такой дефект возникает, когда программа обращается к объекту по имени. При этом сопоставление идёт не с тем элементом, который подразумевался. Способ эксплуатации описан как подмена при взаимодействии. Итог тот же - удалённое повышение привилегий. Дополнительно в этом случае страдают доступность, целостность и конфиденциальность данных. По CVSS 2.0 проблема получает 10 баллов, по CVSS 3.1 тоже 10. Здесь класс иной: бюллетень относит её к уязвимостям кода.

Затронуты организации, которые используют гибридные схемы. Речь о компаниях, подключивших локальные серверы к облачному управлению. Это госсектор, промышленность, финансовые организации, крупные распределённые сети. Средство подключения работает на узле с широкими правами. Через него проходят команды управления, учётные данные и сведения о конфигурации. Поэтому повышение привилегий на таком узле теоретически открывает путь к управлению другими машинами. Кроме того, оно даёт возможность для бокового перемещения внутри сети. В худшем случае злоумышленник добирается до систем, которые считались внутренними и потому защищёнными слабее.

Повышение привилегий само по себе не равно полному захвату системы. Однако в инфраструктурных компонентах оно даёт широкие возможности. Например, злоумышленник может изменить параметры подключения, добавить машину в управляемый парк или выдать себе дополнительные права. Каждое из этих действий трудно заметить, потому что выполняется штатными средствами платформы. Помимо этого, через узел подключения проходят данные о конфигурации, что облегчает разведку перед основной атакой. Следовательно, уязвимость в таком компоненте стоит воспринимать не как локальную ошибку, а как риск для всей гибридной схемы.

Исправление сводится к обновлению программного обеспечения. В Банке данных угроз безопасности информации статус обеих уязвимостей - подтверждена производителем, а информация об устранении говорит о выходе исправления. Администраторам стоит свериться с руководством по обоим идентификаторам. Затем обновить средство подключения на всех узлах и проверить инвентаризацию подключённых машин. Полезно также ограничить сетевой доступ к портам управления. Ещё один шаг - просмотреть журналы на предмет необычных обращений к службе. Наконец, имеет смысл пересмотреть права учётных записей, которые используются для подключения. Если обновление откладывается, разумно изолировать узлы подключения от остальной сети правилами межсетевого экрана.

Такие компоненты образуют отдельную категорию риска. Агенты подключения к облачным платформам стоят на границе между внешней инфраструктурой и внутренней сетью. Они наделены правами, которых обычно нет у рядовых служб. При этом они редко попадают в поле зрения службы безопасности. Ошибки авторизации в них опасны тем, что не требуют ни фишинга, ни действий сотрудника. Поэтому закрывать их логичнее в первые дни после публикации исправлений, не дожидаясь сообщений об эксплуатации.

Детали уязвимостей

Ссылки