hacktricks/pentesting-web/http-response-smuggling-desync.md

Smuggling / Desincronizzazione delle Risposte HTTP

Impara l'hacking AWS da zero a eroe con htARTE (Esperto Red Team AWS di HackTricks)!

Altri modi per supportare HackTricks:

• Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PIANI DI ABBONAMENTO!
• Ottieni il merchandising ufficiale di PEASS & HackTricks
• Scopri La Famiglia PEASS, la nostra collezione di NFT esclusivi
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @carlospolopm.
• Condividi i tuoi trucchi di hacking inviando PR a HackTricks e HackTricks Cloud repos di github.

La tecnica di questo post è stata presa dal video: 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 cos'è:

La differenza principale 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. Questo viene fatto inviando 2 richieste complete per desincronizzare la coda delle risposte dei proxy anziché inviare 1 richiesta e mezza per abusare del Smuggling delle Richieste HTTP.

Questo perché saremo in grado di desincronizzare la coda delle risposte in modo che la risposta dalla richiesta legittima della vittima venga inviata all'attaccante, o iniettando contenuti controllati dagli attaccanti 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 dei 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 contrabbandata vengono risposte immediatamente, la risposta contrabbandata non verrà inserita nella coda della risposta della vittima ma verrà semplicemente scartata come errore.

Pertanto, è necessario che la richiesta contrabbandata richieda più tempo per essere elaborata all'interno del server di backend. Pertanto, quando la richiesta contrabbandata viene elaborata, la comunicazione con l'attaccante sarà terminata.

Se in questa situazione specifica una vittima ha inviato una richiesta e la richiesta contrabbandata viene risposta prima della richiesta legittima, la risposta contrabbandata 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 potrebbe contenere ad esempio l'intestazione Set-Cookie).

Iniezioni Multiple Nidificate

Un'altra differenza interessante con il comune Smuggling delle Richieste HTTP è che, in un comune attacco di smuggling, l'obiettivo è modificare l'inizio della richiesta delle vittime in modo che esegua un'azione inaspettata. In un attacco di Smuggling delle Risposte HTTP, poiché si stanno inviando 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 abusare di questa tecnica, è necessario che il primo messaggio contrabbandato nel server richieda molto tempo per essere elaborato.

Questa richiesta che richiede 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 abusa del Smuggling delle Richieste HTTP, quindi la richiesta che richiede tempo e quindi 1 o più richieste di payload le cui risposte saranno inviate alle vittime.

Abuso della Desincronizzazione della Coda delle Risposte HTTP

Cattura delle richieste di altri utenti

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 riflesso nella risposta, non è necessario alcuno storage persistente.

Innanzitutto, l'attaccante invia un payload contenente una richiesta POST finale con il parametro riflesso alla fine e un grande Content-Length

Quindi, una volta che la richiesta iniziale (blu) è stata elaborata e mentre quella lenta viene elaborata (gialla) la prossima richiesta che arriva da una vittima verrà aggiunta in coda subito dopo il parametro riflesso:

Quindi, la vittima riceverà la risposta alla richiesta lenta e se nel frattempo l'attaccante ha inviato un'altra richiesta, la risposta dalla richiesta di contenuto riflesso gli verrà inviata.

Desincronizzazione della Risposta

Fino a questo punto, abbiamo imparato come abusare degli attacchi di Smuggling delle Richieste HTTP per controllare la richiesta la cui risposta un client sta per ricevere e come è possibile quindi 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 il Content-Length della richiesta come se fosse una richiesta GET.

Pertanto, se un attaccante inietta una richiesta HEAD, come in queste immagini:

Quindi, una volta che la richiesta blu è stata risposta all'attaccante, la prossima richiesta della vittima verrà introdotta nella coda:

Quindi, 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 aspetterà del contenuto, che in realtà sarà la risposta alla richiesta gialla (anch'essa iniettata dall'attaccante):

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 la seguente per causare XSS nella vittima senza che la pagina sia vulnerabile a XSS:

Avvelenamento della Cache

Abusando dell'attacco di Confusione del Contenuto della risposta precedentemente commentato, se la cache memorizza la risposta alla richiesta effettuata dalla vittima e questa risposta è iniettata causando un XSS, allora la cache è avvelenata.

Richiesta malevola contenente il payload XSS:

Risposta malevola alla vittima che contiene l'header che indica alla cache di memorizzare la risposta:

{% hint style="warning" %} Nota che in questo caso se il "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 anziché iniettare un payload all'interno della cache, l'attaccante memorizzerà le informazioni della vittima all'interno della cache:

Divisione della Risposta

Lo 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:

Dopo che la prima richiesta è risolta e inviata all'attaccante, la richiesta della vittima viene aggiunta nella coda:

La vittima riceverà come risposta il HEAD response + il contenuto della risposta della seconda richiesta (contenente parte dei dati riflessi):

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 del secondo vittima riceverà come risposta qualcosa completamente creato dall'attaccante. Poiché la risposta è completamente creata dall'attaccante, può anche far memorizzare nella cache il la risposta.