SAML Attacks
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)
SAMLExtractor: एक उपकरण जो एक URL या URL की सूची ले सकता है और SAML उपभोग URL को वापस प्रिंट करता है।
XML में XML का हस्ताक्षरित भाग मेमोरी में सहेजा जाता है, फिर कुछ एन्कोडिंग/डिकोडिंग की जाती है और हस्ताक्षर की जांच की जाती है। आदर्श रूप से, उस एन्कोडिंग/डिकोडिंग को डेटा को नहीं बदलना चाहिए लेकिन उस परिदृश्य के आधार पर, जांच की जा रही डेटा और मूल डेटा समान नहीं हो सकते हैं।
उदाहरण के लिए, निम्नलिखित कोड की जांच करें:
REXML 3.2.4 या उससे पहले के संस्करण के खिलाफ प्रोग्राम चलाने पर इसके बजाय निम्नलिखित आउटपुट प्राप्त होगा:
यहाँ बताया गया है कि REXML ने ऊपर दिए गए प्रोग्राम से मूल XML दस्तावेज़ को कैसे देखा:
और यह है कि इसे पार्सिंग और सीरियलाइजेशन के एक दौर के बाद कैसे देखा गया:
कमजोरी के बारे में अधिक जानकारी और इसका दुरुपयोग कैसे किया जा सकता है:
XML Signature Wrapping attacks (XSW) में, प्रतिकूल पक्ष एक कमजोरी का लाभ उठाते हैं जो तब उत्पन्न होती है जब XML दस्तावेज़ों को दो अलग-अलग चरणों के माध्यम से संसाधित किया जाता है: signature validation और function invocation। ये हमले XML दस्तावेज़ संरचना को बदलने में शामिल होते हैं। विशेष रूप से, हमलावर जाली तत्वों को इंजेक्ट करता है जो XML Signature की वैधता को प्रभावित नहीं करते। यह हेरफेर application logic द्वारा विश्लेषित तत्वों और signature verification module द्वारा जांचे गए तत्वों के बीच एक विसंगति उत्पन्न करने के लिए है। परिणामस्वरूप, जबकि XML Signature तकनीकी रूप से वैध रहता है और सत्यापन पास करता है, एप्लिकेशन लॉजिक धोखाधड़ी वाले तत्वों को संसाधित करता है। इस प्रकार, हमलावर प्रभावी रूप से XML Signature की integrity protection और origin authentication को बायपास करता है, जिससे मनमाने सामग्री का इंजेक्शन बिना किसी पहचान के संभव हो जाता है।
निम्नलिखित हमले इस ब्लॉग पोस्ट और इस पेपर पर आधारित हैं। इसलिए आगे की जानकारी के लिए उन्हें देखें।
Strategy: एक नया रूट तत्व जो सिग्नेचर को शामिल करता है जोड़ा जाता है।
Implication: वेलिडेटर वैध "Response -> Assertion -> Subject" और हमलावर के "evil new Response -> Assertion -> Subject" के बीच भ्रमित हो सकता है, जिससे डेटा इंटीग्रिटी समस्याएँ उत्पन्न हो सकती हैं।
Difference from XSW #1: एक एन्वेलपिंग सिग्नेचर के बजाय एक डिटैच्ड सिग्नेचर का उपयोग करता है।
Implication: "evil" संरचना, XSW #1 के समान, इंटीग्रिटी चेक के बाद व्यवसायिक लॉजिक को धोखा देने का प्रयास करती है।
Strategy: एक evil Assertion को मूल assertion के समान पदानुक्रम स्तर पर तैयार किया जाता है।
Implication: व्यवसायिक लॉजिक को दुर्भावनापूर्ण डेटा का उपयोग करने के लिए भ्रमित करने का इरादा है।
Difference from XSW #3: मूल Assertion एक डुप्लिकेट (evil) Assertion का बच्चा बन जाता है।
Implication: XSW #3 के समान लेकिन XML संरचना को अधिक आक्रामकता से बदलता है।
Unique Aspect: न तो Signature और न ही मूल Assertion मानक कॉन्फ़िगरेशन (enveloped/enveloping/detached) का पालन करते हैं।
Implication: कॉपी किया गया Assertion Signature को एन्वेलप करता है, अपेक्षित दस्तावेज़ संरचना को संशोधित करता है।
Strategy: XSW #4 और #5 के समान स्थान सम्मिलन, लेकिन एक मोड़ के साथ।
Implication: कॉपी किया गया Assertion Signature को एन्वेलप करता है, जो फिर मूल Assertion को एन्वेलप करता है, एक नेस्टेड धोखाधड़ी संरचना बनाता है।
Strategy: एक Extensions तत्व को कॉपी किए गए Assertion के बच्चे के रूप में सम्मिलित किया जाता है।
Implication: यह Extensions तत्व की कम प्रतिबंधात्मक स्कीमा का लाभ उठाता है ताकि स्कीमा सत्यापन प्रतिरोध उपायों को बायपास किया जा सके, विशेष रूप से OpenSAML जैसी लाइब्रेरी में।
Difference from XSW #7: हमले के एक रूप के लिए एक और कम प्रतिबंधात्मक XML तत्व का उपयोग करता है।
Implication: मूल Assertion कम प्रतिबंधात्मक तत्व का बच्चा बन जाता है, XSW #7 में उपयोग की गई संरचना को उलट देता है।
आप अनुरोध को पार्स करने, कोई भी XSW हमला लागू करने और इसे लॉन्च करने के लिए Burp एक्सटेंशन SAML Raider का उपयोग कर सकते हैं।
यदि आप नहीं जानते कि XXE हमले किस प्रकार के होते हैं, तो कृपया निम्नलिखित पृष्ठ पढ़ें:
XXE - XEE - XML External EntitySAML Responses deflated और base64 encoded XML दस्तावेज़ होते हैं और XML External Entity (XXE) हमलों के प्रति संवेदनशील हो सकते हैं। SAML Response की XML संरचना में हेरफेर करके, हमलावर XXE कमजोरियों का लाभ उठाने का प्रयास कर सकते हैं। यहाँ इस प्रकार के हमले को कैसे देखा जा सकता है:
आप Burp एक्सटेंशन SAML Raider का उपयोग करके SAML अनुरोध से POC उत्पन्न कर सकते हैं ताकि संभावित XXE कमजोरियों और SAML कमजोरियों का परीक्षण किया जा सके।
इस वार्ता को भी देखें: https://www.youtube.com/watch?v=WHn-6xHL7mI
XSLT के बारे में अधिक जानकारी के लिए जाएं:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)Extensible Stylesheet Language Transformations (XSLT) का उपयोग XML दस्तावेजों को HTML, JSON, या PDF जैसे विभिन्न प्रारूपों में परिवर्तित करने के लिए किया जा सकता है। यह महत्वपूर्ण है कि XSLT परिवर्तनों को डिजिटल हस्ताक्षर के सत्यापन से पहले किया जाता है। इसका मतलब है कि एक हमला सफल हो सकता है भले ही हस्ताक्षर मान्य न हो; एक स्व-हस्ताक्षरित या अमान्य हस्ताक्षर आगे बढ़ने के लिए पर्याप्त है।
यहां आप इस प्रकार की कमजोरियों की जांच के लिए एक POC पा सकते हैं, हैक्ट्रिक्स पृष्ठ में जो इस अनुभाग की शुरुआत में उल्लेखित है, आप पेलोड्स के लिए देख सकते हैं।
आप Burp एक्सटेंशन SAML Raider का उपयोग करके SAML अनुरोध से POC उत्पन्न कर सकते हैं ताकि संभावित XSLT कमजोरियों का परीक्षण किया जा सके।
इस वार्ता को भी देखें: https://www.youtube.com/watch?v=WHn-6xHL7mI
XML Signature Exclusion SAML कार्यान्वयन के व्यवहार का अवलोकन करता है जब Signature तत्व अनुपस्थित होता है। यदि यह तत्व गायब है, तो signature validation नहीं हो सकता है, जिससे यह कमजोर हो जाता है। इसे परीक्षण करने के लिए उन सामग्री को बदलना संभव है जो आमतौर पर हस्ताक्षर द्वारा सत्यापित की जाती हैं।
आप Burp एक्सटेंशन SAML Raider का उपयोग कर सकते हैं। SAML Response को इंटरसेप्ट करें और Remove Signatures पर क्लिक करें। ऐसा करने पर सभी Signature तत्व हटा दिए जाते हैं।
हस्ताक्षरों को हटाने के बाद, अनुरोध को लक्ष्य की ओर बढ़ने की अनुमति दें। यदि Signature सेवा द्वारा आवश्यक नहीं है
Certificate Faking एक तकनीक है जो यह परीक्षण करती है कि Service Provider (SP) सही तरीके से सत्यापित करता है कि SAML Message एक विश्वसनीय Identity Provider (IdP) द्वारा हस्ताक्षरित है। इसमें SAML Response या Assertion को हस्ताक्षरित करने के लिए *self-signed certificate का उपयोग करना शामिल है, जो SP और IdP के बीच विश्वास सत्यापन प्रक्रिया का मूल्यांकन करने में मदद करता है।
SAML Raider Burp एक्सटेंशन का उपयोग करके प्रक्रिया के निम्नलिखित चरण हैं:
SAML Response को इंटरसेप्ट करें।
यदि प्रतिक्रिया में एक हस्ताक्षर है, तो Send Certificate to SAML Raider Certs बटन का उपयोग करके प्रमाणपत्र को SAML Raider Certs पर भेजें।
SAML Raider Certificates टैब में, आयातित प्रमाणपत्र का चयन करें और एक self-signed क्लोन बनाने के लिए Save and Self-Sign पर क्लिक करें।
Burp के Proxy में इंटरसेप्ट किए गए अनुरोध पर वापस जाएं। XML Signature ड्रॉपडाउन से नया self-signed प्रमाणपत्र चुनें।
Remove Signatures बटन का उपयोग करके किसी भी मौजूदा हस्ताक्षरों को हटा दें।
(Re-)Sign Message या (Re-)Sign Assertion बटन का उपयोग करके नए प्रमाणपत्र के साथ संदेश या assertion पर हस्ताक्षर करें, जैसा कि उपयुक्त हो।
हस्ताक्षरित संदेश को आगे बढ़ाएं। सफल प्रमाणीकरण यह संकेत करता है कि SP आपके self-signed प्रमाणपत्र द्वारा हस्ताक्षरित संदेशों को स्वीकार करता है, जो SAML संदेशों के सत्यापन प्रक्रिया में संभावित कमजोरियों को उजागर करता है।
Token Recipient Confusion और Service Provider Target Confusion यह जांचने में शामिल हैं कि Service Provider सही तरीके से प्रतिक्रिया के इच्छित प्राप्तकर्ता को सत्यापित करता है। मूल रूप से, एक Service Provider को एक प्रमाणीकरण प्रतिक्रिया को अस्वीकार करना चाहिए यदि यह किसी अन्य प्रदाता के लिए थी। यहां महत्वपूर्ण तत्व Recipient फ़ील्ड है, जो SAML Response के SubjectConfirmationData तत्व के भीतर पाया जाता है। यह फ़ील्ड एक URL निर्दिष्ट करता है जो इंगित करता है कि Assertion को कहाँ भेजा जाना चाहिए। यदि वास्तविक प्राप्तकर्ता इच्छित Service Provider से मेल नहीं खाता है, तो Assertion को अमान्य माना जाना चाहिए।
SAML Token Recipient Confusion (SAML-TRC) हमले के लिए कुछ शर्तें पूरी होनी चाहिए। सबसे पहले, Service Provider (जिसे SP-Legit कहा जाता है) पर एक मान्य खाता होना चाहिए। दूसरे, लक्षित Service Provider (SP-Target) को उसी Identity Provider से टोकन स्वीकार करना चाहिए जो SP-Legit की सेवा करता है।
इन शर्तों के तहत हमले की प्रक्रिया सीधी है। SP-Legit के साथ साझा Identity Provider के माध्यम से एक प्रामाणिक सत्र शुरू किया जाता है। Identity Provider से SP-Legit के लिए SAML Response को इंटरसेप्ट किया जाता है। इस इंटरसेप्ट किए गए SAML Response को, जो मूल रूप से SP-Legit के लिए था, SP-Target की ओर पुनर्निर्देशित किया जाता है। इस हमले में सफलता को SP-Target द्वारा Assertion को स्वीकार करने के रूप में मापा जाता है, जो SP-Legit के लिए उपयोग किए गए समान खाता नाम के तहत संसाधनों तक पहुंच प्रदान करता है।
मूल शोध इस लिंक के माध्यम से पहुँचा जा सकता है।
डायरेक्टरी ब्रूट फोर्सिंग की प्रक्रिया के दौरान, एक लॉगआउट पृष्ठ खोजा गया:
इस लिंक को एक्सेस करने पर, एक रीडायरेक्शन हुआ:
यह दर्शाता है कि base पैरामीटर एक URL स्वीकार करता है। इसे ध्यान में रखते हुए, विचार आया कि URL को javascript:alert(123); के साथ प्रतिस्थापित किया जाए ताकि XSS (Cross-Site Scripting) हमले को प्रारंभ किया जा सके।
SAMLExtractor टूल का उपयोग uberinternal.com के उपडोमेन का विश्लेषण करने के लिए किया गया था जो समान पुस्तकालय का उपयोग कर रहे थे। इसके बाद, oidauth/prompt पृष्ठ को लक्षित करने के लिए एक स्क्रिप्ट विकसित की गई। यह स्क्रिप्ट डेटा इनपुट करके और यह जांचकर XSS (Cross-Site Scripting) के लिए परीक्षण करती है कि क्या यह आउटपुट में परिलक्षित होता है। उन मामलों में जहां इनपुट वास्तव में परिलक्षित होता है, स्क्रिप्ट पृष्ठ को कमजोर के रूप में चिह्नित करती है।
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
