Impara e pratica il hacking AWS:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Impara e pratica il hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos su github.
[**SAMLExtractor**](https://github.com/fadyosman/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**.
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**](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) **e** [**questo documento**](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf). Quindi controllali per ulteriori dettagli.
* **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.
* **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.
Puoi utilizzare l'estensione Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) per analizzare la richiesta, applicare qualsiasi attacco XSW tu scelga e lanciarlo.
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:
Puoi anche utilizzare l'estensione di Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) per generare il POC da una richiesta SAML per testare possibili vulnerabilità XXE e vulnerabilità SAML.
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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) per generare il POC da una richiesta SAML per testare possibili vulnerabilità XSLT.
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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). Intercetta la risposta SAML e clicca su `Remove Signatures`. In questo modo **tutti** gli elementi Signature vengono rimossi.
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](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):
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.
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.
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](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/).
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**](https://github.com/fadyosman/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:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Impara e pratica il hacking GCP: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Controlla i [**piani di abbonamento**](https://github.com/sponsors/carlospolop)!
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Condividi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
