Az - Tokens & Public Applications
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID - це хмарна платформа управління ідентифікацією та доступом (IAM) від Microsoft, яка слугує основною системою аутентифікації та авторизації для таких сервісів, як Microsoft 365 та Azure Resource Manager. Azure AD реалізує фреймворк авторизації OAuth 2.0 та протокол аутентифікації OpenID Connect (OIDC) для управління доступом до ресурсів.
Ключові Учасники в OAuth 2.0:
Сервер Ресурсів (RS): Захищає ресурси, що належать власнику ресурсу.
Власник Ресурсу (RO): Зазвичай кінцевий користувач, який володіє захищеними ресурсами.
Клієнтський Додаток (CA): Додаток, що намагається отримати доступ до ресурсів від імені власника ресурсу.
Сервер Авторизації (AS): Видає токени доступу клієнтським додаткам після їх аутентифікації та авторизації.
Обсяги та Згода:
Обсяги: Дрібні дозволи, визначені на сервері ресурсів, які вказують рівні доступу.
Згода: Процес, за допомогою якого власник ресурсу надає клієнтському додатку дозвіл на доступ до ресурсів з конкретними обсягами.
Інтеграція з Microsoft 365:
Microsoft 365 використовує Azure AD для IAM і складається з кількох "первинних" OAuth додатків.
Ці додатки глибоко інтегровані та часто мають взаємозалежні відносини сервісів.
Щоб спростити досвід користувачів і підтримувати функціональність, Microsoft надає "неявну згоду" або "попередню згоду" цим первинним додаткам.
Неявна Згода: Деяким додаткам автоматично надається доступ до конкретних обсягів без явного схвалення користувача або адміністратора.
Ці попередньо погоджені обсяги зазвичай приховані як від користувачів, так і від адміністраторів, що робить їх менш видимими в стандартних інтерфейсах управління.
Типи Клієнтських Додатків:
Конфіденційні Клієнти:
Мають свої власні облікові дані (наприклад, паролі або сертифікати).
Можуть надійно аутентифікувати себе на сервері авторизації.
Публічні Клієнти:
Не мають унікальних облікових даних.
Не можуть надійно аутентифікуватися на сервері авторизації.
Безпекове Значення: Зловмисник може видавати себе за публічний клієнтський додаток при запиті токенів, оскільки немає механізму для перевірки легітимності додатка на сервері авторизації.
Існує три типи токенів, що використовуються в OIDC:
Токени Доступу: Клієнт представляє цей токен серверу ресурсів для доступу до ресурсів. Він може використовуватися лише для конкретної комбінації користувача, клієнта та ресурсу і не може бути відкликаний до закінчення терміну дії - за замовчуванням це 1 година.
ID Токени: Клієнт отримує цей токен від сервера авторизації. Він містить основну інформацію про користувача. Він прив'язаний до конкретної комбінації користувача та клієнта.
Токени Оновлення: Надаються клієнту разом з токеном доступу. Використовуються для отримання нових токенів доступу та ID токенів. Він прив'язаний до конкретної комбінації користувача та клієнта і може бути відкликаний. За замовчуванням термін дії становить 90 днів для неактивних токенів оновлення та немає терміну дії для активних токенів (з токена оновлення можливо отримати нові токени оновлення).
Токен оновлення повинен бути прив'язаний до aud
, до деяких обсягів та до орендаря, і він повинен мати можливість генерувати токени доступу лише для цього aud, обсягів (і не більше) та орендаря. Однак це не так для токенів додатків FOCI.
Токен оновлення зашифрований, і лише Microsoft може його розшифрувати.
Отримання нового токена оновлення не відкликає попередній токен оновлення.
Інформація для умовного доступу зберігається всередині JWT. Тому, якщо ви запитуєте токен з дозволеної IP-адреси, ця IP буде збережена в токені, і тоді ви зможете використовувати цей токен з недозволеної IP для доступу до ресурсів.
Поле, вказане в полі "aud", є сервером ресурсів (додатком), що використовується для виконання входу.
Команда az account get-access-token --resource-type [...]
підтримує такі типи, і кожен з них додасть конкретний "aud" у результативний токен доступу:
Зверніть увагу, що наступні є лише API, підтримуваними az account get-access-token
, але їх більше.
Обсяг токена доступу зберігається всередині ключа scp в JWT токена доступу. Ці обсяги визначають, до чого має доступ токен доступу.
Якщо JWT дозволено контактувати з конкретним API, але не має обсягу для виконання запитаної дії, він не зможе виконати цю дію з цим JWT.
Раніше згадувалося, що токени оновлення повинні бути прив'язані до областей (scopes), з якими вони були згенеровані, до додатку та орендаря (tenant), для якого вони були згенеровані. Якщо будь-яка з цих меж буде порушена, можливо підвищити привілеї, оскільки буде можливість генерувати токени доступу до інших ресурсів і орендарів, до яких користувач має доступ, і з більшою кількістю областей, ніж це було спочатку передбачено.
Більше того, це можливо з усіма токенами оновлення в Microsoft identity platform (облікові записи Microsoft Entra, особисті облікові записи Microsoft та соціальні облікові записи, такі як Facebook і Google), оскільки, як зазначено в документації: "Токени оновлення прив'язані до комбінації користувача та клієнта, але не прив'язані до ресурсу або орендаря. Клієнт може використовувати токен оновлення для отримання токенів доступу в будь-якій комбінації ресурсу та орендаря, де він має на це дозвіл. Токени оновлення зашифровані, і лише платформа ідентичності Microsoft може їх читати."
Крім того, зверніть увагу, що FOCI додатки є публічними додатками, тому секрет не потрібен для автентифікації на сервері.
Тоді відомі клієнти FOCI, про які повідомлялося в оригінальному дослідженні, можуть бути знайдені тут.
Продовжуючи з попереднього прикладу коду, у цьому коді запитується новий токен для іншої області:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)