Az - Токени та Публічні Додатки

Reading time: 10 minutes

Основна Інформація

Entra ID - це хмарна платформа управління ідентифікацією та доступом (IAM) від Microsoft, яка слугує основною системою аутентифікації та авторизації для таких сервісів, як Microsoft 365 та Azure Resource Manager. Azure AD реалізує фреймворк авторизації OAuth 2.0 та протокол аутентифікації OpenID Connect (OIDC) для управління доступом до ресурсів.

OAuth

Ключові Учасники в OAuth 2.0:

1. Сервер Ресурсів (RS): Захищає ресурси, що належать власнику ресурсу.
2. Власник Ресурсу (RO): Зазвичай кінцевий користувач, який володіє захищеними ресурсами.
3. Клієнтський Додаток (CA): Додаток, що намагається отримати доступ до ресурсів від імені власника ресурсу.
4. Сервер Авторизації (AS): Видає токени доступу клієнтським додаткам після їх аутентифікації та авторизації.

Обсяги та Згода:

• Обсяги: Дрібні дозволи, визначені на сервері ресурсів, які вказують рівні доступу.
• Згода: Процес, за допомогою якого власник ресурсу надає клієнтському додатку дозвіл на доступ до ресурсів з конкретними обсягами.

Інтеграція з Microsoft 365:

• Microsoft 365 використовує Azure AD для IAM і складається з кількох "первинних" OAuth додатків.
• Ці додатки глибоко інтегровані та часто мають взаємозалежні відносини сервісів.
• Щоб спростити досвід користувачів і підтримувати функціональність, Microsoft надає "неявну згоду" або "попередню згоду" цим первинним додаткам.
• Неявна Згода: Деяким додаткам автоматично надається доступ до конкретних обсягів без явного схвалення користувача або адміністратора.
• Ці попередньо погоджені обсяги зазвичай приховані як від користувачів, так і від адміністраторів, що робить їх менш видимими в стандартних інтерфейсах управління.

Типи Клієнтських Додатків:

1. Конфіденційні Клієнти:

• Мають свої власні облікові дані (наприклад, паролі або сертифікати).
• Можуть надійно аутентифікувати себе на сервері авторизації.

2. Публічні Клієнти:

• Не мають унікальних облікових даних.
• Не можуть надійно аутентифікуватися на сервері авторизації.
• Безпекове Значення: Зловмисник може видавати себе за публічний клієнтський додаток при запиті токенів, оскільки немає механізму для сервера авторизації, щоб перевірити легітимність додатка.

Токени Аутентифікації

Існує три типи токенів, що використовуються в OIDC:

• Токени Доступу: Клієнт представляє цей токен серверу ресурсів для доступу до ресурсів. Він може використовуватися лише для конкретної комбінації користувача, клієнта та ресурсу і не може бути відкликаний до закінчення терміну дії - тобто 1 година за замовчуванням.
• ID Токени: Клієнт отримує цей токен від сервера авторизації. Він містить основну інформацію про користувача. Він прив'язаний до конкретної комбінації користувача та клієнта.
• Токени Оновлення: Надаються клієнту разом з токеном доступу. Використовуються для отримання нових токенів доступу та ID токенів. Він прив'язаний до конкретної комбінації користувача та клієнта і може бути відкликаний. За замовчуванням термін дії становить 90 днів для неактивних токенів оновлення та немає терміну дії для активних токенів (з токена оновлення можливо отримати нові токени оновлення).
• Токен оновлення повинен бути прив'язаний до aud, до деяких обсягів та до орендаря, і він повинен мати можливість генерувати токени доступу лише для цього aud, обсягів (і не більше) та орендаря. Однак це не так для токенів додатків FOCI.
• Токен оновлення зашифрований, і лише Microsoft може його розшифрувати.
• Отримання нового токена оновлення не відкликає попередній токен оновлення.

Токени Доступу "aud"

Поле, вказане в полі "aud", є сервером ресурсів (додатком), що використовується для виконання входу.

