Par Mauricio Payne, Analyste sécurité chez Bureau Veritas Cybersecurity

Compromettre le cloud Azure par le biais d'autorisations d'API sensibles

Récemment, les chercheurs de Cloudbrothers ont trouvé une nouvelle façon intéressante de passer d'un environnement sur site à un environnement Azure et d'obtenir des droits d'administrateur global. Dans ce blog, nous allons vous donner une démonstration et une explication de cette attaque. En outre, des mesures d'atténuation seront incluses pour vous aider à détecter et à vous protéger contre cette attaque.

Démonstration du cheminement de l'attaque

Les chercheurs de Cloudbrothers ont découvert qu'un attaquant qui a réussi à compromettre le compte AAD Sync utilisé par le serveur AD Connect peut élever ses privilèges au niveau d'administrateur global en exploitant des applications dotées d'autorisations sensibles.

Ceci est possible car le compte AAD Sync possède les permissions 'microsoft.directory/applications/owners/update' et 'microsoft.directory/servicePrincipals/owners/update'. Cela lui permet de mettre à jour les propriétaires des applications enregistrées.
En outre, en utilisant les autorisations "microsoft.directory/servicePrincipals/credentials/update" , ce compte peut directement ajouter des identifiants à ces applications sans devoir d'abord s'ajouter lui-même en tant que propriétaire.
Ces applications peuvent alors être utilisées pour escalader les privilèges si elles disposent des autorisations correctes.

Dans ce blog, nous nous concentrerons sur deux de ces autorisations sensibles ('RoleManagement.ReadWrite.Directory' et 'AppRoleAssignment.ReadWrite.All') et démontrerons le chemin d'attaque qu'un attaquant devrait suivre en décrivant chaque étape.

Avant de commencer

Avant de commencer, il est important d'aborder certaines hypothèses qui ont été faites pour réaliser cette attaque.

• La première étant qu'une application est enregistrée sur Azure qui contient l'une des deux permissions sensibles mentionnées précédemment.
• La deuxième hypothèse est que vous avez réussi à compromettre complètement le serveur qui exécute AD Connect et que vous avez pu extraire les identifiants du compte AAD Sync. L'extraction des identifiants peut se faire par différentes méthodes, par exemple en utilisant le module PowerShell AADInternals. L'utilisation de Get-AADIntSyncCredentials sur le serveur AD Connect renvoie les identifiants de l'utilisateur AAD Sync :

Une fois ces identifiants capturés, nous pouvons passer à l'attaque principale proprement dite. La première étape consiste à s'authentifier auprès du locataire en tant qu'utilisateur AAD Sync :

Muni de ce jeton JWT, nous pouvons maintenant faire des appels à l'API Microsoft Graph et obtenir une liste de toutes les applications enregistrées sur le locataire. Ce jeton JWT peut être enregistré dans une variable PowerShell qui peut être utilisée comme en-tête d'authentification :

$AuthHeader = @{Authorization = "Bearer <JWT>"}

En procédant de la sorte, nous pouvons ensuite envoyer une requête au point de terminaison beta/applications à l'aide de PowerShell :

Invoke-RestMethod -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/applications/"

En examinant cette réponse, nous voyons beaucoup d'informations concernant les différentes applications. Cependant, ce qui est important pour nous dans cette attaque est le champ "appID". Ces identifiants doivent être enregistrés dans une liste car ils sont nécessaires pour l'étape suivante de l'attaque. Dans cette étape, nous utiliserons l'appID pour faire une requête à l'API Graph et demander quels sont les principaux services qui appartiennent à cette application.

Ci-dessous, nous pouvons voir la réponse d'une telle requête qui contient l'ID du principal de service appartenant à l'application avec l'appID 8c3ffdc3-fe9d-47a2-9bbc-3bc49e486c43. Cette demande peut être effectuée via PowerShell avec la commande suivante :

