未经许可,不得转载。
文章目录
正文
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/