Команда az account get-access-token --resource-type [...] підтримує такі типи, і кожен з них додасть конкретний "aud" у результативний токен доступу:

Обсяги Токенів Доступу "scp"

Обсяг токена доступу зберігається всередині ключа scp всередині JWT токена доступу. Ці обсяги визначають, до чого має доступ токен доступу.

Якщо JWT дозволено контактувати з конкретним API, але не має обсягу для виконання запитуваної дії, він не зможе виконати дію з цим JWT.

Приклад отримання токена оновлення та доступу

# Code example from https://github.com/secureworks/family-of-client-ids-research
import msal
import requests
import jwt
from pprint import pprint
from typing import Any, Dict, List


# LOGIN VIA CODE FLOW AUTHENTICATION
azure_cli_client = msal.PublicClientApplication(
"04b07795-8ddb-461a-bbee-02f9e1bf7b46" # ID for Azure CLI client
)
device_flow = azure_cli_client.initiate_device_flow(
scopes=["https://graph.microsoft.com/.default"]
)
print(device_flow["message"])

# Perform device code flow authentication

azure_cli_bearer_tokens_for_graph_api = azure_cli_client.acquire_token_by_device_flow(
device_flow
)
pprint(azure_cli_bearer_tokens_for_graph_api)


# DECODE JWT
def decode_jwt(base64_blob: str) -> Dict[str, Any]:
"""Decodes base64 encoded JWT blob"""
return jwt.decode(
base64_blob, options={"verify_signature": False, "verify_aud": False}
)
decoded_access_token = decode_jwt(
azure_cli_bearer_tokens_for_graph_api.get("access_token")
)
pprint(decoded_access_token)


# GET NEW ACCESS TOKEN AND REFRESH TOKEN
new_azure_cli_bearer_tokens_for_graph_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
azure_cli_bearer_tokens_for_graph_api.get("refresh_token"),
# Same scopes as original authorization
scopes=["https://graph.microsoft.com/.default"],
)
)
pprint(new_azure_cli_bearer_tokens_for_graph_api)

Інші поля токена доступу

• appid: Ідентифікатор програми, що використовується для генерації токена
• appidacr: Посилання на клас контексту автентифікації програми вказує, як клієнт був автентифікований, для публічного клієнта значення дорівнює 0, а якщо використовується секрет клієнта, значення дорівнює 1
• acr: Заява про клас контексту автентифікації є "0", коли автентифікація кінцевого користувача не відповідала вимогам ISO/IEC 29115.
• amr: Метод автентифікації вказує, як токен був автентифікований. Значення “pwd” вказує на те, що був використаний пароль.
• groups: Вказує на групи, в яких є членом принципал.
• iss: Видавець ідентифікує службу безпеки токенів (STS), яка згенерувала токен. наприклад, https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (uuid - це ідентифікатор орендаря)
• oid: Ідентифікатор об'єкта принципала
• tid: Ідентифікатор орендаря
• iat, nbf, exp: Дата видачі (коли він був виданий), Не раніше (не може бути використаний до цього часу, зазвичай таке ж значення, як і iat), Час закінчення терміну дії.

Підвищення привілеїв токенів FOCI

Раніше згадувалося, що токени оновлення повинні бути прив'язані до областей, з якими вони були згенеровані, до програми та орендаря, для яких вони були згенеровані. Якщо будь-яка з цих меж буде порушена, можливо підвищити привілеї, оскільки буде можливим генерувати токени доступу до інших ресурсів і орендарів, до яких користувач має доступ, і з більшою кількістю областей, ніж це було спочатку передбачено.

Більше того, це можливо з усіма токенами оновлення в Microsoft identity platform (облікові записи Microsoft Entra, особисті облікові записи Microsoft та соціальні облікові записи, такі як Facebook і Google), оскільки, як зазначають документи: "Токени оновлення прив'язані до комбінації користувача та клієнта, але не прив'язані до ресурсу або орендаря. Клієнт може використовувати токен оновлення для отримання токенів доступу по будь-якій комбінації ресурсу та орендаря, де він має на це дозвіл. Токени оновлення зашифровані, і лише платформа ідентичності Microsoft може їх читати."

