微软最近修补了其 Azure API 管理服务中的三个漏洞，其中两个漏洞启用了服务器端请求伪造 (SSRF) 攻击，这些攻击可能允许黑客访问内部 Azure 资产。

概念验证漏洞用于突出开发人员在尝试为自己的 API 和服务实施基于黑名单的限制时可能犯的常见错误。

Web API 已成为现代应用程序开发不可或缺的一部分，尤其是在云中。它们允许服务进行通信和交换数据，非浏览器客户端（例如移动应用程序和物联网设备）可以代表用户安全地访问数据和执行操作，并且公司可以抽象出旧的服务器后端并快速将它们与现代应用程序和服务互连。

API 是标准化的并且易于交互，而不是依赖于不是为 Web 构建的自定义和遗留协议。

近年来，随着公司在生产中快速推出 API，针对它们的攻击数量激增，因为攻击者越来越意识到不安全的 API 可能会提供进入数据库和内部基础设施的后门。

据全球内容交付网络提供商 Akamai 称，与 2021 年相比，2022 年针对 API 和 Web 应用程序的攻击数量增长了 2.5 倍。SSRF 是过去两年涌现的攻击媒介之一。Microsoft Exchange 服务器中的 ProxyLogon、ProxyNotShell 和 OWASSRF 缺陷是被大量利用的著名示例。

在过去的两年里，Akamai 发现攻击尝试和授权漏洞扫描流量都在稳步增加，这些流量在 Microsoft Exchange 以外的软件中寻找 SSRF 漏洞。

此外，我们每天都看到平均有 1400 万次 SSRF 尝试探测我们的 App & API Protector 客户的 Web 应用程序和 API，这表明该向量的流行程度越来越高。值得注意的是这种增长以及 SSRF 开发对组织造成的潜在影响。

通过 Azure API 管理代理的 SSRF

Microsoft 的 Azure API Management 是一项服务，它允许公司将托管在 Azure 上或其私有网络内的服务公开为 API 并对其进行监控。它是一项针对 API 开发人员的服务，由 API 网关、管理平面和开发人员门户组成。

在 SSRF 攻击中，攻击者必须找到一种方法来使用应用程序的功能作为访问内部资源的代理，搭载服务器的特权位置和访问内部网络。换句话说，如果应用程序或 API 允许用户提供 URL，然后将抓取该 URL 并返回响应，则如果不采取额外的安全措施，则可能会发生 SSRF 攻击。

Azure API 管理有这样的功能。它允许用户为预期通过他们部署的 API 交换的 JSON 或 XML 数据的结构指定模式。然而，据安全公司 Ermetic 的研究人员称，该服务还可以通过向用户提供的 URL 发出请求来指示自动确定架构，此功能称为“从 URL 导入”。

一旦你指定了模式的 URL，Azure API 管理 CORS 代理就会通过向指定的 URL 发送 HTTP 请求来检索模式，研究人员在他们的报告中说。

跨源资源共享 (CORS) 是一种基于 HTTP 标头的机制，它允许 Web 服务器向浏览器指示允许加载脚本等资源的其他源（服务器）。这种情况下的 CORS 代理会拦截请求并修改 CORS 标头，以确保允许 portal.azure.com 和其他服务器之间的跨域请求。

一旦发现此功能，Ermetic 研究人员便考虑提供 http://localhost 或 http://127.0.1.1（环回地址）作为远程 URL，以获取模式以查看 CORS 代理是否会在内部到达服务器本身，实现SSRF。这导致了 HTTP 403 错误（禁止访问），表明存在黑名单。

然后研究人员注册了一个名为 localhost.me 的域，然后编辑其 DNS 记录以指向 127.0.1.1。因此，当 CORS 代理尝试访问 http://localhost.me 时，它会首先解析 DNS 并尝试访问返回的 IP 地址，该地址绕过黑名单指向自身。这奏效了。CORS 代理返回的响应是 HTTP 错误 404（未找到页面），这意味着服务器不再拒绝请求但没有可提供的页面。

研究人员还发现，他们可以在请求中添加自定义标头，这些标头将由 CORS 代理代理到目标服务器，从而为更复杂的攻击打开大门。然后他们尝试在不同的端口号上访问内部服务器，而不是默认的 80，以探测其他服务是否可能在自定义端口上运行，并注意到当他们尝试包括“300”的端口号时，例如 300、3000 或 30000 ，他们再次收到错误 403 Forbidden。

研究人员说：“我们了解到，如果专门针对这些端口存在正则表达式 [正则表达式]，那么一些重要的服务必须在这些端口上侦听。”

正则表达式是可用于构建黑名单的搜索和匹配规则。例如，该规则可以匹配请求中包含术语 localhost 和由 300 组成的端口号的任何 URL。研究人员推断，如果存在正则表达式，它必须应用于请求标头中名为“Ocp-Apim-Url”的值，该值定义了 CORS 代理到达的 URL。因此，他们使用指向他们控制的域的 URL，然后将代理重定向回 http://localhost:30001。

这有效并再次绕过黑名单，允许研究人员发现和访问不同端口号上的内部服务：30001 - 开发人员门户的经过身份验证的视图，30004 - Azure 的管理 API，30005 - Azure 的 Kudu API 管理，30006 - 未发布的开发人员站点（未经身份验证）。Kudu是为 Azure App Service 的一些管理功能提供支持的引擎，Azure App Service 是一种用于在 Azure 上托管和部署 Web 应用程序的服务。

SSRF 漏洞揭示黑名单弱点作为防御

这个通过 CORS 代理的 SSRF 漏洞类似于 Orca Security 的研究人员在 11 月份在同一服务中发现的漏洞。Ermetic 在 12 月向 Microsoft 报告了它的发现，并认为它可能是同一个漏洞。然而，他们的漏洞利用绕过了 Microsoft 在 Orca 报告原始缺陷后实施的修复，使其成为一个单独的漏洞。这凸显了依靠正则表达式等黑名单技术作为这些类型功能的防御机制的困难，因为总是有多种方法可以绕过它们。

Ermetic 研究人员并没有就此停止他们的分析，并发现了第二个 SSRF，这次是在 Azure API 管理托管代理中——一个不同的代理，用于在创建 API 时为 API 动态配置后端服务 URL。

“当从用户指定的前端发送请求时，请求将被发送到入站处理代理，然后再发送到指定的后端，”研究人员说。在此过程中，代理将根据用户定义的入站和出站处理策略对请求进行修改。

研究人员发现，用户可以将 set-backend-service 策略配置为指向 http://localhost 而不是他们真正的 API 后端服务 URL，从而欺骗代理将从 API 前端接收到的请求定向到它自己。

“由于我们可以控制前端和入站处理策略，我们可以使用我们选择的 HTTP 动词/方法和自定义标头发送 SSRF，”他们说。“我们能够访问内部 HTTP 端口 80 以进行 POC [概念验证]。”

对于这两个漏洞，研究人员停止了调查，以避免对内部服务和基础设施造成损害，或者避免通过通常需要身份验证的 SSRF 探测访问敏感数据的风险。

API Management Developer Portal中的路径遍历漏洞 

最后，研究人员还能够在导致路径遍历的 API 管理开发人员门户中找到不受限制的文件上传功能。这有可能影响最终用户部署的任何自托管 API 管理开发人员门户以及他们自己的基础设施。

“我们发现 Azure 不会验证上传文件的文件类型和路径，”研究人员说。“经过身份验证的用户可以遍历上传文件时指定的路径，将恶意文件上传到开发人员门户服务器，并可能使用 DLL 劫持、iisnode 配置交换或任何其他相关攻击媒介在其上执行代码。”