Usurpation d’Identités managées dans AzureUsurpation d’Identités managées dans Azure

Identité managée sur Azure

Une Identité managée permet à une application de s’authentifier directement auprès d’Azure sans nécessiter de stockage de secrets.

Il en existe deux types :

• Identité managée affectée par le système : cette identité est liée directement à une seule ressource, comme un App Service. L’authentification est donc restreinte à une relation un à un entre la ressource et son identité.
• Identité managée gérée par l’utilisateur : créée indépendamment et pouvant être attribuée à plusieurs ressources.

Ces identités simplifient la gestion des accès, mais une mauvaise configuration des permissions peut exposer l’environnement Azure à des risques.

C’est quoi une Azure App Service ?

Une Azure App Service permet d’exécuter des applications web, API et back-end sans gérer l’infrastructure sous-jacente. L’objectif est de fournir un environnement managé où le développeur peut déployer son code sans se soucier du serveur.

Pour interagir avec d’autres services Azure (Key Vault, Storage Account, SQL Database…), une application doit s’authentifier. Au lieu d’utiliser des clés d’API ou des secrets stockés en clair, Microsoft propose les Identités managées.

Dans cet article, nous allons illustrer l’exploitation d’une identité managée dans une App Service Azure, mais cette identité aurait aussi pu être attribuée à une machine virtuelle ou à d’autres services.

Exploitation d’une App Service avec une identité managée

Dans notre lab, une App Service est configurée avec une identité managée affectée par le système et contient une vulnérabilité d’injection de commande. L’exploitation permet d’exécuter du code arbitraire sur le serveur.

L’application exécutée dans l’App Service présente une faille permettant d’exécuter des commandes.

L’attaquant peut utiliser le paramètre « message » pour exécuter des commandes :

Nous allons transférer un reverse shell sur le serveur et obtenir un shell interactif pour une exploitation plus confortable.

Sert le reverse shell PHP

Télécharge le shell dans le serveur

Réceptionne le reverse shell

Une fois le shell obtenu, nous pouvons passer à l’exploitation de l’identité managée.
Dans un scénario réel, il serait pertinent de rechercher dans les fichiers sources des informations potentiellement sensibles.

Exploitation de l’identité managée

Une application cliente peut demander un jeton d’accès à l’identité managée pour interagir avec d’autres services Azure.

Le processus de demande d’un jeton et d’accès aux ressources fonctionne comme suit :

1. Une identité managée (system-assigned ou user-assigned) est associée à une ressource.
2. Un principal de service correspondant est créé dans Entra ID.
3. Le principal de service est enregistré auprès de l’IMDS.
4. Un rôle RBAC peut être attribué à cette identité.
5. Lorsqu’une ressource doit interagir avec Azure, elle contacte le point de terminaison IMDS local (https://169.254.169.254/metadata/identity/oauth2/token).
6. L’IMDS demande un jeton d’accès à Entra ID.
7. Entra ID émet le jeton d’accès.

L’URL de l’IMDS et l’ID de l’identité managée sont déjà définis automatiquement dans les variables d’environnement de l’App Service.

Pour demander un jeton, nous pouvons exécuter la commande suivante sur le serveur :

curl "$IDENTITY_ENDPOINT?api-version=2019-08-01&resource=https://management.azure.com/" -H "X-Identity-Header: $IDENTITY_HEADER"

Décomposition de l’URL :

• $IDENTITY_ENDPOINT : le point de terminaison du service des identités managées (IMDS)
• api-version : la version de l’API utilisée
• resource : l’URL de la ressource cible
• $IDENTITY_HEADER : l’ID de l’identité managée

Une fois le JWT récupéré, nous pouvons nous authentifier au service Azure et usurper l’identité managée :

Connect-AzAccount -AccessToken $armtoken -AccountId <ANYTHING>

Le paramètre AccountId peut prendre une valeur arbitraire.

Une fois authentifié, nous pouvons :

• Énumérer le tenant Azure et découvrir les rôles de l’identité avec Get-AzRoleAssignment
• Lister les ressources accessibles avec Get-AzResource

Dans notre scénario, nous avons trouvé un Key Vault « mobeta-vault ».

Dans lequel l’identité managée dispose des permissions Key Vault Administrator, incluant la lecture et l’écriture des secrets.

Nous pouvons alors modifier le scope du jeton pour cibler Key Vault https://vault.azure.net

Avec ce nouveau JWT, nous pouvons extraire les secrets stockés dans « mobeta-vault ».

Cet exemple illustre un scénario fictif ciblant un Key Vault, mais d’autres permissions pourraient être attribuées à une identité managée.

C’est le type de scénario qu’on peut mettre en œuvre lors d’un pentest Azure ou d’une mission Red Team.

Mitigation

Pour se protéger contre ce type d’attaque :

• Restreindre les permissions des identités managées (principe du moindre privilège)
• Auditer régulièrement les applications web pour limiter les failles

Comme nous l’avons vu, une simple faille d’injection peut mener à une compromission complète de l’environnement Azure d’une entreprise.

Sources

• Microsoft Docs – Managed Identities
• Microsoft Docs – Using VM Token
• Pwned Labs – Azure VM Attack Vectors