mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-16 09:48:14 +00:00
150 lines
11 KiB
Markdown
150 lines
11 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
<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 [**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 a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
|
|
|
</details>
|
|
|
|
**La tecnica di questo post è stata presa dal video: [https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s](https://www.youtube.com/watch?v=suxDcYViwao\&t=1343s)**
|
|
|
|
|
|
## Desincronizzazione della coda delle richieste HTTP
|
|
|
|
Innanzitutto, questa tecnica **sfrutta una vulnerabilità di Smuggling delle Richieste HTTP**, quindi è necessario sapere cosa sia:
|
|
|
|
La **principale** **differenza** tra questa tecnica e un comune Smuggling delle Richieste HTTP è che, **anziché attaccare la richiesta della vittima aggiungendo un prefisso ad essa**, andremo a **rivelare o modificare la risposta che la vittima riceve**. Ciò viene fatto inviando non solo 1 richiesta e mezza per sfruttare il Smuggling delle Richieste HTTP, ma **inviando 2 richieste complete per desincronizzare la coda delle risposte dei proxy**.
|
|
|
|
Questo perché saremo in grado di **desincronizzare la coda delle risposte** in modo che la **risposta** della **richiesta legittima** della **vittima venga inviata all'attaccante**, o **iniettando contenuti controllati dall'attaccante nella risposta alla vittima**.
|
|
|
|
### Desincronizzazione della pipeline HTTP
|
|
|
|
HTTP/1.1 consente di **richiedere risorse diverse senza dover attendere quelle precedenti**. Pertanto, se c'è un **proxy** in mezzo, è compito del proxy **mantenere una corrispondenza sincronizzata delle richieste inviate al backend e delle risposte che arrivano da esso**.
|
|
|
|
Tuttavia, c'è un problema nella desincronizzazione della coda delle risposte. Se un attaccante invia un attacco di Smuggling delle Risposte HTTP e le risposte alla **richiesta iniziale e a quella smugglata vengono risposte immediatamente**, la risposta smugglata non verrà inserita nella coda della risposta della vittima ma verrà **semplicemente scartata come errore**.
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
Pertanto, è necessario che la **richiesta smugglata richieda più tempo per essere elaborata** all'interno del server di backend. Di conseguenza, quando la richiesta smugglata viene elaborata, la comunicazione con l'attaccante sarà terminata.
|
|
|
|
Se in questa situazione specifica una **vittima ha inviato una richiesta** e la **richiesta smugglata viene risposta prima** della richiesta legittima, la **risposta smugglata verrà inviata alla vittima**. Pertanto, l'attaccante **controllerà la richiesta "eseguita" dalla vittima**.
|
|
|
|
Inoltre, se l'**attaccante esegue una richiesta** e la **risposta legittima** alla **richiesta della vittima viene risposta prima** della richiesta dell'attaccante. La **risposta alla vittima verrà inviata all'attaccante**, **rubando** la risposta alla vittima (che può contenere ad esempio l'intestazione **Set-Cookie**).
|
|
|
|
 (1).png>)
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
### Iniezioni nidificate multiple
|
|
|
|
Un'altra **differenza interessante** rispetto al comune **Smuggling delle Richieste HTTP** è che, in un attacco di smuggling comune, l'**obiettivo** è **modificare l'inizio della richiesta della vittima** in modo che esegua un'azione inaspettata. In un attacco di **Smuggling delle Risposte HTTP**, poiché si inviano richieste complete, è possibile **iniettare in un payload decine di risposte** che **desincronizzeranno decine di utenti** che riceveranno le **risposte iniettate**.
|
|
|
|
Oltre a poter **distribuire più facilmente decine di exploit** tra gli utenti legittimi, ciò potrebbe anche essere utilizzato per causare un **DoS** nel server.
|
|
|
|
### Organizzazione dell'exploit
|
|
|
|
Come spiegato in precedenza, per sfruttare questa tecnica è necessario che il **primo messaggio smugglato** nel server richieda **molto tempo per essere elaborato**.
|
|
|
|
Questa richiesta **che richiede molto tempo è sufficiente** se si vuole solo **provare a rubare la risposta delle vittime**. Ma se si desidera eseguire un exploit più complesso, questa sarà una struttura comune per l'exploit.
|
|
|
|
Prima di tutto la **richiesta iniziale** che sfrutta il **Smuggling delle Richieste HTTP**, quindi la **richiesta che richiede molto tempo** e quindi **1 o più richieste di payload** le cui risposte verranno inviate alle vittime.
|
|
|
|
## Sfruttare la desincronizzazione della coda delle risposte HTTP
|
|
|
|
### Catturare le richieste di altri utenti <a href="#capturing-other-users-requests" id="capturing-other-users-requests"></a>
|
|
|
|
Come con i payload noti di Smuggling delle Richieste HTTP, è possibile **rubare la richiesta delle vittime** con una differenza importante: in questo caso è sufficiente che il **contenuto inviato venga riflettuto nella risposta**, non è necessario uno storage persistente.
|
|
|
|
Innanzitutto, l'attaccante invia un payload contenente una **richiesta POST finale con il parametro riflettuto** alla fine e un grande Content-Length
|
|
|
|
.png>)
|
|
|
|
Quindi, una volta che la **richiesta iniziale** (blu) è stata **elaborata** e **mentre** quella **che richiede tempo** viene elaborata (gialla), la **prossima richiesta che arriva da una vittima** verrà **aggiunta nella coda subito dopo il parametro riflettuto**:
|
|
|
|
 (1).png>)
