Az - Tokens & Public Applications
Last updated
Last updated
Вивчайте та практикуйте Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте Hacking GCP: 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.
Раніше згадувалося, що refresh tokens повинні бути прив'язані до scopes, з якими вони були згенеровані, до application та tenant, для яких вони були згенеровані. Якщо будь-яка з цих меж буде порушена, можливо підвищити привілеї, оскільки буде можливість генерувати access tokens для інших ресурсів і tenants, до яких користувач має доступ, і з більшими scopes, ніж це було спочатку передбачено.
Більше того, це можливо з усіма refresh tokens у Microsoft identity platform (Microsoft Entra accounts, Microsoft personal accounts та соціальні акаунти, такі як Facebook і Google), оскільки, як зазначають документи: "Refresh tokens прив'язані до комбінації користувача та клієнта, але не прив'язані до ресурсу або tenant. Клієнт може використовувати refresh token для отримання access tokens для будь-якої комбінації ресурсу та tenant, де він має на це дозвіл. Refresh tokens зашифровані, і лише Microsoft identity platform може їх читати."
Крім того, зверніть увагу, що FOCI applications є публічними додатками, тому секрет не потрібен для автентифікації на сервері.
Тоді відомі FOCI клієнти, про які повідомлялося в оригінальному дослідженні, можуть бути знайдені тут.
Продовжуючи з попереднього прикладу коду, у цьому коді запитується новий токен для іншого scope:
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)