Azure API Connections 曝五处跨租户提权漏洞，输入校验成薄弱环节

安全研究者近日公开了 Azure Logic Apps 中 API Connections（API 连接）的一系列严重漏洞，总计五处跨租户提权问题。这些漏洞的共同点在于：攻击者可以借助自己拥有的连接，诱导 Azure 内部服务去调用属于其他租户的连接，从而使用受害者连接中配置的凭据访问其后端服务，包括 Key Vault 和 Azure SQL 数据库。

本文根据公开披露材料梳理漏洞的技术背景、核心变化与影响，并从防御角度给出可执行的建议。需要说明的是，本文没有进行任何独立复现或测试，所有事实均来自来源文章，分析部分为编辑解读。

背景：API Connections 的共享架构

API Connections 是 Azure Logic Apps 的组成部分，用于让工作流连接外部服务。根据来源文章引用的微软文档，其调用链大致如下：Logic App 调用共享的 Azure API Management 实例；API Management 先校验连接器类型的 OpenAPI 定义，确认是合法操作；随后进行某种令牌交换，把输入令牌换成后端服务配置的令牌；最后用新令牌完成后端调用。

这个设计的关键在于：API Management 实例对多个连接是共享的，并且代表调用方使用连接中保存的凭据。如果攻击者能让该实例操作一个不属于自己的连接，就能间接使用受害者的后端令牌。来源文章指出，通过 ARM REST API 的 DynamicInvoke 或 /extensions/proxy/ 端点，可以直接经 ARM 查询 APIM 服务，而 ARM 作为资源管理器对资源具有广泛访问能力。

来源文章还提到一个现实前提：很多连接配置的后端令牌或密钥权限较大，OAuth 连接通常沿用最初创建连接者的令牌，API 密钥也往往没有做最小权限收敛。这放大了连接被滥用后的影响。

核心变化：五处漏洞与修复的反复

来源文章描述了攻击思路的演进，以及微软修复过程中的反复。

第一处问题借助 DynamicInvoke 端点中的路径遍历，让请求从自己的连接跳到其他租户的 Key Vault 等后端。来源文章给出的示例显示，通过在请求路径中插入 %2e%2e 等编码后的上级目录片段，可以读取受害者 Key Vault 中的 secret。

微软随后对该端点做了路径限制。研究者通过创建 Standard Logic App 并提取相关代码，发现修复方式偏向黑名单式路径限制，而非解决底层令牌归属问题。他还发现同一路径下存在四个未公开的函数（如 DynamicList），其中部分端点同样可被滥用。来源文章展示了通过 DynamicList 对受害者 Azure SQL 数据库执行任意 SQL 查询的示例。微软最终选择封禁这些端点，但研究者认为底层缓解措施并不充分。

第三类问题转向 Logic Apps 本身。研究者注意到 Consumption 与 Standard Logic App 在创建连接时的流程差异：Consumption 逻辑应用创建 Version 1 连接，而 Standard 逻辑应用创建 Version 2 连接，并使用托管标识进行授权。研究者推断，每个 Consumption Logic App 可能对每个 Version 1 API Connection 都有隐式访问权，剩下的障碍只是输入校验。

他随后发现 host.api.RuntimeUrl 参数可被用来覆盖连接中内置的运行时 URL。只要主机名以 azure-apihub.net 结尾，请求仍会带上所需的 Authorization 头。微软的修复要求运行时 URL 必须与连接期望的 API 端点完全匹配，但研究者发现校验发生在路径规范化之前，因此可以通过构造路径绕过。来源文章还提到，在后续修复中，原先的 RuntimeUrl 路径一度不再被校验，导致旧攻击方式重新可用。

来源文章称，五处漏洞均在其报告后的合理时间内得到修复，过程中与 MSRC 存在一些分歧，但总体结果令研究者满意。来源未说明各漏洞的具体修复日期、影响租户数量或是否观察到在野利用。

影响分析：为什么这类问题值得警惕

从来源材料看，这些漏洞的影响并非局限于某个单一服务。API Connections 的后端列表“实际上没有边界”，既包括 Azure 服务，也包括 Jira、Salesforce 等外部 SaaS。一旦连接被跨租户滥用，攻击者可能获得受害者配置凭据所对应的全部权限。

对使用 Logic Apps 的团队而言，风险点主要有三：

1. 凭据权限过大：如果连接使用高权限服务主体、管理员级 API 密钥或长期 OAuth 令牌，连接被滥用后的爆炸半径会显著扩大。
2. 连接归属校验依赖输入过滤：来源文章反复说明，系统对“你是否拥有该连接”的校验存在边界情况，路径规范化、未公开端点、运行时 URL 覆盖等都可能成为绕过点。
3. 共享基础设施的信任边界：Consumption Logic Apps 运行在共享环境中，其连接创建流程与 Standard 版本不同，隐式访问关系增加了攻击面。

对云平台而言，这类问题提醒我们：在多租户服务中，仅靠输入校验来隔离租户资源是脆弱的。修复应落在授权模型和令牌作用域上，而不是逐个封堵已知路径。

行动建议：开发者与运维可做什么

以下建议基于来源文章揭示的风险模式，供使用 Azure Logic Apps 和 API Connections 的团队参考。

收敛连接凭据权限。 检查每个 API Connection 的后端认证方式。对 OAuth 连接，尽量使用专用服务主体或托管标识，并只授予完成工作流所需的最小权限；对 API 密钥，避免使用全局管理员密钥，优先使用可限定范围、可轮换的密钥。来源文章明确指出，连接创建者往往不会主动做最小权限，因此这项检查需要由团队制度化执行。

审计连接与工作流归属。 盘点订阅内所有 API Connections，确认其创建者、后端服务、认证类型和最近使用情况。对不再使用的连接及时删除，减少可被利用的凭据面。对 Consumption Logic Apps，重点关注其引用的 Version 1 连接是否仍为必要。

优先采用 Standard Logic App 与托管标识。 来源文章显示，Standard 版本使用托管标识授权，连接创建流程与 Consumption 不同。在条件允许时，迁移到 Standard 工作流并配合托管标识，可以降低共享环境中隐式访问带来的风险。迁移前需验证连接器兼容性和区域可用性，来源未说明所有连接器是否均已支持。

监控异常调用模式。 在日志中关注对 API Connections 的异常请求，例如路径中包含编码后的上级目录片段、非预期的 RuntimeUrl 参数、对未公开动态端点的调用，以及跨订阅或跨租户资源标识的出现。由于来源未提供具体检测规则或日志字段，建议结合 Azure Monitor、活动日志和 APIM 日志自行设计基线与告警。

关注平台修复并验证。 来源文章称相关漏洞已修复，但修复曾出现反复。运维团队应关注微软安全更新和 MSRC 公告，在修复发布后验证自身环境中相关端点行为是否符合预期。不要假设一次补丁就永久关闭了攻击面。

对高风险后端增加额外隔离。 对 Key Vault、Azure SQL 等敏感后端，除连接凭据外，可考虑网络限制、私有终结点、数据库防火墙和 Key Vault 访问策略等纵深防御措施，降低单一连接凭据泄露后的直接影响。

资料来源

• Azure's Weakest Link - Five Full Cross-Tenant Compromises

本文由自动化系统筛选公开技术信息，并经 AI 辅助整理。