Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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 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)
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.
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.
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.
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:
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 el local como ms-DS-ConsistencyGuid para el usuario y/o puede derivarse del GUID del usuario.
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.
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 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 SAMLResponse, asegurando que fue emitida por un IdP de confianza.
Se puede trazar 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) 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.
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 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 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:
Con toda la información, es posible olvidar una SAMLResponse válida como el usuario que deseas suplantar usando shimit:
También es posible crear ImmutableID de usuarios solo en la nube e impersonarlos.
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)
