Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID est la plateforme de gestion des identités et des accès (IAM) basée sur le cloud de Microsoft, servant de système d'authentification et d'autorisation fondamental pour des services comme Microsoft 365 et Azure Resource Manager. Azure AD implémente le cadre d'autorisation OAuth 2.0 et le protocole d'authentification OpenID Connect (OIDC) pour gérer l'accès aux ressources.
Participants clés dans OAuth 2.0 :
Serveur de ressources (RS) : Protège les ressources appartenant au propriétaire des ressources.
Propriétaire des ressources (RO) : Typiquement un utilisateur final qui possède les ressources protégées.
Application cliente (CA) : Une application cherchant à accéder aux ressources au nom du propriétaire des ressources.
Serveur d'autorisation (AS) : Délivre des jetons d'accès aux applications clientes après les avoir authentifiées et autorisées.
Scopes et consentement :
Scopes : Permissions granulaires définies sur le serveur de ressources qui spécifient les niveaux d'accès.
Consentement : Le processus par lequel un propriétaire de ressources accorde à une application cliente la permission d'accéder aux ressources avec des scopes spécifiques.
Intégration Microsoft 365 :
Microsoft 365 utilise Azure AD pour l'IAM et est composé de plusieurs applications OAuth "de première partie".
Ces applications sont profondément intégrées et ont souvent des relations de service interdépendantes.
Pour simplifier l'expérience utilisateur et maintenir la fonctionnalité, Microsoft accorde un "consentement implicite" ou un "pré-consentement" à ces applications de première partie.
Consentement implicite : Certaines applications se voient automatiquement accorder l'accès à des scopes spécifiques sans approbation explicite de l'utilisateur ou de l'administrateur.
Ces scopes pré-consentis sont généralement cachés à la fois des utilisateurs et des administrateurs, les rendant moins visibles dans les interfaces de gestion standard.
Types d'applications clientes :
Clients confidentiels :
Possèdent leurs propres identifiants (par exemple, mots de passe ou certificats).
Peuvent s'authentifier de manière sécurisée auprès du serveur d'autorisation.
Clients publics :
N'ont pas d'identifiants uniques.
Ne peuvent pas s'authentifier de manière sécurisée auprès du serveur d'autorisation.
Implication de sécurité : Un attaquant peut usurper une application cliente publique lors de la demande de jetons, car il n'existe aucun mécanisme pour que le serveur d'autorisation vérifie la légitimité de l'application.
Il existe trois types de jetons utilisés dans OIDC :
Jetons d'accès: Le client présente ce jeton au serveur de ressources pour accéder aux ressources. Il ne peut être utilisé que pour une combinaison spécifique d'utilisateur, de client et de ressource et ne peut pas être révoqué jusqu'à son expiration - c'est-à-dire 1 heure par défaut.
Jetons d'identité : Le client reçoit ce jeton du serveur d'autorisation. Il contient des informations de base sur l'utilisateur. Il est lié à une combinaison spécifique d'utilisateur et de client.
Jetons de rafraîchissement : Fournis au client avec le jeton d'accès. Utilisés pour obtenir de nouveaux jetons d'accès et d'identité. Il est lié à une combinaison spécifique d'utilisateur et de client et peut être révoqué. L'expiration par défaut est de 90 jours pour les jetons de rafraîchissement inactifs et pas d'expiration pour les jetons actifs (il est possible d'obtenir de nouveaux jetons de rafraîchissement à partir d'un jeton de rafraîchissement).
Un jeton de rafraîchissement doit être lié à un aud, à certains scopes, et à un tenant et il ne devrait pouvoir générer des jetons d'accès que pour cet aud, ces scopes (et pas plus) et ce tenant. Cependant, ce n'est pas le cas avec les jetons d'applications FOCI.
Un jeton de rafraîchissement est crypté et seul Microsoft peut le déchiffrer.
Obtenir un nouveau jeton de rafraîchissement ne révoque pas le jeton de rafraîchissement précédent.
Les informations pour l'accès conditionnel sont stockées à l'intérieur du JWT. Donc, si vous demandez le jeton depuis une adresse IP autorisée, cette IP sera stockée dans le jeton et vous pourrez utiliser ce jeton depuis une adresse IP non autorisée pour accéder aux ressources.
Le champ indiqué dans le champ "aud" est le serveur de ressources (l'application) utilisé pour effectuer la connexion.
La commande az account get-access-token --resource-type [...] prend en charge les types suivants et chacun d'eux ajoutera un "aud" spécifique dans le jeton d'accès résultant :
Notez que les éléments suivants ne sont que les API prises en charge par az account get-access-token, mais il y en a d'autres.
Le scope d'un jeton d'accès est stocké à l'intérieur de la clé scp dans le JWT du jeton d'accès. Ces scopes définissent à quoi le jeton d'accès a accès.
Si un JWT est autorisé à contacter une API spécifique mais n'a pas le scope pour effectuer l'action demandée, il ne pourra pas effectuer l'action avec ce JWT.
Il a été mentionné précédemment que les jetons d'actualisation doivent être liés aux portées avec lesquelles ils ont été générés, à l'application et au locataire pour lesquels ils ont été générés. Si l'une de ces limites est franchie, il est possible d'escalader les privilèges car il sera possible de générer des jetons d'accès pour d'autres ressources et locataires auxquels l'utilisateur a accès et avec plus de portées que ce qui était initialement prévu.
De plus, cela est possible avec tous les jetons d'actualisation dans la plateforme d'identité Microsoft (comptes Microsoft Entra, comptes personnels Microsoft et comptes sociaux comme Facebook et Google) car comme le mentionnent les docs : "Les jetons d'actualisation sont liés à une combinaison d'utilisateur et de client, mais ne sont pas liés à une ressource ou à un locataire. Un client peut utiliser un jeton d'actualisation pour acquérir des jetons d'accès à travers n'importe quelle combinaison de ressource et de locataire où il a la permission de le faire. Les jetons d'actualisation sont cryptés et seule la plateforme d'identité Microsoft peut les lire."
De plus, notez que les applications FOCI sont des applications publiques, donc aucun secret n'est nécessaire pour s'authentifier auprès du serveur.
Ensuite, les clients FOCI connus rapportés dans la recherche originale peuvent être trouvés ici.
En suivant l'exemple de code précédent, dans ce code, un nouveau jeton est demandé pour une portée différente :
Apprenez et pratiquez le hacking AWS :HackTricks Formation Expert Red Team AWS (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Formation Expert Red Team GCP (GRTE)
