Azure API connections के लिए continuous exposure scanner
Azure Logic Apps के API connections का लगातार ऑडिट करता है, over-privileged tokens और ज्ञात cross-tenant attack paths को इससे पहले ढूंढता है कि कोई और ढूंढ ले।
Claude Code, Cursor या किसी भी कोडिंग एजेंट में चिपकाने के लिए तैयार ब्रीफ़ (अंग्रेज़ी में)।
कुल6.5/10
समस्या7
भुगतान की इच्छा6
समय8
बाज़ार में कमी6
सुरक्षा कवच6
व्यवहार्यता6
पक्ष में
- कौन भुगतान करेगा
- Azure-heavy enterprises (500+ कर्मचारी) में cloud security leads और AppSec managers, जो Logic Apps और Power Platform चलाते हैं; cloud security posture बजट से $1-3k/महीने।
- लोगों ने क्या कहा · 4
- लेख API Connections के ज़रिए पांच अलग cross-tenant compromise paths दिखाता है, जिनसे पीड़ितों के Key Vaults, SQL databases, Jira और Salesforce तक पहुंच मिली; लेखक का अनुमान है कि connection tokens लगभग कभी न्यूनतम scope में नहीं होते। लेख से ↗
- Microsoft ने रिपोर्ट किया गया बग गलत तरीके से patch किया, फिर बाद के fix ने पहले वाले fix को तोड़ दिया, जिससे सिस्टम फिर से असुरक्षित हो गया। टिप्पणी पढ़ें ↗
- Azure cross-tenant leaks में प्रतिस्पर्धियों से आगे दिखता है, फिर भी enterprises उसे अपनाते रहते हैं। टिप्पणी पढ़ें ↗
- खामियां basic path traversal और IDOR हैं, जो संभवतः फीचर लॉन्च होने के समय से मौजूद हैं। टिप्पणी पढ़ें ↗
चर्चा से अपने शब्दों में लिखा गया। मूल टिप्पणियों के लिए लिंक देखें।
- प्रतिस्पर्धी और कमी
CSPM tools सामान्य misconfigurations पकड़ते हैं, पर कोई भी Logic Apps/API Connection attack surface को गहराई से मॉडल नहीं करता: DynamicInvoke-style proxy endpoints, host.api.RuntimeUrl overrides, V1 बनाम V2 connections में implicit access, और हर connector token का privilege scope। Defender for Cloud वह vendor है जो इसी surface के लिए बार-बार गलत fixes भेजता रहा है।
- अभी क्यों
- एक ही connector subsystem पर पांच काम करने वाले cross-tenant exploits एक श्रृंखला में प्रकाशित हुए, fixes बार-बार regress हुए, और कमेंटेटर्स को उम्मीद है कि LLM-आधारित discovery इस तरह की findings को बढ़ाएगी; डिफेंडर्स को अब one-time pentests नहीं, continuous testing चाहिए।
- सुरक्षा कवच · 6/10
- Azure connector types और अदस्तावेज़ित endpoints की लगातार अपडेट होती rule/attack-graph library, जो original research से बनती है; reproduction harnesses और tenant telemetry समय के साथ जमा होते हैं और generic CSPMs के लिए जल्दी दोहराना मुश्किल है।
विपक्ष में
- रेड टीम
- CSPMs इस खास Logic Apps/API Connection attack surface को साफ तौर पर चूकते हैं, research असली exploitability साबित करता है, और Azure-heavy enterprises पहले से Wiz जैसे स्तर के posture tools के लिए बड़ा बजट देते हैं।
- यह किस वजह से असफल हो सकता है
- Microsoft आखिरकार API Connections को सही तरीके से दोबारा बना दे (हर जगह managed identity / V2 अनिवार्य करके), और विशिष्ट attack surface ग्राहक आधार के बदलने से पहले ही खत्म हो जाए।
शुरुआत
- पहले तीन कदम
- एक read-only Azure auditor बनाएं जो tenant के API connections गिने, V1 connections, व्यापक backend scopes वाले unmanaged OAuth tokens और पहुंच योग्य dynamic endpoints को flag करे।
- ग्राहक के अपने connections पर प्रकाशित attack classes (DynamicInvoke के जरिए path traversal, RuntimeUrl override) के सुरक्षित, non-destructive checks चलाएं।
- Dashboard और alerting दें जो config बदलने पर और Microsoft के fixes आने के बाद checks दोबारा चलाए, और हर connector token का scope सीमित करने के लिए remediation guidance भी दे।
- मूल चर्चा
- Azure's Weakest Link – Five Full Cross-Tenant Compromises ↗ 329 पॉइंट60 टिप्पणियाँकहानी सेजुड़ा हुआ लेख
अंग्रेज़ी से अनूदित। मूल पढ़ें