SAML Attacks
Last updated
Last updated
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)
SAMLExtractor: Uno strumento che può prendere un URL o un elenco di URL e restituisce l'URL di consumo SAML.
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:
Eseguire il programma contro REXML 3.2.4 o versioni precedenti produrrebbe invece il seguente output:
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:
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.
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.
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à.
Strategia: Viene creata un'asserzione malvagia allo stesso livello gerarchico dell'asserzione originale.
Implicazione: Intende confondere la logica aziendale nell'utilizzare i dati malevoli.
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.
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.
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.
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.
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.
Puoi utilizzare l'estensione Burp SAML Raider per analizzare la richiesta, applicare qualsiasi attacco XSW tu scelga e lanciarlo.
Se non sai che tipo di attacchi sono XXE, ti preghiamo di leggere la seguente pagina:
XXE - XEE - XML External EntityLe 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:
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
Per ulteriori informazioni su XSLT vai a:
XSLT Server Side Injection (Extensible Stylesheet Language Transformations)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.
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
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.
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
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.
I seguenti passaggi delineano il processo utilizzando l'estensione Burp SAML Raider:
Intercetta 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 autofirmato del certificato originale.
Torna alla richiesta intercettata nel Proxy di Burp. Seleziona il nuovo certificato autofirmato dal menu a discesa XML Signature.
Rimuovi eventuali firme esistenti con il pulsante Remove Signatures.
Firma il messaggio o l'asserzione con il nuovo certificato utilizzando il pulsante (Re-)Sign Message o (Re-)Sign Assertion, a seconda dei casi.
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.
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.
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.
La ricerca originale può essere consultata tramite questo link.
Durante il processo di brute forcing delle directory, è stata scoperta una pagina di logout a:
Al momento dell'accesso a questo link, si è verificato un reindirizzamento 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).
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.
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)
