Один токен, чтобы править всеми: получение прав глобального администратора в каждом клиенте Entra ID через Actor-токены

Во время подготовки к выступлениям на Black Hat и DEF CON в июле этого года я обнаружил самую серьёзную уязвимость в Entra ID, которую мне, вероятно, доведётся найти. Она позволяла скомпрометировать любого клиента Entra ID в мире (за исключением национальных облачных развёртываний). Уязвимость состояла из двух компонентов: недокументированных токенов олицетворения (Actor-токенов), используемых Microsoft для внутреннего межсервисного взаимодействия, и критической ошибки в устаревшем API Azure AD Graph, которая позволяла использовать эти токены для межклиентского доступа.

С помощью токена, полученного в моём тестовом клиенте, я мог аутентифицироваться от имени любого пользователя, включая глобальных администраторов, в любом другом клиенте. Actor-токены не подчиняются политикам безопасности вроде Conditional Access, поэтому не существовало настроек, способных смягчить угрозу. Доступ к API Azure AD Graph позволял вносить любые изменения в клиенте, которые доступны глобальным администраторам, включая создание новых учётных записей с любыми правами.

Я сообщил об уязвимости в MSRC в тот же день. Microsoft исправила её в течение нескольких дней и выпустила CVE-2025-55241.

Влияние

Токены предоставляли полный доступ к API Azure AD Graph в любом клиенте. Их запрос не оставлял журналов, а в целевом клиенте не было записей о существовании таких токенов. API Azure AD Graph не имеет журналирования на уровне API, поэтому следующие данные могли быть доступны без следов:

• Информация о пользователях, включая личные данные.
• Сведения о группах и ролях.
• Настройки клиента и политики.
• Данные приложений и сервисных субъектов.
• Информация об устройствах и ключах BitLocker.

При олицетворении глобального администратора можно было изменять любые объекты и настройки, что вело к полной компрометации клиента и доступу к таким службам, как SharePoint Online и Exchange Online, а также к ресурсам Azure. Хотя модификация объектов обычно оставляет журналы аудита, действия выглядели бы как легитимные действия администратора.

По данным телеметрии Microsoft, злоупотреблений этой уязвимостью обнаружено не было. Для поиска возможных артефактов злоупотребления в конце поста приведено KQL-правило.

Технические детали

Actor-токены выпускаются службой «Access Control Service» — устаревшим сервисом, используемым для аутентификации в приложениях SharePoint и внутренних службах Microsoft. Я обнаружил его при исследовании гибридных настроек Exchange, которые ранее использовали сертификаты для аутентификации Exchange Online.

• Обсуждение уязвимости в Entra ID, позволяющей обход проверок и несанкционированный доступ к данным других тенантов.
• Критика сложности атаки (CVSS: High) как завышенной, учитывая, что для эксплуатации требуются лишь базовые знания Entra ID.
• Указание на системную проблему Microsoft: наслоение нового кода на устаревшие API без должного тестирования их взаимодействия.
• Сравнение уязвимости с ранее известными инцидентами безопасности в продуктах Microsoft и мнение о слабой безопасности системы.
• Обсуждение проблем дизайна Entra ID: сложность создания тенанта, путаница с типами учетных записей и устаревшая документация.
• Критика использования долгоживущих токенов с широкими правами (Actor tokens), игнорирующих политики безопасности.
• Замечание о том, что корпоративные клиенты вынуждают Microsoft поддерживать устаревший код, усугубляя проблемы безопасности.

SSO Wall of Shame — список вендоров, считающих SSO роскошью, а не базовой безопасностью.

SSO позволяет компании управлять доступом через собственный поставщик идентификации (Google, Okta, Azure AD), централизованно создавать/удалять аккаунты и мгновенно отключать уволенных сотрудников. Для любой организации >5 человек это критично.

Однако вендоры прячут SSO за «Enterprise»-тарифами, где цена выше в 2–4 раза или привязана к большому пакету ненужных функций. Это тормозит внедрение безопасности.

Примеры завышенных надбавок

Вендор	Базовая цена	SSO-цена	Рост
Airtable	$10/польз./мес	$60	+500 %
Appsmith	$15	$2 500	+16 567 %
Coursera	$399/польз./год	$49 875/год	+12 400 %
Cloudflare	$20/домен/мес	$1 000	+4 900 %
Breezy HR	$171/мес	$1 500	+777 %
DatoCMS	$100/мес	$667	+567 %
Canva	$10/польз./мес	$40	+300 %
Figma	$12	$45	+275 %
Bitrise	$90	$270	+200 %
Box	$5	$15	+200 %

(и ещё ~30 компаний с ростом 15–167 %).

Вывод: если вендор «серьёзно относится к безопасности», SSO должен быть либо в базе, либо за умеренную доплату.

• «SSO-налог» — это не техническая, а ценовая сегментация: крупные клиенты обязаны иметь SSO (SOC2), поэтому за него платят.
• Поддержка SSO действительно дорога: множество тикетов, сложные интеграции, вызовы инженеров, особенно при частных IdP.
• Часть вендоров всё же даёт базовый SSO через Google/GitHub/Microsoft, но «частный IdP» остаётся маркером Enterprise.
• Малым компаниям SSO тоже нужен по контрактам, но высокие цены отталкивают; кто-то предлагает субсидии или прокси-решения.
• Итог: SSO = не «фича», а показатель зрелости клиента и объём его кошелька.

Кратко о PR #3899
Добавлена поддержка SSO через OpenID Connect (OIDC) в Vaultwarden.

• Что нового

  • Авторизация через внешний OIDC-провайдер (Keycloak, Azure AD, Google и др.).
  • Автоматическое создание/обновление пользователей при первом входе.
  • Настройка через переменные окружения: SSO_ENABLED, SSO_AUTHORITY, SSO_CLIENT_ID, SSO_CLIENT_SECRET.
  • Поддержка PKCE и offline_access для refresh-токенов.

• Как использовать

  1. Указать параметры OIDC в .env.
  2. Включить SSO в админ-панели.
  3. Пользователи входят кнопкой «Login with SSO».

• Ограничения

  • Только веб-клиент; мобильные/CLI пока без SSO.
  • Не работает с двухфакторной аутентификацией Vaultwarden (используйте MFA у провайдера).

• Проверено

  • Keycloak, Auth0, Azure AD, Google Workspace.

PR готов к слиянию; дальнейшие улучшения (SAML, группы) в roadmap.

• Внедрённый SSO в Vaultwarden в первую очередь нужен корпоративным и командным средам, где упрощает автоматическое добавление/удаление пользователей и управление доступом к коллекциям паролей.
• Для личного или семейного использования польза минимальна: мастер-пароль всё равно требуется, а SSO не заменяет шифрование.
• Многие админы некоммерческих и малых организаций рады возможности подключить единый OIDC-провайдер вместо ручного приглашения и отслеживания активных волонтёров/сотрудников.
• Часть пользователей обеспокоена безопасностью: просят аудитов, контроля образов Docker и зависимостей.
• SSO не отменяет мастер-пароль: он по-прежнему нужен для расшифровки хранилища, а SSO лишь аутентифицирует пользователя.