Крім того, зверніть увагу, що програми FOCI є публічними програмами, тому секрет не потрібен для автентифікації на сервері.

Тоді відомі клієнти FOCI, про які повідомлялося в оригінальному дослідженні, можуть бути знайдені тут.

Отримати різну область

Продовжуючи з попереднього прикладу коду, у цьому коді запитується новий токен для іншої області:

# Code from https://github.com/secureworks/family-of-client-ids-research
azure_cli_bearer_tokens_for_outlook_api = (
# Same client as original authorization
azure_cli_client.acquire_token_by_refresh_token(
new_azure_cli_bearer_tokens_for_graph_api.get(
"refresh_token"
),
# But different scopes than original authorization
scopes=[
"https://outlook.office.com/.default"
],
)
)
pprint(azure_cli_bearer_tokens_for_outlook_api)

Отримати різні клієнти та області

# Code from https://github.com/secureworks/family-of-client-ids-research
microsoft_office_client = msal.PublicClientApplication("d3590ed6-52b3-4102-aeff-aad2292ab01c")
microsoft_office_bearer_tokens_for_graph_api = (
# This is a different client application than we used in the previous examples
microsoft_office_client.acquire_token_by_refresh_token(
# But we can use the refresh token issued to our original client application
azure_cli_bearer_tokens_for_outlook_api.get("refresh_token"),
# And request different scopes too
scopes=["https://graph.microsoft.com/.default"],
)
)
# How is this possible?
pprint(microsoft_office_bearer_tokens_for_graph_api)

Де знайти токени

З точки зору атакуючого, дуже цікаво знати, де можна знайти токени доступу та оновлення, коли, наприклад, ПК жертви скомпрометовано:

• Всередині <HOME>/.Azure
• azureProfile.json містить інформацію про користувачів, які входили в систему раніше
• clouds.config містить інформацію про підписки
• service_principal_entries.json містить облікові дані додатків (ідентифікатор орендаря, клієнти та секрет). Тільки в Linux та macOS
• msal_token_cache.json містить токени доступу та токени оновлення. Тільки в Linux та macOS
• service_principal_entries.bin та msal_token_cache.bin використовуються в Windows і зашифровані за допомогою DPAPI
• msal_http_cache.bin є кешем HTTP запитів
• Завантажте його: with open("msal_http_cache.bin", 'rb') as f: pickle.load(f)
• AzureRmContext.json містить інформацію про попередні входи за допомогою Az PowerShell (але без облікових даних)
• Всередині C:\Users\<username>\AppData\Local\Microsoft\IdentityCache\* є кілька .bin файлів з токенами доступу, ID токенами та інформацією про облікові записи, зашифрованими за допомогою DPAPI користувача.
• Можна знайти більше токенів доступу у файлах .tbres всередині C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\, які містять base64 зашифровані за допомогою DPAPI токени доступу.
• У Linux та macOS ви можете отримати токени доступу, токени оновлення та ID токени з Az PowerShell (якщо використовувався), запустивши pwsh -Command "Save-AzContext -Path /tmp/az-context.json"
• У Windows це просто генерує ID токени.
• Можна перевірити, чи використовувався Az PowerShell в Linux та macOS, перевіривши, чи існує $HOME/.local/share/.IdentityService/ (хоча вміст файлів порожній і марний)
• Якщо користувач увійшов в Azure через браузер, відповідно до цього посту, можливо, розпочати процес аутентифікації з перенаправленням на localhost, змусити браузер автоматично авторизувати вхід і отримати токен оновлення. Зверніть увагу, що є лише кілька FOCI додатків, які дозволяють перенаправлення на localhost (як az cli або модуль PowerShell), тому ці додатки повинні бути дозволені.

Посилання

• https://github.com/secureworks/family-of-client-ids-research
• https://github.com/Huachao/azure-content/blob/master/articles/active-directory/active-directory-token-and-claims.md