未经许可，不得转载。

正文

Azure API管理包括三个主要组件：API网关、管理平面和开发者门户。这些组件默认由Azure托管并完全管理。Azure API管理可实现数字化体验、简化应用程序集成，支持新的数字产品，并促进数据和服务的重复使用与广泛访问。

创建一个新的 API 管理服务：

创建服务后，转到主服务页面并查看正在发送的各种请求：

其中，较为特殊的请求为：

上图中，由于API管理开发者门户尚未分配，因此Ocp-Apim-Url默认为null/internal-status-0123456789abcdef

将url参数修改为https://www.ifconfig.me，回显当前服务器 IP：

同时，Burp Collaborator可接受服务器回调：

从以上两个例子看出，Ocp-Apim-Url为SSRF的关键点，因为我们可以发送任意的请求。

知晓漏洞点后，即可进行进一步利用。

漏洞利用

IMDS运行于169.254.169.254上，提供有关当前正在运行的虚拟机实例的信息，但经过尝试，无法访问 IMDS。

因此我们枚举了内部127.0.0.1的端口：

枚举过程如下：

发现开放端口：

下图为示例响应包：

本文主要分享 30005 端口的测试过程，其URL为https://apimanagement-cors-proxy-prd.scm.azure-api.net/

通过浏览器（外部方式）访问可证实这一点：

通过服务器（内部方式）访问也可证实这一点：

不同之处在于，SSRF 漏洞从服务器内部发送请求，才可获取敏感信息。

由于这是一个Kudu Git服务器，可以推测它使用 Git 客户端从门户上传和保存各种部署。

因此，尝试使用git-upload-pack命令获取 Git 对象数据，回显如下：

同理，尝试向远程存储库发送请求以列出 refs：

1、

2、

总而言之，我们能够检索 Git 客户端版本、空的 refs 列表和不同的git-scm功能。

接下来，有几种进一步利用的可能性：

1、尝试上传远程仓库

2、枚举Kudu SCM服务器内的各种敏感文件。

原文出处： https://orca.security/resources/blog/ssrf-vulnerabilities-azure-api-management/