Invoke-RestMethod -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/?`$filter=(appid eq '<appID>')"

Une fois que nous avons l'ID de ces principaux services, nous pouvons rechercher les permissions qui leur sont attribuées. Plus précisément, nous recherchons une permission avec un appRoleID de "9e3f62cf-ca93-4989-b6ce- bf83c28f9fe8" qui correspond au rôle RoleManagement.ReadWrite.Directory ou l'appRoleID de "06b708a9-e830-4db3-a914-8e69da51d44f" qui correspond au rôle AppRoleAssignment.ReadWrite.All.

ROLEMANAGEMENT.READWRITE.DIRECTORY

Le rôle RoleManagement.ReadWrite.Directory permet à l'application d'accorder des privilèges supplémentaires à elle-même, à d'autres applications ou à n'importe quel utilisateur. En effectuant la requête suivante, nous pouvons obtenir les autorisations attribuées au principal de service dont l'identifiant est : "9e666f83-8520-4c65- a8e2-e929194839ea".

Invoke-RestMethod -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/<ServicePrincipalID>/appRoleAssignments"

Dans l'image ci-dessous, nous pouvons voir la réponse à la requête effectuée ci-dessus. En regardant la réponse, nous voyons l'appRoleId mentionné ci-dessus, ce qui rend cette application vulnérable à cette attaque.

Une fois que nous avons trouvé une application qui a ce rôle défini, nous pouvons ajouter notre utilisateur (dans ce cas l'utilisateur AAD Sync) en tant que propriétaire de ce principal de service. En PowerShell, la requête ressemblerait à ceci :

$Reference = @{ "@odata.id" = "https://graph.microsoft.com/beta/directoryObjects/" + <AAD Sync userID> } | ConvertTo-Json

Invoke-RestMethod -Method Post -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/<ServicePrincipalToTakeover>/owners/`$ref" - Body $Reference -ContentType "application/json" | Out-Null

La réponse à cette requête ressemblerait à ceci :

L'étape suivante consiste à ajouter un nouveau secret au principal du service, que nous utiliserons ultérieurement pour nous authentifier auprès du locataire en tant qu'application vulnérable. Une requête POST est faite à l'API Graph qui définit automatiquement un mot de passe sécurisé et le renvoie dans le paramètre "secretText". Cette opération est réalisée à l'aide de la commande PowerShell suivante :

Invoke-RestMethod -Method Post -Headers $AuthHeader -Uri "https://graph.microsoft.com/beta/servicePrincipals/<ServicePrincipalToTakeover>/addPassword" -Body $Reference -ContentType "application/json"

Comme vous pouvez le voir ci-dessous, l'API renvoie le texte du secret :

En utilisant l'appID de l'application vulnérable comme "Client_Id" et le nouveau secret ajouté comme"Client_Secret", nous pouvons nous authentifier auprès du locataire en tant que principal de service et recevoir un nouveau jeton JWT.

APPROLEASSIGNMENT.READWRITE.ALL

Le rôle AppRoleAssignment.ReadWrite.All permet à l'application de s'octroyer des privilèges supplémentaires. Cela signifie que nous pourrions accorder le rôle RoleManagement.ReadWrite.Directory à l'application et obtenir des privilèges d'administrateur global. Vous pouvez voir ci-dessous une image où nous identifions une application vulnérable avec ce rôle :

Une fois que nous avons identifié cette application, nous pouvons lui ajouter un secret que nous utiliserons pour nous authentifier en tant qu'application auprès du locataire Azure :

Comme nous l'avons vu précédemment, le mot de passe est renvoyé en tant que paramètre "secretText" que nous utiliserons en combinaison avec l'appID pour nous authentifier auprès du locataire :

Cela renvoie un jeton JWT qui, une fois décodé, comme nous pouvons le voir, ne contient que le rôle "AppRoleAssignment.ReadWrite.All" :

En utilisant ce jeton JWT comme nouveau jeton d'autorisation, nous pouvons ajouter le rôle requis à l'application. Pour ce faire, nous devons connaître l'appRoleID du rôle que nous voulons ajouter, le principalId et le resourceId. La demande d'ajout du rôle RoleManagement.ReadWrite.Directory peut être effectuée à l'aide des commandes PowerShell suivantes :

$params = @{
principalId = <servicePrincipalId>
resourceId = <resourceId>
appRoleId = "9e3f62cf-ca93-4989-b6ce-bf83c28f9fe8"
} | ConvertTo-Json

Invoke-RestMethod -Method POST -Headers $AppAuthHeader -Uri "https://graph.microsoft.com/v1.0/servicePrincipals/ <servicePrincipalId>/appRoleAssignments" - Body $params -ContentType "application/json"

