Microsoft आंतरिक एप्लिकेशन एक्सेस के लिए Entra OAuth का दुरुपयोग

• शोधकर्ताओं ने Entra OAuth में सहमति (consent) और अनुमति delegation प्रक्रिया के दुरुपयोग से Microsoft के आंतरिक एप्लिकेशन तक पहुँच संभव होने की पुष्टि की
• यह कमजोरी आंतरिक सिस्टम सुरक्षा के लिए एक नया खतरा है, क्योंकि बाहरी उपयोगकर्ताओं द्वारा अंदरूनी सेवाओं तक पहुँचने का मार्ग बन सकता है
• बुनियादी सहमति तंत्र और अपर्याप्त अनुमति सेटिंग ही मुख्य कारण हैं
• शोध में पाया गया कि केवल मौजूदा सुरक्षा नियंत्रणों पर भरोसा करने से OAuth सहमति अनुरोध और एक्सेस कंट्रोल में कमजोरी बनी रहती है
• कंपनियों और संगठनों के लिए OAuth सहमति तथा अनुमति प्रबंधन मजबूत करने की आवश्यकता सामने आई

---

शोध का अवलोकन एवं पृष्ठभूमि

• Microsoft Entra OAuth एक authentication/authorization framework है जिसमें उपयोगकर्ता की सहमति से अलग-अलग applications को विभिन्न सेवाओं तक पहुँच का अधिकार मिलता है
• शोधकर्ताओं ने लक्ष्य वातावरण में पाया कि जो Microsoft एप्लिकेशन सामान्यतः केवल आंतरिक रूप से ही उपलब्ध होते हैं, वे भी खास consent और permission delegation सीनारियो के दुरुपयोग पर बाहरी पहुँच के लिए खुल सकते हैं

कारण विश्लेषण

• कमजोरी OAuth सहमति अनुरोध प्रक्रिया के दुरुपयोग से पैदा होती है
• यदि application को ठीक से प्रतिबंधित न किया गया हो, तो हमलावर उपयोगकर्ता की सहमति प्राप्त करके आंतरिक संसाधन token हासिल कर सकता है
• डिफ़ॉल्ट रूप से दिए गए सहमति और अनुमति प्रदान करने के तंत्र पर्याप्त रूप से granular नहीं हैं, इसलिए कुछ आंतरिक सेवाएँ बाहरी exposure risk में आ जाती हैं

प्रभाव और जोखिम

• एक हमलावर इस कमजोरी का उपयोग करके Microsoft आंतरिक सिस्टम और एप्लिकेशन तक पहुँच बना सकता है
• यदि उसे पहुँच मिलती है, तो संवेदनशील डेटा लीक या आंतरिक फंक्शन के दुरुपयोग का जोखिम मौजूद रहता है

प्रतिक्रिया और सिफारिशें

• संगठनों को OAuth governance को दोबारा देखना चाहिए और सभी सहमति तथा अनुमति आवंटन प्रक्रियाओं को कठोरता से नियंत्रित करना चाहिए
• कम से कम अधिकार सिद्धांत (least privilege) के आधार पर, सहमति से मिले संसाधन और अनुमति की सीमा को स्पष्ट रूप से सीमित करने की जरूरत है
• नियमित रूप से OAuth एप्लिकेशन ऑडिट और सहमति प्रबंधन प्रक्रिया स्थापित करके नियंत्रणों को मजबूत करने की आवश्यकता है

[GN⁺]

Hacker News टिप्पणी

• Microsoft की documentation सच में एक दुःस्वप्न है, इसमें कोई भी vulnerability हो ही जाए इसमें कोई अचरज नहीं हाल ही में हमने Entra ID से SSO login सेट किया था, और (सौभाग्य से यह single-tenant था) सही access token scope व अतिरिक्त fields return सेटिंग मिल जाएँ इसके लिए लगभग random कोशिशें करनी पड़ीं शुरुआत की guide खोजते हुए कई sub-pages खुलते चले जाते हैं, और अंदर बस Microsoft की उलझी हुई terminology तथा मदद न करने वाले doc links ही बार-बार दिखाई देते हैं

• यह परिणाम किसी को भी चौंकाने वाला नहीं है Entra की OAuth2 सेटिंग और docs बिल्कुल उलझी हुई हैं इतनी confusion है कि शायद Microsoft के लोग भी इसे बिना दिक्कत चलाने में struggle करते हैं उनके हिसाब से इसका समाधान “और docs जोड़ दो” था, जबकि पहले से मौजूद spaghetti जैसी docs पढ़ना ही मुश्किल है

  • मैंने भी कुछ हफ्ते पहले यही समस्या झेली थी official docs के मुताबिक कई resource server target करने वाले scopes के साथ authorization code flow चलाया ही नहीं जा सकता लेकिन openid $clientid/.default माँगने पर यह काम कर जाता है flow के अंतिम चरण में ID token और access token दोनों मिलते हैं, और ID token में OIDC scope लागू दिखता है जबकि access token में scope से openid गायब होता है वास्तविकता में Microsoft Graph (UserInfo endpoint के equivalent) को call नहीं कर सकता इस behavior की सही वजह समझाने वाली कोई साफ वजह नहीं मिली