|
|
|
|
Quindi, la **vittima** riceverà la **risposta alla richiesta che richiede tempo** e se nel frattempo l'**attaccante invia un'altra richiesta**, la **risposta dalla richiesta di contenuto riflettuto gli verrà inviata**.
|
|
|
|
## Desincronizzazione delle risposte
|
|
|
|
Fino a questo punto, abbiamo imparato come sfruttare gli attacchi di Smuggling delle Richieste HTTP per **controllare** la **richiesta** di cui un **client riceverà la risposta** e come è possibile **rubare la risposta che era destinata alla vittima**.
|
|
|
|
Ma è ancora possibile **desincronizzare ancora di più le risposte**.
|
|
|
|
Ci sono richieste interessanti come la richiesta **HEAD** che sono specificate per non avere **alcun contenuto nel corpo delle risposte** e che dovrebbero (devono) **contenere la Content-Length** della richiesta come **se fosse una richiesta GET**.
|
|
|
|
Pertanto, se un attaccante **inietta** una richiesta **HEAD**, come in queste immagini:
|
|
|
|
.png>)
|
|
### Confusione del contenuto
|
|
|
|
Seguendo l'esempio precedente, sapendo che puoi **controllare il corpo** della richiesta il cui risposta riceverà la vittima e che una risposta **HEAD** di solito contiene nei suoi header il **Content-Type e il Content-Length**, puoi **inviare una richiesta come quella seguente** per causare XSS nella vittima senza che la pagina sia vulnerabile a XSS:
|
|
|
|
 (1) (1) (1) (1).png>)
|
|
|
|
### Avvelenamento della cache
|
|
|
|
Sfruttando l'attacco di confusione del contenuto della risposta precedentemente commentato, **se la cache memorizza la risposta alla richiesta effettuata dalla vittima e questa risposta è un'iniezione che causa XSS, allora la cache viene avvelenata**.
|
|
|
|
Richiesta malevola contenente il payload XSS:
|
|
|
|
 (1).png>)
|
|
|
|
Risposta malevola alla vittima che contiene l'header che indica alla cache di memorizzare la risposta:
|
|
|
|
 (1).png>)
|
|
|
|
{% hint style="warning" %}
|
|
Nota che in questo caso se la **"vittima" è l'attaccante** può ora eseguire **l'avvelenamento della cache in URL arbitrari** poiché può **controllare l'URL che verrà memorizzato nella cache** con la risposta malevola.
|
|
{% endhint %}
|
|
|
|
### Inganno della cache web
|
|
|
|
Questo attacco è simile al precedente, ma **anziché iniettare un payload all'interno della cache, l'attaccante memorizzerà le informazioni della vittima all'interno della cache:**
|
|
|
|
 (1) (1).png>)
|
|
|
|
### Splitting della risposta
|
|
|
|
L'**obiettivo** di questo attacco è sfruttare nuovamente la **desincronizzazione della risposta** per **far sì che il proxy invii una risposta generata al 100% dall'attaccante**.
|
|
|
|
Per raggiungere questo obiettivo, l'attaccante deve trovare un endpoint dell'applicazione web che **rifletta alcuni valori all'interno della risposta** e **conoscere la lunghezza del contenuto della risposta HEAD**.
|
|
|
|
Invierà un **exploit** come:
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
Dopo che la prima richiesta viene risolta e inviata all'attaccante, la **richiesta della vittima viene aggiunta alla coda**:
|
|
|
|
 (1) (1) (1).png>)
|
|
|
|
La vittima riceverà come risposta la **risposta HEAD + il contenuto della risposta della seconda richiesta (contenente parte dei dati riflessi):**
|
|
|
|
 (1).png>)
|
|
|
|
Tuttavia, nota come i **dati riflessi avevano una dimensione in base al Content-Length** della risposta **HEAD** che **ha generato una risposta HTTP valida nella coda delle risposte**.
|
|
|
|
Pertanto, la **prossima richiesta della seconda vittima** riceverà come **risposta qualcosa completamente creato dall'attaccante**. Poiché la risposta è completamente creata dall'attaccante, può anche **far memorizzare la risposta al proxy**.
|
|
|
|
|
|
<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>
|