Nous pouvons maintenant nous authentifier en tant qu'application en utilisant le même mot de passe que celui que nous avions ajouté précédemment. En visualisant le jeton JWT nouvellement généré, nous pouvons voir que notre nouveau rôle a été appliqué avec succès :

Vous pouvez également le vérifier sur le portail Azure en visitant l'application :

AJOUT D'UN UTILISATEUR EN TANT QU'ADMINISTRATEUR GLOBAL

L'utilisation de ce nouveau JWT nous permet de faire des requêtes en tant que principal du service. Comme il a le rôle RoleManagement.ReadWrite.Directory, il nous permet d'attribuer à un utilisateur le rôle d'administrateur global. Dans PowerShell, cela se fait en mettant à jour la variable AppAuthHeader avec le nouveau jeton JWT et en exécutant les commandes suivantes :

$Reference = @{ "@odata.id" = "https://graph.microsoft.com/beta/directoryObjects/" + <UserIDToMakeGlobalAdmin>} | ConvertTo-Json

Invoke-RestMethod -Method Post -Headers $AppAuthHeader -Uri "https://graph.microsoft.com/beta/directoryRoles/roleTemplateId=62e90394-69f5-4237-9190- 012177145e10/members/`$ref" -Body $Reference -ContentType "application/json"

En regardant sur le portail Azure, nous pouvons voir que notre utilisateur fait maintenant partie des administrateurs globaux :

ATTÉNUATIONS

Il n'y a pas de réponse claire à la question de savoir comment atténuer cette attaque. Toutefois, certaines mesures peuvent être prises pour réduire le taux de réussite de cette attaque.

La première et la plus évidente consiste à limiter l'utilisation de rôles sensibles tels que RoleManagement.ReadWrite.Directory. Dans certains cas, ces rôles seront nécessaires. Dans ces scénarios, il est préférable de surveiller étroitement ces applications et d'avoir des réponses automatisées prêtes en cas de comportement anormal.

En outre, l'utilisation de l'accès conditionnel réduirait la probabilité que cette attaque réussisse sur l'internet. Cela pourrait se faire, par exemple, en autorisant uniquement les connexions au compte AAD Sync à partir de vos locaux. Toute irrégularité pourrait alors être utilisée pour déclencher une alerte et vous informer d'une tentative de connexion potentiellement malveillante. Cependant, comme le montre cet exemple, un attaquant qui a compromis le serveur AD Connect peut contourner ces politiques d'accès conditionnel en menant l'attaque à partir du serveur AD Connect.

En outre, des mesures de sécurité doivent être mises en place sur le serveur AD Connect afin de contrôler et de réduire les types d'actions qui peuvent être effectuées sur le serveur. Il peut s'agir, par exemple, de bloquer l'utilisation d'outils tels que AADInternals.

Ces mesures d'atténuation montrent qu'il n'existe pas de solution unique à cette attaque. Au lieu de cela, il faudrait mettre en place plusieurs couches de défense qui arrêteraient un attaquant avant même qu'il n'ait accès au serveur AD Connect.

Pour plus d'informations sur cette attaque, veuillez consulter

• https://cloudbrothers.info/en/prem-global-admin-password-reset/
• https://cloudbrothers.info/en/azure-attack-paths/
• https://posts.specterops.io/azure-privilege-escalation-via-azure-api-permissions-abuse-74aee1006f48

A PROPOS DE SECURA

Bureau Veritas Cybersecurity est un expert de premier plan en matière de cybersécurité. Nos clients vont des gouvernements et des soins de santé à la finance et à l'industrie dans le monde entier. Bureau Veritas Cybersecurity propose des services techniques, tels que des évaluations de vulnérabilités, des tests d'intrusion et du Red Teaming. Nous fournissons également des certifications pour les environnements IoT et industriels, ainsi que des audits, des services forensiques et des formations de sensibilisation. Notre objectif est d'accroître votre résilience Cyber.

Bureau Veritas Cybersecurity est une société de Bureau Veritas. Bureau Veritas (BV) est une société cotée en bourse spécialisée dans les tests, l'inspection et la certification. Fondé en 1828, BV emploie plus de 80 000 personnes et est présent dans 140 pays. Bureau Veritas Cybersecurity est la pierre angulaire de la stratégie de cybersécurité de Bureau Veritas.