• मल्टी-टेनेंट ऐप authorization लगातार अनपेक्षित समस्याएँ बना रहा है मैं पहले Microsoft में Wiz research-based patch पर काम करने वाला (अब निकल चुका) PM था पोस्ट में मैंने एक सुधार सुझाव दिया था कि मल्टी-टेनेंट app authorization में सिर्फ iss या tid claim देखना काफी है वास्तविक recommendation इससे थोड़ा अधिक जटिल है अगर सिर्फ tenant verify करें तो किसी भी service principal को authorized access मिल सकता है टोकन validate करते समय tenant के साथ subject की भी जाँच जरूरी है उदाहरण के लिए tid+oid से token validate करें, या authorize करने से पहले tenant और subject दोनों conditions जांचें डिटेल claims validation official दस्तावेज़ में मौजूद हैं

  • हर token को forge माना जाए, ऐसा approach ही सही है default से secure design करना चाहिए CPU खर्च हो तो भी हर field की full validation करनी चाहिए signature तब ही meaningful है जब validate किया जाए अगर संभव हो तो identity डेटाबेस से भी cross-check करने की सलाह दी जाती है हमने developers को हमेशा यही सिखाया: tenant, user, group और resource—सब कुछ authorize करने से पहले बारीकी से check होना चाहिए

  • 100% सही कहा गया सच में engineers को official guide ज़रूर पढ़नी चाहिए संबंधित गाइड यहाँ देखी जा सकती है

  • यह भी पूछना है कि “check-list में क्या-क्या check करना है” कहीं साफ से define है या नहीं ideally यह सिर्फ Yes/No होना चाहिए सिस्टम में मैंने कभी ऐसा checkbox नहीं देखा कि “इस group का user सभी लोगों की private notes पढ़ सकता है?”

• Entra की complexity को ignore भी करें तो, खासकर जब internal Microsoft tenants और 3P customer tenants अलग-अलग पहचान के बिना mix हों, गलती समझना मुश्किल हो जाता है इससे भी ज्यादा खतरनाक यह भरोसा है कि “एक authentication token” से ही security solve हो जाएगी ऐसा portal इंटरनेट पर सार्वजनिक नहीं होना चाहिए था (अब शायद public नहीं है) network security अक्सर पीछे धकेली जाती है, जबकि वही सबसे effective defense है

  • network security भी आखिरकार केवल defense layers में से एक ही layer है सही approach है multi-layered security यानी defense-in-depth

• हमें cloud में जाना था क्योंकि अंदर की तुलना में ज्यादा safe बताया गया, और खुद की टीम रखना सिर्फ बेवकूफों का काम बताया गया मैं शायद काफी पुराना हो गया हूँ, इसलिए internal Microsoft apps का बाहर से access होना समझ से बाहर है

  • पिछले 10 साल से Google ने “Zero Trust” के नाम पर full-scale VPN हटाने की दिशा पकड़ ली है कोई भी व्यक्ति यदि केवल VPN में घुस जाए तो sensitive data access रोकना बेहद कठिन हो जाता है इसलिए अब “internal” सेवाएँ भी बाहर expose कर दी जाती हैं, और हर layer पर permissions manage करना पड़ता है इससे एक attacker का कई सेवाओं में एक साथ घुसना काफी कठिन होता है Zero Trust परिचय

  • मेरी राय में इस app का public इंटरनेट पर उपलब्ध होना (यानी intranet न होना) असली समस्या नहीं है वास्तविक समस्या यह है कि Entra ID जैसी applications multi-tenant हैं critical credentials कई tenants (attacker समेत) के साथ एक ही database में store व share होते हैं इसलिए multi-tenancy violations आम हैं Entra ID में tenancy checks कितना भी robust क्यों न हो, कमजोरी फिर भी रहती है जैसे ब्लॉग में उल्लेख है, दो से अधिक tenants को कवर करने वाले requests (multi-tenant requests) को authorize करना मूलतः कठिन है, और छोटी सी गलती भी बड़ा risk बना देती है single-tenant app से तुलना करें तो attacker को पहले उसी tenant का user बनना होता है, इसलिए pre-auth attack काफी कठिन हो जाता है

  • “cloud में जाओ, यहाँ ज्यादा secure है, खुद ऑपरेशन टीम नहीं चाहिए” ऐसे claims बहुत सुनने को मिलते हैं लेकिन core issue वही है जो ब्लॉग में दिखा: resource-server authorization करने वाले developers token में issuer, audience, subject जैसे base claim तक नहीं जाँचते अगर यह गलती intranet में भी हो रही है तो कोई लाभ नहीं आख़िरकार मुद्दा cloud vs self-hosting नहीं, security के मूलतः कठिन होने का है और वास्तविक समस्या आने तक सुधार का loop नहीं चलता intranet या VPN डाल देने से ऐसी security weakness खत्म नहीं हो जाती

  • अब क्या “defence in depth” शब्द भी ट्रेंड से बाहर हो गया लगता है?

  • ज्यादातर companies के लिए self-hosting अब भी बेहतर सलाह है तीन राज्यों में best roof-repair company को भी शायद आप अपना पूरा website, email और booking system चलाने नहीं देंगे इस forum के लोग शायद server setup और operations कर सकते हैं, पर वे “average user” नहीं होते

