Согласно подтвержденному раскрытию информации об уязвимости, критический дефект аутентификации в Azure SRE Agent от Microsoft обнажил конфиденциальные данные агента для несанкционированного сетевого доступа.
Проблема была выявлена исследователем Enclave AI Яниром Царими, который подробно описал свои находки в посте в блоге, описывающем, как можно получить доступ к взаимодействиям агента без надлежащих механизмов контроля аутентификации. Уязвимости присвоен идентификатор CVE-2026-32173, она оценена как критическая с баллом CVSS 8.6.
В блоге Царими описал сценарии, при которых можно было наблюдать активность агента во время его выполнения, включая взаимодействие между пользователями и системой. Утечка произошла из-за пробела в аутентификации сервиса, что позволяло получать доступ к потокам данных без действительных учетных данных.
Microsoft классифицировала это как проблему некорректной аутентификации, позволяющую неавторизованному злоумышленнику раскрывать информацию по сети, говорится в записи NVD.
«Представьте, что вы наняли помощника, имеющего доступ ко всему: к вашим серверам, логам, паролям, исходному коду. А теперь представьте, что совершенно незнакомец из совершенно несвязанной компании может незаметно прослушивать каждый разговор этого помощника», — написал исследователь Enclave Янир Царими. «Именно это мы обнаружили в Azure SRE Agent».
Microsoft уже устранила проблему, добавлено в блоге. Исправление было применено на стороне сервера, и в уведомлении Microsoft указано, что никаких действий со стороны клиентов не требуется. Azure SRE Agent достиг общей доступности 10 марта.
Мультитенантность по умолчанию
Агент передает всю активность через конечную точку WebSocket с именем /agentHub, говорится в блоге.
Для подключения к этой конечной точке требовался токен, но базовая регистрация приложения Entra ID была настроена как мультитенантная, что означало, что любой аккаунт из любого клиента Entra ID мог получить действительный токен, который принимал хаб.
«Затем хаб проверял: Токен действителен? Да. Соответствует ли аудитория? Да. Он никогда не спрашивал: Принадлежит ли этот вызывающий клиент целевому клиенту? Авторизован ли он использовать этого агента? Имеет ли он какую-либо роль в этом ресурсе?» — написал Царими.
После подключения хаб транслировал все события всем клиентам без какой-либо фильтрации по идентификаторам, говорится в блоге.
В раскрытый канал входили запросы пользователя, ответы агента, внутренние трассировки рассуждений, каждая выполненная команда с полными аргументами и вывод команды.
«В нашей собственной тестовой среде мы наблюдали, как агент выполняет рутинную задачу и возвращает учетные данные для развертывания живых веб-приложений», — написал Царими. «Перехватчик на реальной цели получил бы то же самое. Незаметно. Без каких-либо признаков того, что в линии присутствует кто-то еще».
Для эксплуатации требовался только поддомен целевого агента, который Enclave описала как предсказуемый и перечисляемый, а также около 15 строк кода на Python. Сторонние трекеры определили затронутый компонент как Azure SRE Agent Gateway SignalR Hub.
Наблюдение за тем, как привилегированный оператор рассуждает вслух
Категорию этого дефекта не следует слишком тесно сравнивать с обычной ошибкой API, заявил Александр Хагенах, специалист по кибербезопасности и исполнительный директор швейцарской финансовой инфраструктурной компании SIX Group.
«Обычная проблема API обычно ограничена определенной конечной точкой, набором данных или проверкой разрешений. В случае агента операций на базе ИИ сам агент становится точкой агрегации для состояния инфраструктуры, логов, исходного кода, контекста инцидентов, команд, результатов и иногда учетных данных, которые появляются во время устранения неполадок», — сказал Хагенах.
«На практике это может выглядеть как наблюдение за тем, как привилегированный оператор рассуждает вслух», — добавил он.
Хагенах отметил, что утечка не приводит к автоматическому компрометации инфраструктуры, но может быть более ценной, чем многие ошибки, связанные только с чтением. Злоумышленникам обычно приходится приложить значительные усилия после первоначального доступа, чтобы понять среду. Агент SRE может уже иметь этот контекст собранным для них.
Соединение также не оставляло следов на стороне жертвы, написал исследователь. «У организаций-жертв не было возможности обнаружить это, расследовать постфактум и оценить масштаб произошедшего».
Соображения для предприятий
Enclave, согласно сообщению в блоге, отметила, что организации, использовавшие Azure SRE Agent в период предварительного просмотра, должны считать этот период потенциально скомпрометированным и просмотреть любые учетные данные, данные конфигурации или конфиденциальную информацию, которые могли пройти через взаимодействия агента или вывод CLI.
Хагенах считает, что сервисы агентных операций необходимо регулировать скорее как привилегированные платформы автоматизации, а не как обычные инструменты SaaS.
«Прежде чем предоставлять такой уровень доступа, я хотел бы получить очень четкие ответы об изоляции клиентов и авторизации на уровне ресурсов. Недостаточно, чтобы токен был действительным. Сервис должен проверить, что вызывающий принадлежит к правильному клиенту, авторизован для этого конкретного агента и имеет право доступа к этому конкретному потоку, ветке, выводу инструмента или действию», — сказал он.
Агент должен работать под выделенной управляемой идентификацией с минимальными разрешениями, а интеграции с выполнением команд, запросом логов, репозиториями исходного кода и платформами инцидентов следует рассматривать как любую другую привилегированную систему, сказал Хагенах. Предприятия также должны знать, кто подключался, к каким веткам обращался, какие команды выполнялись и какой вывод возвращался, при этом логи должны экспортироваться в SIEM. Microsoft не сразу ответила на запрос о комментарии.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Gyana Swain
