mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 06:30:37 +00:00
159 lines
11 KiB
Markdown
159 lines
11 KiB
Markdown
# HTTP Response Smuggling / Desync
|
|
|
|
{% hint style="success" %}
|
|
Impara e pratica Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Impara e pratica Hacking GCP: <img src="/.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)
|
|
|
|
<details>
|
|
|
|
<summary>Supporta HackTricks</summary>
|
|
|
|
* 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.
|
|
|
|
</details>
|
|
{% endhint %}
|
|
|
|
**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
|
|
|
|
Prima di tutto, questa tecnica **sfrutta una vulnerabilità di HTTP Request Smuggling**, quindi devi sapere cos'è:
|
|
|
|
La **principale** **differenza** tra questa tecnica e un comune HTTP Request smuggling è che **invece** di **attaccare** la **richiesta** della **vittima** **aggiungendo un prefisso**, andremo a **leakare o modificare la risposta che la vittima riceve**. Questo viene fatto, invece di inviare 1 richiesta e mezza per abusare dell'HTTP Request smuggling, **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**.
|
|
|
|
### Desync della Pipeline HTTP
|
|
|
|
HTTP/1.1 consente di richiedere **risorse diverse senza dover aspettare quelle precedenti**. Pertanto, se c'è un **proxy** nel **mezzo**, è compito del proxy **mantenere una corrispondenza sincronizzata delle richieste inviate al backend e delle risposte provenienti da esso**.
|
|
|
|
Tuttavia, c'è un problema nella desincronizzazione della coda delle risposte. Se un attaccante invia un attacco di HTTP Response smuggling e le risposte alla **richiesta iniziale e a quella smuggled vengono risposte immediatamente**, la risposta smuggled non verrà inserita nella coda della risposta della vittima ma verrà **semplicemente scartata come errore**.
|
|
|
|
.png>)
|
|
|
|
Pertanto, è necessario che la **richiesta smuggled** **richieda più tempo per essere elaborata** all'interno del server backend. Pertanto, quando la richiesta smuggled viene elaborata, la comunicazione con l'attaccante sarà terminata.
|
|
|
|
Se in questa situazione specifica una **vittima ha inviato una richiesta** e la **richiesta smuggled viene risolta prima** della richiesta legittima, la **risposta smuggled verrà inviata alla vittima**. Pertanto, l'attaccante controllerà la **richiesta "eseguita" dalla vittima**.
|
|
|
|
Inoltre, se l'**attaccante esegue poi 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**).
|
|
|
|
.png>)
|
|
|
|
.png>)
|
|
|
|
### Iniezioni Annidate Multiple
|
|
|
|
Un'altra **differenza interessante** con il comune **HTTP Request Smuggling** è 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 HTTP Response smuggling**, poiché stai **inviando richieste complete**, puoi **iniettare in un payload decine di risposte** che andranno a **desincronizzare decine di utenti** che riceveranno le **risposte iniettate**.
|
|
|
|
Oltre a poter **distribuire più facilmente decine di exploit** tra utenti legittimi, questo potrebbe anche essere utilizzato per causare un **DoS** nel server.
|
|
|
|
### Organizzazione dell'Exploit
|
|
|
|
Come spiegato in precedenza, per abusare di questa tecnica, è necessario che il **primo messaggio smuggled** nel server **richieda molto tempo per essere elaborato**.
|
|
|
|
Questa **richiesta che richiede tempo è sufficiente** se vogliamo solo **cercare di rubare la risposta della vittima.** Ma se vuoi eseguire un exploit più complesso, questa sarà una struttura comune per l'exploit.
|
|
|
|
Prima di tutto la **richiesta iniziale** che sfrutta **HTTP** **Request** **smuggling**, poi la **richiesta che richiede tempo** e infine **1 o più richieste payload** le cui risposte verranno inviate alle vittime.
|
|
|
|
## Abusare della 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 HTTP Request Smuggling, puoi **rubare la richiesta della vittima** con una differenza importante: in questo caso hai solo bisogno che il **contenuto inviato venga riflesso nella risposta**, **non è necessario alcun storage persistente**.
|
|
|
|
Prima, l'attaccante invia un payload contenente una **richiesta POST finale con il parametro riflesso** alla fine e un grande Content-Length
|
|
|
|
.png>)
|
|
|
|
Poi, una volta che la **richiesta iniziale** (blu) è stata **elaborata** e **mentre** quella **sonnolenta** viene elaborata (gialla), la **prossima richiesta che arriva da una vittima** verrà **aggiunta nella coda subito dopo il parametro riflesso**:
|
|
|
|
.png>)
|
|
|
|
Poi, la **vittima** riceverà la **risposta alla richiesta sonnacchiosa** e se nel frattempo l'**attaccante** **ha inviato** **un'altra** **richiesta**, la **risposta dalla richiesta di contenuto riflesso verrà inviata a lui**.
|
|
|
|
## Desincronizzazione della Risposta
|
|
|
|
Fino a questo punto, abbiamo imparato come abusare degli attacchi di HTTP Request Smuggling per **controllare** la **richiesta** **la cui** **risposta** un **client** riceverà e come puoi poi **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 all'interno del corpo delle risposte** e che dovrebbero (devono) **contenere il Content-Length** della richiesta come **se fosse una richiesta GET**.
|
|
|
|
Pertanto, se un attaccante **inietta** una **richiesta HEAD**, come in queste immagini:
|
|
|
|
.png>)
|
|
|
|
Poi, **una volta che quella blu viene risolta per l'attaccante**, la prossima richiesta della vittima verrà introdotta nella coda:
|
|
|
|
.png>)
|
|
|
|
Poi, la **vittima** riceverà la **risposta** dalla **richiesta HEAD**, che **conterrà un Content-Length ma nessun contenuto**. Pertanto, il proxy **non invierà questa risposta** alla vittima, ma **attenderà** un **contenuto**, che in realtà sarà la **risposta alla richiesta gialla** (anch'essa iniettata dall'attaccante):
|
|
|
|
.png>)
|
|
|
|
### Confusione del Contenuto
|
|
|
|
Seguendo l'esempio precedente, sapendo che puoi **controllare il corpo** della richiesta la cui risposta riceverà la vittima e che una **risposta HEAD** di solito contiene nelle sue intestazioni il **Content-Type e il Content-Length**, puoi **inviare una richiesta come la seguente** per **causare XSS** nella vittima senza che la pagina sia vulnerabile a XSS:
|
|
|
|
.png>)
|
|
|
|
### Avvelenamento della Cache
|
|
|
|
Abusando dell'attacco di Confusione del Contenuto desincronizzato della risposta precedentemente commentato, **se la cache memorizza la risposta alla richiesta eseguita dalla vittima e questa risposta è una iniettata che causa un XSS, allora la cache è avvelenata**.
|
|
|
|
Richiesta malevola contenente il payload XSS:
|
|
|
|
.png>)
|
|
|
|
Risposta malevola alla vittima che contiene l'intestazione che indica alla cache di memorizzare la risposta:
|
|
|
|
.png>)
|
|
|
|
{% hint style="warning" %}
|
|
Nota che in questo caso se la **"vittima" è l'attaccante** ora può eseguire **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 **invece di iniettare un payload all'interno della cache, l'attaccante memorizzerà informazioni sulla vittima all'interno della cache:**
|
|
|
|
.png>)
|
|
|
|
### Suddivisione della Risposta
|
|
|
|
L'**obiettivo** di questo attacco è abusare nuovamente della **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 **riflette alcuni valori all'interno della risposta** e **conoscere la lunghezza del contenuto della risposta HEAD**.
|
|
|
|
Invierà un **exploit** come:
|
|
|
|
.png>)
|
|
|
|
Dopo che la prima richiesta è stata risolta e restituita all'attaccante, la **richiesta della vittima viene aggiunta nella coda**:
|
|
|
|
.png>)
|
|
|
|
La vittima riceverà come risposta la **risposta HEAD + il contenuto della risposta della seconda richiesta (contenente parte dei dati riflessi):**
|
|
|
|
.png>)
|
|
|
|
Tuttavia, nota come i **dati riflessi avessero una dimensione secondo il 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 sì che il proxy memorizzi nella cache la risposta**.
|
|
|
|
{% hint style="success" %}
|
|
Impara e pratica Hacking AWS:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
|
Impara e pratica Hacking GCP: <img src="/.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)
|
|
|
|
<details>
|
|
|
|
<summary>Supporta HackTricks</summary>
|
|
|
|
* 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.
|
|
|
|
</details>
|
|
{% endhint %}
|