Présentation

Les API Connections de la plateforme Azure Logic Apps offrent un point d’intégration entre un workflow et un service externe (Key Vault, Azure SQL, Jira, Salesforce, etc.). L’auteur a démontré que la même primitive d’accès peut être détournée pour lire ou modifier les ressources d’un autre locataire, générant ainsi une perte financière estimée à 200 000 $. Le problème repose sur la façon dont Azure API Management (APIM) échange le jeton d’entrée contre le jeton configuré du service cible.

Architecture et flux d’authentification

Un logic app invoque un instance partagée d’Azure API Management. APIM valide d’abord le swagger (OpenAPI) du connecteur, puis effectue un échange de clé : le jeton fourni par le client est remplacé par le jeton stocké dans la connexion pour le service backend. La requête finale, contenant ce jeton, est transmise au service cible. Le diagramme officiel d’Azure omet toutefois la capacité d’appeler APIM via l’API REST d’ARM (DynamicInvoke ou /extensions/proxy/), ce qui donne à ARM, en tant que gestionnaire de ressources, un accès complet à toutes les connexions.

Exploitation initiale

En utilisant l’endpoint DynamicInvoke d’une connexion contrôlée, l’auteur a injecté un chemin de traversée (%2e%2e/) pour forcer APIM à accéder à la connexion d’un autre locataire et à lire un secret stocké dans un Azure Key Vault. Exemple de charge utile :

POST /subscriptions/8e3ce52f-d45b-4347-8705-65892507465e/resourceGroups/token-storer/providers/Microsoft.Web/connections/custom2/DynamicInvoke?api-version=2018-07-01-preview HTTP/2
Host: management.azure.com
Authorization: Bearer 
Content-Type: application/json
Content-Length: 147
{
    "request":{
        "method":"get",
        "path":"path/%2e%2e/%2e%2e/%2e%2e/%2e%2e/apim/keyvault/fd8d0f4f4069495991ccb4974f96a1ed/secrets/victimsecret/value"
    }
}

La réponse HTTP 200 renvoie le secret dontreadme, confirmant que le token du locataire victime a été réutilisé. Le mécanisme repose sur le fait que, lorsqu’ARM invoque APIM, il possède les droits sur *toutes* les connexions, indépendamment du contexte de la requête.

Limites du correctif et vecteurs résiduels

Après signalement, Microsoft a introduit un filtrage des chemins autorisés, mais uniquement pour l’endpoint DynamicInvoke. L’auteur a découvert trois fonctions supplémentaires (DynamicList, DynamicCreate, DynamicDelete) non documentées mais accessibles via le même préfixe. Ces fonctions partagent la même logique d’échange de jeton et ne sont pas couvertes par le filtrage, conservant ainsi la capacité d’exécuter des traversées de chemin ou d’autres manipulations de paramètres. En modifiant simplement le segment dynamicInvoke de l’URL, il est possible d’atteindre ces points d’entrée et de reproduire le même type d’accès non autorisé.

Le correctif actuel ne résout donc pas la vulnérabilité fondamentale : la confiance implicite d’ARM envers APIM pour opérer sur n’importe quelle connexion. Sans une révision de l’architecture – par exemple, en isolant les jetons par locataire ou en imposant une validation stricte côté APIM – les attaquants peuvent continuer à exploiter les fonctions non filtrées.