API Connections 架構與跨租戶攻擊原理

Azure Logic Apps 的 API Connections 允許使用者連接外部服務如 Jira、Salesforce 或 Azure 內部服務。其運作流程涉及 Logic App 查詢共享的 Azure API Management (APIM) 實例，APIM 驗證請求後將輸入權限交換為後端服務配置的權限，最後以該權限呼叫後端。

研究員指出，若能誘騙 APIM 實例操作非攻擊者擁有的連線，即可利用受害者的後端權限進行存取。透過 ARM REST API 的 DynamicInvoke 或 /extensions/proxy/ 端點直接查詢 APIM 服務，由於 ARM 資源管理器擁有廣泛權限，攻擊者可繞過一般使用者介面限制，直接對其他租戶的連線發起請求。

這種架構導致只要輸入驗證不夠嚴謹，任何使用者皆可完全存取全球範圍內其他 API Connections 連接的後端服務，包括 Key Vaults 和 Azure SQL 資料庫。

利用路徑遍歷與未文檔化端點進行攻擊

研究員首先透過 DynamicInvoke 端點發現路徑遍歷漏洞，使用包含 %2e%2e（即 ..）的路徑參數，成功讀取其他租戶 Key Vault 中的秘密值。微軟隨後標記該問題為已修復，但修復方式僅限制允許的路徑格式，並未解決底層權限交換的核心問題。

研究員透過 SSH 進入 Standard Logic App 的專用主機並提取程式碼，發現除了 DynamicInvoke 外，還有四個完全未文檔化的函數：DynamicList、DynamicSchema、DynamicSchemaList 和 DynamicParameters。這些函數位於相同路徑且可被存取，攻擊者可透過修改 URI 中的函數名稱來觸發。

以 DynamicList 為例，攻擊者可透過指定多個路徑參數執行路徑遍歷，並在受害者的 SQL 資料庫上執行任意查詢或寫入操作。微軟隨後選擇直接阻擋所有這些端點作為修復手段，而非修正個別邏輯，這意味著若未來重新啟用這些端點，可能仍會面臨相同風險。

Consumption Logic Apps 的隱含權限與 RuntimeUrl 繞過

研究員發現 Consumption Logic Apps（多租戶共用）與 Standard Logic Apps（專用主機）在建立連線流程上存在差異。Standard Logic Apps 會透過受控身分識別明確授權存取特定後端，而 Consumption Logic Apps 因無法控制執行環境，未進行此類授權，導致其隱含可存取所有 Version 1 API Connections。

雖然 Logic App 工作流對輸入有嚴格驗證，但研究員在程式碼中找到 host.api.RuntimeUrl 參數。該參數允許指定一個不同的 runtime URL，只要主機名稱以 azure-apihub.net 結尾，系統便會自動附加必要的 Authorization 標頭。攻擊者可利用此參數將請求導向其他租戶的連線端點。

微軟修復此問題時，要求 runtime URL 必須精確匹配預期端點。然而，驗證發生在路徑正規化之前，導致攻擊者可使用包含編碼字元的路徑繞過檢查，使 APIM 實例將請求解析為指向受害者連線，從而再次實現跨租戶存取。

修復過程的回歸問題與漏洞獎金

在微軟針對 RuntimeUrl 路徑遍歷進行修復後，出現了一個意外的回歸問題：原本用於驗證的原始 RuntimeUrl 路徑不再被檢查，導致攻擊者可以再次使用最初的攻擊向量。這顯示安全修復過程中可能存在測試覆蓋不足或邏輯順序錯誤的問題。

研究員共報告了五個關鍵的權限提升漏洞，所有漏洞均在提交後合理時間內獲得修復。儘管在與微軟安全回應中心（MSRC）的溝通過程中存在一些分歧，但最終這些漏洞為研究員帶來了總計 20 萬美元的獎金。

社群評論指出，Azure 的跨租戶洩漏問題似乎比競爭對手更為嚴重，並質疑企業為何仍大量採用該平台。另有評論提到，資源名稱隨機化的建議可能是為了緩解這類基於可預測 ID 的攻擊，但這屬於安全透過隱蔽性（security by obscurity）的做法。