Az - Federation
Informations de base
À partir de la documentation :La fédération est un ensemble de domaines qui ont établi une confiance. Le niveau de confiance peut varier, mais inclut généralement l'authentification et inclut presque toujours l'autorisation. Une fédération typique peut inclure un certain nombre d'organisations qui ont établi une confiance pour un accès partagé à un ensemble de ressources.
Vous pouvez fédérer votre environnement sur site avec Azure AD et utiliser cette fédération pour l'authentification et l'autorisation. Cette méthode de connexion garantit que toute authentification de l'utilisateur se fait sur site. Cette méthode permet aux administrateurs de mettre en place des niveaux de contrôle d'accès plus rigoureux. La fédération avec AD FS et PingFederate est disponible.
En gros, dans la fédération, toute authentification se fait dans l'environnement sur site et l'utilisateur bénéficie d'un SSO dans tous les environnements de confiance. Par conséquent, les utilisateurs peuvent accéder aux applications cloud en utilisant leurs identifiants sur site.
Le Security Assertion Markup Language (SAML) est utilisé pour échanger toutes les informations d'authentification et d'autorisation entre les fournisseurs.
Dans toute configuration de fédération, il y a trois parties :
Utilisateur ou Client
Fournisseur d'identité (IdP)
Fournisseur de services (SP)
(Images de https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
Initialement, une application (Fournisseur de services ou SP, tel que la console AWS ou le client web vSphere) est accédée par un utilisateur. Cette étape peut être contournée, conduisant le client directement vers l'IdP (Fournisseur d'identité) en fonction de l'implémentation spécifique.
Ensuite, le SP identifie l'IdP approprié (par exemple, AD FS, Okta) pour l'authentification de l'utilisateur. Il crée ensuite une demande d'authentification SAML (Security Assertion Markup Language) et redirige le client vers l'IdP choisi.
L'IdP prend le relais, authentifiant l'utilisateur. Après l'authentification, une réponse SAML est formulée par l'IdP et transmise au SP via l'utilisateur.
Enfin, le SP évalue la réponse SAML. Si la validation est réussie, impliquant une relation de confiance avec l'IdP, l'utilisateur obtient l'accès. Cela marque la fin du processus de connexion, permettant à l'utilisateur d'utiliser le service.
Si vous souhaitez en savoir plus sur l'authentification SAML et les attaques courantes, rendez-vous sur :
Pivotage
AD FS est un modèle d'identité basé sur les revendications.
"..les revendications sont simplement des déclarations (par exemple, nom, identité, groupe) faites sur les utilisateurs, qui sont principalement utilisées pour autoriser l'accès aux applications basées sur les revendications situées n'importe où sur Internet."
Les revendications pour un utilisateur sont écrites à l'intérieur des jetons SAML et sont ensuite signées pour assurer la confidentialité par l'IdP.
Un utilisateur est identifié par ImmutableID. Il est globalement unique et stocké dans Azure AD.
L'ImmutableID est stocké sur site en tant que ms-DS-ConsistencyGuid pour l'utilisateur et/ou peut être dérivé du GUID de l'utilisateur.
Attaque Golden SAML :
Dans ADFS, la réponse SAML est signée par un certificat de signature de jeton.
Si le certificat est compromis, il est possible de s'authentifier sur Azure AD en tant que N'IMPORTE QUEL utilisateur synchronisé avec Azure AD !
Tout comme notre abus de PTA, le changement de mot de passe pour un utilisateur ou la MFA n'aura aucun effet car nous forgeons la réponse d'authentification.
Le certificat peut être extrait du serveur AD FS avec des privilèges DA et peut ensuite être utilisé à partir de n'importe quelle machine connectée à Internet.
Golden SAML
Le processus où un Fournisseur d'identité (IdP) produit une Réponse SAML pour autoriser la connexion de l'utilisateur est primordial. Selon l'implémentation spécifique de l'IdP, la réponse peut être signée ou chiffrée à l'aide de la clé privée de l'IdP. Cette procédure permet au Fournisseur de services (SP) de confirmer l'authenticité de la Réponse SAML, garantissant qu'elle a bien été émise par un IdP de confiance.
Une analogie peut être faite avec l'attaque du golden ticket, où la clé authentifiant l'identité et les autorisations de l'utilisateur (KRBTGT pour les golden tickets, clé privée de signature de jeton pour les golden SAML) peut être manipulée pour fausser un objet d'authentification (TGT ou Réponse SAML). Cela permet l'usurpation de n'importe quel utilisateur, accordant un accès non autorisé au SP.
Les Golden SAML offrent certains avantages :
Ils peuvent être créés à distance, sans avoir besoin de faire partie du domaine ou de la fédération en question.
Ils restent efficaces même avec l'authentification à deux facteurs (2FA) activée.
La clé privée de signature de jeton ne se renouvelle pas automatiquement.
Changer le mot de passe d'un utilisateur n'invalide pas une Réponse SAML déjà générée.
AWS + AD FS + Golden SAML
Active Directory Federation Services (AD FS) est un service Microsoft qui facilite l'échange sécurisé d'informations d'identité entre des partenaires commerciaux de confiance (fédération). Il permet essentiellement à un service de domaine de partager les identités des utilisateurs avec d'autres fournisseurs de services au sein d'une fédération.
Avec AWS faisant confiance au domaine compromis (dans une fédération), cette vulnérabilité peut être exploitée pour potentiellement acquérir toutes les autorisations dans l'environnement AWS. L'attaque nécessite la clé privée utilisée pour signer les objets SAML, similaire au besoin du KRBTGT dans une attaque de golden ticket. L'accès au compte utilisateur AD FS est suffisant pour obtenir cette clé privée.
Les exigences pour exécuter une attaque Golden SAML comprennent :
Clé privée de signature de jeton
Certificat public de l'IdP
Nom de l'IdP
Nom du rôle (rôle à assumer)
Domaine\nom d'utilisateur
Nom de session de rôle dans AWS
ID de compte Amazon
Seuls les éléments en gras sont obligatoires. Les autres peuvent être remplis selon les besoins.
Pour acquérir la clé privée, l'accès au compte utilisateur AD FS est nécessaire. À partir de là, la clé privée peut être exportée depuis le magasin personnel en utilisant des outils comme mimikatz. Pour obtenir les autres informations requises, vous pouvez utiliser le module d'extension Microsoft.Adfs.Powershell comme suit, en vous assurant d'être connecté en tant qu'utilisateur AD FS :
Avec toutes les informations, il est possible d'oublier une SAMLResponse valide en tant qu'utilisateur que vous souhaitez impersonner en utilisant shimit:
Sur site -> cloud
Il est également possible de créer un ImmutableID pour les utilisateurs uniquement dans le cloud et de les impersonner
Références
Dernière mise à jour