Уязвимость CVE-2025-29827 в Azure Automation получила оценку 9,9 из 10 по шкале CVSS и в худшем сценарии позволяла атакующему выйти за пределы своего тенанта и перехватить управляемое удостоверение другой организации. Для компаний, которые держат в Azure развертывание, обновления, ротацию секретов и служебные сценарии, это уже не рядовая облачная ошибка, а потенциальный вход в чужую инфраструктуру через доверенную автоматизацию.
О проблеме написал Dark Reading со ссылкой на исследователя Microsoft Шая Шавита. Сам бюллетень MSRC по этой уязвимости Microsoft опубликовала 8 мая 2025 года, а публично тему снова подняли перед выступлением на Black Hat USA 2026. По словам Шавита, известных случаев эксплуатации не зафиксировали, но Microsoft уже изменила поведение по умолчанию: конечная точка учетной записи Azure Automation больше не должна быть публичной по умолчанию.
Как работала цепочка атаки
Проблема была не в одном баге, а в неудачной комбинации настроек и логики сервиса. Исследователи описали цепочку из трех элементов: публичной доступности учетных записей Azure Automation по умолчанию и еще двух отдельных дефектов в коде. По отдельности такие находки часто выглядят как неприятный, но ограниченный риск. Вместе они позволяли пересечь границу между тенантами.
Сценарий атаки выглядел так: злоумышленнику было достаточно иметь доступ к собственной учетной записи Azure Automation, после чего он мог попытаться присвоить управляемое удостоверение чужой учетной записи. А дальше все упиралось уже не в сам сервис, а в выданные этому удостоверению права. Если сценарии автоматизации имели доступ к конфигурации, секретам, виртуальным машинам, Key Vault или другим ресурсам подписки, атакующий получал тот же набор полномочий.
Это особенно неприятно потому, что Azure Automation редко живет на периферии инфраструктуры. Обычно через него крутят развертывание ресурсов, обслуживание, обновления и ротацию учетных данных. Иначе говоря, сервис часто работает с широкими правами и видит то, что обычному пользователю видеть не положено.
Чем эта история отличается от AutoWarp
Шавит отдельно сравнивает свою находку с AutoWarp — известной уязвимостью в Azure Automation, о которой Orca Security рассказала в 2021 году, а Microsoft публично сообщила в марте 2022-го. Тогда речь шла о краже токенов управляемого удостоверения из общего сервера-песочницы. В случае с CVE-2025-29827 ключевую роль сыграли не выполнение кода, а цепочка из публичной доступности и логических дефектов сервиса.
Разница важная: такие инциденты показывают, что в облаке самые дорогие атаки все чаще строятся не вокруг классического удаленного выполнения кода, а вокруг доверительных связей, токенов и служебных удостоверений. Для атакующего это даже удобнее: если получилось перехватить сильное удостоверение, дальше можно работать через портал Azure, CLI или API почти как штатный администратор.
Что это значит для компаний на Azure
Для русскоязычных команд, которые используют Azure в международных проектах, вывод вполне приземленный. Внешнюю доступность служебных интерфейсов стоит считать исключением, а не нормой. Права управляемых удостоверений для автоматизации нужно пересматривать так же жестко, как права сотрудников. И, пожалуй, главный урок: опасно оценивать уязвимости поодиночке. Один средний дефект рядом с неудачной настройкой по умолчанию и лишними правами быстро превращается в критическую цепочку атаки.
Для ИТ-руководителей и платформенных команд это еще один сигнал заняться инвентаризацией служебных удостоверений: где они используются, какие роли получили и какие из них доступны извне. В облаке такие сущности часто получают слишком много власти просто потому, что так удобнее запустить автоматизацию. А потом выясняется, что именно этот «временный» сценарий и держит половину рабочей среды.
Следующий шаг для защитников очевиден: смотреть не только на отдельную CVE, но и на полный путь атаки. Оригинал: Dark Reading; карточка уязвимости: NVD.