任何人都能完整淪陷全球任何其他 Azure API Connection，拿下其後端 Key Vault、SQL 資料庫，甚至 Jira、Salesforce。擋在攻擊者前面的，其實只是一層層外加的輸入驗證。
本文含 Binary Security 研究原文全文翻譯、Hacker News 討論整理，以及一頁式視覺懶人包。
一頁式懶人包直連： https://static.blog.derekhsu.net/azure-weakest-link-hn.html （含攻擊鏈、五個漏洞時間線、HN 正反分歧）
備援連結： https://derek-static.pages.dev/azure-weakest-link-hn.html
原文出處
- 原文：Binary Security〈Azure 最弱一環〉系列第三篇，2026 年 10 月刊出
- 前作：〈Azure 最弱的一環？〉（2025 年 3 月）、〈Azure 最弱的一環：完整跨租戶淪陷〉（2025 年 8 月）
- 原文連結： https://www.binarysecurity.no/posts/2026/10/one-root-case
- HN 討論： https://news.ycombinator.com/item?id=50301854 （分數 294、留言 56 則、頂層 13 則，2026 年 10 月 31 日 14:16 CST 抓取）
- 作者另於 2026 年亞洲藍帽（Blue Hat Asia 2026）發表此主題，錄影上線後會補上連結
全文翻譯
作者在前兩篇中揭露：Azure API Connections（Logic Apps 的一部分），架構有嚴重的不安全設計，以及一例完整的跨租戶淪陷。這次帶來同系統更多漏洞，每個都能給攻擊者同等的操作原語。這系列漏洞共為他帶來 20 萬美元獎金。
TL;DR
API Connections 讓任何人都能完整淪陷全球任何其他連線，取得其後端服務的完整存取權。包括跨租戶竊取 Key Vault 與 Azure SQL 資料庫，以及任何外部服務（Jira、Salesforce 等）。擋在攻擊者前面的，其實只是一層層外加的輸入驗證，而邊界案例永遠抓不完。
架構
沒看過前兩篇的人建議先看，重點重述如下。微軟文件有一張架構圖，講解了系統運作所需的一切：
- Logic App（左下角圖示）查詢共用的 Azure API Management（APIM）執行個體；
- APIM 先檢查連接器型別的 swagger（OpenAPI）定義，確認是合法動作；
- 發生某種金鑰交換：輸入的 token（金鑰）被換成後端服務預設的 token；
- APIM 用新 token 完成對後端服務的呼叫。
由此可推論：若能誘使 APIM 去操作別人的連線，而不是你自己的，就能盜用受害者連線的 token 操作其後端。後端可以是任何東西，連接器清單實際上無邊界，包含大量 Azure 服務。
圖表有一處關鍵遺漏（前篇已利用）：透過 ARM REST API 的 DynamicInvoke 或 /extensions/proxy/ 端點，可以直接經由 ARM 打到 APIM。作者補上了修正版架構圖。而 ARM 是資源管理器，實際上對一切都有完整存取權，攻擊路徑就清楚了：誘使呼叫服務去查別人的連線，就能完全控制後端服務。
附帶說明：理論上建立連線的人可以把 token、金鑰權限縮到最小，但作者認為很少人這麼做。OAuth 連線一定是建立者的個人 token；API 金鑰情境，誰會有空做最小權限？微軟自己就沒有。
初始漏洞利用
第一個跨租戶利用（也是 Azure 史上的第一例）已寫在第二篇。複習：用自己連線的 DynamicInvoke 端點，以路徑遍歷讀取別租戶的 Key Vault：
- 打自己的
.../connections/custom2/DynamicInvoke?api-version=2018-07-01-preview， request.path填path/%2e%2e/%2e%2e/%2e%2e/%2e%2e/apim/keyvault/<受害者連線 id>/secrets/victimsecret/value，- 回傳 200，內容是
value: dontreadme等完整秘密資料。
這是很典型的路徑遍歷漏洞，也證實了假設：打到 APIM 的 ARM 請求，對所有連線都有權限，不分是誰的。
後續利用一：黑名單修補與未公開端點
回報幾週後漏洞被標記修復，重試只得到「路徑不允許」錯誤。作者判斷修法只是限制路徑、沒動底層 token 問題，一定有繞法。
ARM API 有時不如想像中黑箱：相關程式碼「有時」會出現在資源型別內。作者開了一個 Standard Logic App（獨佔主機），SSH 進去把程式碼抽出來，果然找到驗證程式碼，裡面對 ../ 做了檢查，修補手法一目了然。
更意外的收穫：找 DynamicInvoke 實作時，旁邊躺著四個完全未公開、無文件的函式。把 URI 裡的 dynamicInvoke 換成 DynamicList 就能打到。以 DynamicList 為例：每個路徑參數分開指定，照樣做路徑遍歷，就能對受害者的 SQL Server 做跨租戶寫入，例如 Insert INTO MySecrets VALUES ('NewEvilSecrets', 3)，目標 victimservice.database.windows.net,VictimDatabase。
作者先只報了 DynamicList，指望微軟比照辦理、剩下兩端點還能再報。結果微軟直接把這些端點全封了。沒有其他緩解措施，所以哪天端點重開，大機率照樣有洞。
後續利用二：Logic App 本體的 runtimeUrl 覆寫
動態呼叫的路徑花招走到盡頭，作者換方向：直接用 Logic App 本身。關鍵差異在 Consumption 與 Standard 兩種 Logic App 的連線建立流程：多人共置的 Consumption 版建立 Version 1 連線，獨佔主機的 Standard 版建立 Version 2 連線。V2 流程中，資源建好、後端授權加上後，用受控識別（managed identity）授權該 Logic App 存取；V1 流程沒有這個身份可以授權，因為環境不是你的。結論：每個 Consumption Logic App 都隱含擁有對「所有」V1 連線的存取權，擋著的只剩輸入驗證。
Logic App 工作流程檢視的輸入很受限，但 API 端點與 GUI 的 Code 檢視可以玩更多。直接把連接器參照換成受害者，擁有權驗證會擋下（擁有權驗證很嚴），但作者手握程式碼，把合法參數翻了一遍，找到了 host.api.runtimeUrl。這個參數至今仍被接受：在驗證完 host.connection 參照的連線後，允許你指定另一套 runtimeUrl，取代連線內建值，只要主機尾端是 azure-apihub.net，還會附上所需的 Authorization 標頭。工作流程一跑，受害者的秘密就回來了。
天上掉下來的禮物：修了又破
回報後微軟修了一版，錯誤訊息變成：主機 API runtime URL 與該連線預期的 https://logic-apis-norwayeast.azure-apihub.net/apim/keyvault/<id>? 不符，要嘛拿掉 host.api，要嘛修正 URL。除冗長外算是合理的修法，除非它「在路徑正規化之前」就做檢查。沒錯，runtimeUrl 再做一次路徑遍歷就又通了：驗證時以為指向自己的連線，APIM 看到的是另一條路。
接著更有趣：微軟修掉這次路徑遍歷時，竟把最初的 RuntimeUrl 檢查弄丟了，原攻擊又能打了（附圖與之前相同，略）。
回報與獎勵
API Connections 系列共計五個 Azure 嚴重權限提升漏洞，全部在合理時間內修復。與 MSRC 中間雖有分歧，整體結果作者很滿意。
HN 討論整理
主題一：Azure 跨租戶破事特別多？（主流）
論點：Azure 的跨租戶外洩數量遙遙領先，不意外，修補也是修一次破一次。
- meekins：「Azure 的跨租戶外洩數量看起來大幅領先競爭對手，真不懂企業為何還湧向它。」
- outworlder：「微軟有個離譜的跨租戶漏洞（話說其他雲才出過幾個？）回報了，修錯了；再回報，這次修好又把上次的修法搞壞了，又能打了，根本小丑秀。」
- thewisenerd：「路徑遍歷加 IDOR，大概從這功能誕生第一天就活著了。」
主題二：企業為何還留在 Azure（分歧：採購現實 vs 支援惡夢）
論點：既有微軟授權、議價與資料中心落地是主因；但支援體驗極差，單一廠商並沒有比較省事。
- traceroute66：「企業早就按人頭付 Intune、Teams，順手用 Azure 就好；只管一家廠商，而且拿個人化支援花的錢可能比 AWS 少。」
- toomuchtodo：「業務超會打 C-level，給大額 credits、手把手幫你蓋，尤其想從別家雲搶人時。」
- magicalhippo：「我們主要是資料中心在本國，延遲好、客戶睡得著；亞馬遜沒有，Google 沒人敢押寶它哪天砍產品。」
- waz0wski：「跟微軟打過交道就知道『單一廠商關係』毫無意義，支援團隊互踢皮球，入口網站難用，只有甲骨文更爛。」
- marcosdumay：「管廠商關係就是管授權與合約，多一家就是多幾個全職缺，企業自然不想加。」
主題三：漏洞獎金與內部通報文化（少數）
論點：外部鏈式回報賺大錢，內部員工反而多一事不如少一事。
- eugenekay：「外部人報跨租戶鏈能拿 $$$；員工報『理論性』驗證問題，只會被盤問你沒事看這個幹嘛。」
- rsalus（自稱微軟 FTE）：「yup。」
主題四：歪樓與新線頭
- adminconsent 回呼可偽造（unddoch 拋的新議題，wibartle 自稱可轉交、要求給漏洞編號 fast route，並稱 redirect_uri 有對 app registration 檢查）。
- outworlder 追問「微軟不鼓勵員工報漏洞？那就說得通了。」
- 其餘為 Teams 凍結功能、FedRAMP、微軟裁員與支援外包抱怨，技術含量低，略。
譯註（非原文）
- 系列三篇的脈絡：第一篇揭露架構問題，第二篇完成第一例跨租戶淪陷，本篇是同系統更多漏洞的後續利用合集，共計五個嚴重權限提升漏洞。
- HN 分數與留言數為抓取當下快照，隨時間變動；descendants 含已刪除留言，與 alive 數的落差屬正常現象。
- 技術名詞保留原文（APIM、ARM、Logic App、runtimeUrl、managed identity），引號內的使用者留言忠於原文語氣，僅轉為繁體字形。