SAML Attacks
Attacchi SAML
Informazioni di Base
pageSAML BasicsStrumento
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:
Eseguire il programma contro REXML 3.2.4 o versioni precedenti produrrà il seguente output:
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:
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:
pageXXE - XEE - XML External EntityLe 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:
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:
pageXSLT Server Side Injection (Extensible Stylesheet Language Transformations)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.
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:
Intercepisci la Risposta SAML.
Se la risposta contiene una firma, invia il certificato a SAML Raider Certs utilizzando il pulsante
Send Certificate to SAML Raider Certs
.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.Torna alla richiesta intercettata nel Proxy di Burp. Seleziona il nuovo certificato auto-firmato dal menu a discesa della Firma XML.
Rimuovi eventuali firme esistenti con il pulsante
Remove Signatures
.Firma il messaggio o l'affermazione con il nuovo certificato utilizzando il pulsante
(Re-)Sign Message
o(Re-)Sign Assertion
, a seconda del caso.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.
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:
Una volta che si accede a questo link, si è reindirizzati a:
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
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.
Riferimenti
Last updated