Az - Tokens & Public Applications
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Entra ID माइक्रोसॉफ्ट का क्लाउड-आधारित पहचान और पहुंच प्रबंधन (IAM) प्लेटफ़ॉर्म है, जो Microsoft 365 और Azure Resource Manager जैसी सेवाओं के लिए मौलिक प्रमाणीकरण और प्राधिकरण प्रणाली के रूप में कार्य करता है। Azure AD OAuth 2.0 प्राधिकरण ढांचे और OpenID Connect (OIDC) प्रमाणीकरण प्रोटोकॉल को संसाधनों तक पहुंच प्रबंधित करने के लिए लागू करता है।
OAuth 2.0 में मुख्य प्रतिभागी:
Resource Server (RS): संसाधनों की रक्षा करता है जो संसाधन मालिक के पास हैं।
Resource Owner (RO): आमतौर पर एक अंतिम उपयोगकर्ता जो संरक्षित संसाधनों का मालिक होता है।
Client Application (CA): एक एप्लिकेशन जो संसाधन मालिक की ओर से संसाधनों तक पहुंच प्राप्त करने का प्रयास करता है।
Authorization Server (AS): प्रमाणीकरण और प्राधिकरण के बाद क्लाइंट एप्लिकेशनों को एक्सेस टोकन जारी करता है।
Scopes और Consent:
Scopes: संसाधन सर्वर पर परिभाषित सूक्ष्म अनुमतियाँ जो पहुँच स्तर निर्दिष्ट करती हैं।
Consent: वह प्रक्रिया जिसके द्वारा एक संसाधन मालिक एक क्लाइंट एप्लिकेशन को विशिष्ट स्कोप के साथ संसाधनों तक पहुँच प्राप्त करने की अनुमति देता है।
Microsoft 365 एकीकरण:
Microsoft 365 IAM के लिए Azure AD का उपयोग करता है और इसमें कई "पहली-पार्टी" OAuth एप्लिकेशन शामिल हैं।
ये एप्लिकेशन गहराई से एकीकृत होते हैं और अक्सर आपस में निर्भर सेवा संबंध होते हैं।
उपयोगकर्ता अनुभव को सरल बनाने और कार्यक्षमता बनाए रखने के लिए, Microsoft इन पहली-पार्टी एप्लिकेशनों को "अर्थित सहमति" या "पूर्व-सहमति" प्रदान करता है।
Implied Consent: कुछ एप्लिकेशनों को स्पष्ट उपयोगकर्ता या प्रशासक अनुमोदन के बिना विशिष्ट स्कोप तक पहुँच स्वतः प्रदान की जाती है।
ये पूर्व-सहमति वाले स्कोप आमतौर पर उपयोगकर्ताओं और प्रशासकों दोनों से छिपे होते हैं, जिससे वे मानक प्रबंधन इंटरफेस में कम दिखाई देते हैं।
Client Application Types:
Confidential Clients:
अपने स्वयं के क्रेडेंशियल्स (जैसे, पासवर्ड या प्रमाणपत्र) रखते हैं।
प्राधिकरण सर्वर के लिए सुरक्षित रूप से प्रमाणीकरण कर सकते हैं।
Public Clients:
अद्वितीय क्रेडेंशियल्स नहीं होते हैं।
प्राधिकरण सर्वर के लिए सुरक्षित रूप से प्रमाणीकरण नहीं कर सकते हैं।
सुरक्षा निहितार्थ: एक हमलावर टोकन मांगते समय एक सार्वजनिक क्लाइंट एप्लिकेशन का अनुकरण कर सकता है, क्योंकि प्राधिकरण सर्वर के लिए एप्लिकेशन की वैधता की पुष्टि करने का कोई तंत्र नहीं है।
OIDC में तीन प्रकार के टोकन होते हैं:
Access Tokens: क्लाइंट इस टोकन को संसाधन सर्वर को संसाधनों तक पहुँचने के लिए प्रस्तुत करता है। इसे केवल उपयोगकर्ता, क्लाइंट और संसाधन के विशिष्ट संयोजन के लिए उपयोग किया जा सकता है और समाप्ति तक रद्द नहीं किया जा सकता - जो डिफ़ॉल्ट रूप से 1 घंटा है।
ID Tokens: क्लाइंट को यह टोकन प्राधिकरण सर्वर से प्राप्त होता है। इसमें उपयोगकर्ता के बारे में बुनियादी जानकारी होती है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है।
Refresh Tokens: एक्सेस टोकन के साथ क्लाइंट को प्रदान किया जाता है। इसका उपयोग नए एक्सेस और ID टोकन प्राप्त करने के लिए किया जाता है। यह उपयोगकर्ता और क्लाइंट के विशिष्ट संयोजन से बंधा होता है और इसे रद्द किया जा सकता है। डिफ़ॉल्ट समाप्ति 90 दिन है निष्क्रिय रिफ्रेश टोकन के लिए और सक्रिय टोकन के लिए कोई समाप्ति नहीं (एक रिफ्रेश टोकन से नए रिफ्रेश टोकन प्राप्त करना संभव है)।
एक रिफ्रेश टोकन को एक aud, कुछ scopes, और एक tenant से जोड़ा जाना चाहिए और इसे केवल उस aud, scopes (और अधिक नहीं) और tenant के लिए एक्सेस टोकन उत्पन्न करने में सक्षम होना चाहिए। हालाँकि, यह FOCI एप्लिकेशन टोकन के साथ ऐसा नहीं है।
एक रिफ्रेश टोकन एन्क्रिप्टेड होता है और केवल माइक्रोसॉफ्ट इसे डिक्रिप्ट कर सकता है।
नया रिफ्रेश टोकन प्राप्त करने से पिछले रिफ्रेश टोकन को रद्द नहीं किया जाता है।
Conditional access के लिए जानकारी JWT के अंदर स्टोर की जाती है। इसलिए, यदि आप अनुमत IP पते से टोकन का अनुरोध करते हैं, तो वह IP टोकन में स्टोर किया जाएगा और फिर आप उस टोकन का उपयोग गैर-अनुमत IP से संसाधनों तक पहुँचने के लिए कर सकते हैं।
"aud" फ़ील्ड में निर्दिष्ट फ़ील्ड resource server (एप्लिकेशन) है जिसका उपयोग लॉगिन करने के लिए किया जाता है।
कमांड az account get-access-token --resource-type [...] निम्नलिखित प्रकारों का समर्थन करता है और इनमें से प्रत्येक परिणामस्वरूप एक्सेस टोकन में एक विशिष्ट "aud" जोड़ेगा:
ध्यान दें कि निम्नलिखित केवल az account get-access-token द्वारा समर्थित APIs हैं लेकिन और भी हैं।
एक एक्सेस टोकन का स्कोप एक्सेस टोकन JWT के अंदर scp कुंजी के अंदर स्टोर किया जाता है। ये स्कोप परिभाषित करते हैं कि एक्सेस टोकन को क्या पहुँच प्राप्त है।
यदि एक JWT को एक विशिष्ट API से संपर्क करने की अनुमति है लेकिन अनुरोधित क्रिया को करने के लिए स्कोप नहीं है, तो यह उस JWT के साथ क्रिया करने में असमर्थ होगा।
पहले उल्लेख किया गया था कि रिफ्रेश टोकन को स्कोप से जोड़ा जाना चाहिए जिसके साथ इसे उत्पन्न किया गया था, ऐप्लिकेशन और टेनेंट से जिसे यह उत्पन्न किया गया था। यदि इनमें से कोई भी सीमा टूटती है, तो विशेषाधिकार बढ़ाना संभव है क्योंकि अन्य संसाधनों और टेनेंट के लिए एक्सेस टोकन उत्पन्न करना संभव होगा जिन तक उपयोगकर्ता की पहुंच है और अधिक स्कोप के साथ जितना कि इसे मूल रूप से इरादा किया गया था।
इसके अलावा, यह सभी रिफ्रेश टोकन के साथ संभव है Microsoft identity platform (Microsoft Entra खाते, Microsoft व्यक्तिगत खाते, और फेसबुक और गूगल जैसे सामाजिक खाते) क्योंकि दस्तावेज़ में उल्लेख किया गया है: "रिफ्रेश टोकन उपयोगकर्ता और क्लाइंट के संयोजन से बंधे होते हैं, लेकिन किसी संसाधन या टेनेंट से बंधे नहीं होते। एक क्लाइंट रिफ्रेश टोकन का उपयोग करके एक्सेस टोकन प्राप्त कर सकता है किसी भी संसाधन और टेनेंट के संयोजन में जहां इसे ऐसा करने की अनुमति है। रिफ्रेश टोकन एन्क्रिप्टेड होते हैं और केवल Microsoft identity platform उन्हें पढ़ सकता है।"
इसके अलावा, ध्यान दें कि FOCI एप्लिकेशन सार्वजनिक एप्लिकेशन हैं, इसलिए सर्वर पर प्रमाणीकरण के लिए कोई रहस्य आवश्यक नहीं है।
फिर ज्ञात FOCI क्लाइंट्स की रिपोर्ट मूल शोध में की गई है, जिसे यहां पाया जा सकता है।
पिछले उदाहरण कोड के साथ आगे बढ़ते हुए, इस कोड में एक अलग स्कोप के लिए एक नया टोकन मांगा गया है:
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
