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 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.
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.
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.
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.
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.
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í.
Siguiendo con el código de ejemplo anterior, en este código se solicita un nuevo token para un alcance diferente:
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)