• Windows build server में RCE vulnerability मिलने के बाद bounty $0 देना बेतुका है अगर वह सिर्फ सेटिंग issue हो और true zero-day न हो, फिर भी अगर backdoor DLL से build environment खराब हो सकता है तो यह वैश्विक स्तर पर बड़ी तबाही ला सकता है

  • मैं पहले Microsoft का Windows build engineer था इस build tooling management UI की details मुझे अच्छी तरह याद नहीं (शायद मैं छोड़ने के बाद अपडेट हुए), मगर मुझे यह UI RCE करने के लिए designed नहीं लगता हमेशा NuGet से ही package लेना होता था; UI में कोई भी package/source चुनने जैसा दिखता था, लेकिन वास्तविकता में Microsoft internal NuGet feed का ही whitelist था NuGet package control हम Windows engineering टीम में बहुत गंभीरता से लेते थे बाहरी public NuGet packages पर पूर्ण प्रतिबंध था; अगर बहुत जरूरी होता तो पहले repackage करके internal source पर upload करना पड़ता था

• Microsoft में अच्छे लोग बहुत हैं, फिर भी हाल की master-key leak, engineers का PR में GPT से coding request करना, और CEO का यह कहना कि backend engineers जा रहे हैं—इन सब के बाद मैं उस company पर भरोसा नहीं कर पाता हालांकि अधिकांश लोगों के पास विकल्प भी नहीं होता फिर भी यदि कोई वहाँ बना रहता है तो वह थोड़ा गैर-जिम्मेदाराना लगता है

  • “engineers ने PR में GPT से क्या feature request किया था” — यह समझ नहीं आया शायद dotnet/runtime वाला मामला था?

• मेरा नजरिया बेहद सरल है Entra (या Azure AD जैसे नाम बदलने की स्थिति) को AuthZ (authorization) के लिए नहीं चलाना चाहिए AuthN (authentication) के लिए ठीक है, लेकिन authorization खुद implement करनी चाहिए यदि AuthZ खुद बनाई जाए तो इन समस्याओं से आसानी से बच सकते हैं *- नाम क्यों बदलते हैं यह मैं भी नहीं जानता; शायद कोई Microsoft lead यह मानता है कि “मैं नाम बदलता हूँ, इसलिए मैं मौजूद हूँ”

  • “Azure AD” नाम से यह भ्रम बनता है कि यह सिर्फ Azure में AD hosted होने का मामला है जबकि अब यह उससे कहीं ज्यादा बड़ा है

  • Entra से AuthZ implement करना संभव है बस “Assign users to this app” वाला box tick करें[1] लेकिन यह Entra में उपलब्ध एकमात्र AuthZ feature है अगर Entra में AuthZ enable नहीं किया तो यह मानना कि वह खुद authorization मैनेज करेगा, गलत अपेक्षा है आसान "allow/deny" authorization सिर्फ उन apps में meaningful है जहाँ हर user की permissions समान हो जटिल applications में user अलग-अलग access levels रखते हैं, इसलिए वास्तविक authorization ऐप के अंदर implement करनी होती है [1] management portal से user/group access assign करने का तरीका

• इसी कारण समस्या यह भी है कि Entra ID मल्टी-टेनेंट apps में किसी specific tenant को blacklist/whitelist नहीं कर सकते ऊपर से MSAL browser extensions जैसी जगह काम नहीं करता, इसलिए users को Entra ID से communication के लिए अतिरिक्त security controls खुद बनाना पड़ता है इसलिए ऐसी issues बार-बार आना स्वाभाविक है

  • Entra ID में मल्टी-टेनेंट apps के लिए specific tenant allow/deny नहीं कर पाना सच में annoying है अगर विकल्प होता कि “इस app में केवल ये tenants ही accessible हों” तो बेहतर रहता, पर अभी केवल “my tenant” या “all Azure tenants” ही उपलब्ध है मेरा workaround: app को “specific tenant only” सेट करके अन्य tenants के users को अपने tenant में invite करना या “all tenants allowed” छोड़कर वास्तविक users को groups के जरिए manage करके allow करना समझ नहीं आता कि यह technical कारणों से है या बड़े ग्राहक ने feature माँगा ही नहीं

• Azure सच में बेहद confusing है Okta के भी अपने issues हैं, लेकिन उसकी docs कहीं बेहतर हैं और महंगी होने के बाद भी Azure सेवाओं के साथ mix किए बिना उन्हें पूरी तरह अलग रख सकते हैं उस खर्च को मैं उचित मानता हूँ