Azure API Management is a feature-rich API management platform that allows developers to publish and manage their APIs. One of the main components of this offering is an API gateway that acts as an intermediary between API consumers and the backend services which provide functionality for the consumers.

API gateways are commonly used to provide a single point for common needs, such as authentication, rate limiting, logging and more. From the attacker perspective, it could be advantageous to learn more about the backend services being called by the API gateway and to bypass it.

I recently came across Azure API Management during an API assessment. During the assessment, I encountered a debugging feature in Azure API Management called “tracing” that is meant to help troubleshoot technical issues. When tracing is enabled for an API user, it provides developers (or attackers) with extra information about the API request. A user who has tracing enabled can pass the request header “Ocp-Apim-Trace: true” to turn on tracing for a given request. The response from the API gateway will then include an additional response header “Ocp-Apim-Trace-Location” that contains a URL pointing to Azure blob storage, where the trace information is temporarily stored. The trace information contains data about the request to the API gateway, the request and response from the backend service and any policies applied to both the request to and response from the backend service.

This technical information is often sought by attackers as it can be useful when profiling potential targets and refining attacks. Learning more about the backend services is a common first step when profiling the API. Using the knowledge gained, attackers develop targeted attacks against the software in use by the API, especially out-of-date components. In addition, any secrets or sensitive information such as backend API keys or passwords can be immediately useful to attackers trying to bypass security controls.

I created an intentionally misconfigured API to demonstrate some of the possible misconfigurations. The slightly redacted tracing information is available at https://gist.github.com/james-otten/0d631d1e34792280003b868746d06ac8. Notice that the trace includes information about the backend service that the API gateway routed the incoming request to. The backend service was hosted at “echoapi.cloudapp.net” on port 80. After learning this information, an attacker would likely attempt to interact with this host directly.

{
"source": "api-inspector",
"timestamp": "2020-05-19T02:23:55.4866316Z",
"elapsed": "00:00:00.6714891",
"data": {
"configuration": {
"api": {
"from": "/echo",
"to": {
"scheme": "http",
"host": "echoapi.cloudapp.net",
"port": 80,
"path": "/api",
"queryString": "",
"query": {},
"isDefaultPort": true
},
"version": null,
"revision": "1"
},
"operation": {
"method": "POST",
"uriTemplate": "/resource"
},
"user": "-",
"product": "-"
}
}
},


When viewing the policies that were applied to the incoming request, notice that a HTTP request header “AuthHeader” was added, and a query string parameter “password” was added. These sensitive values could be useful to an attacker, especially if they allow the attacker to communicate with the backend service directly.

{
"source": "set-header",
"timestamp": "2020-05-19T02:23:56.4710075Z",
"elapsed": "00:00:01.6598630",
"data": {
"message": "Specified value was appended to the original header value. See the new header value below.",
"header": {
"name": "AuthHeader",
"value": "S3CR3T"
}
}
},
{
"source": "set-query-parameter",
"timestamp": "2020-05-19T02:23:56.5022331Z",
"elapsed": "00:00:01.6869739",
"data": {
"message": "Request URL was updated with the query value.",
"request": {
"url": "http://echoapi.cloudapp.net/api/resource?password=P@SSW0RD"
}
}
}


Notice that the full HTTP response headers from the backend services are included in the tracing data. This information could be useful to an attacker attempting to exploit platform specific vulnerabilities in the backend service through the API gateway.

{
"source": "forward-request",
"timestamp": "2020-05-19T02:23:57.2712963Z",
"elapsed": "00:00:02.4616234",
"data": {
"response": {
"status": {
"code": 200,
"reason": "OK"
},
"headers": [
{
"name": "Pragma",
"value": "no-cache"
},
{
"name": "Transfer-Encoding",
"value": "chunked"
},
{
"name": "Host",
"value": "echoapi.cloudapp.net"
},
{
"name": "Ocp-Apim-Subscription-Key",
"value": ""
},
{
"name": "AuthHeader",
"value": "S3CR3T"
},
{
"name": "X-Forwarded-For",
"value": ""
},
{
"name": "Cache-Control",
"value": "no-cache"
},
{
"name": "Content-Type",
"value": "application/xml"
},
{
"name": "Expires",
"value": "-1"
},
{
"name": "Server",
"value": "Microsoft-IIS/8.5"
},
{
"name": "X-AspNet-Version",
"value": "4.0.30319"
},
{
"name": "X-Powered-By",
"value": "Azure API Management - http://api.azure.com/,ASP.NET"
},
{
"name": "Date",
"value": "Tue, 19 May 2020 02:23:56 GMT"
}
}
}
}
}


I created a Burp Suite extension to automatically identify this misconfiguration through a scanner check and to nicely display any tracing information inside of Burp Suite during manual testing. This can help attackers identify misconfigured APIs quickly and reduce the number of steps needed to view the trace information.

The source code for the extension is available at the following GitHub repository: https://github.com/optiv/azure-api-management-tracing-helper.