HTTP Response Smuggling / Desync
Last updated
Last updated
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
La tecnica di questo post è stata presa dal video: https://www.youtube.com/watch?v=suxDcYViwao&t=1343s
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.
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.
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).
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.
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.
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
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:
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.
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:
Poi, una volta che quella blu viene risolta per l'attaccante, la prossima richiesta della vittima verrà introdotta nella coda:
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):
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:
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:
Risposta malevola alla vittima che contiene l'intestazione che indica alla cache di memorizzare la risposta:
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.
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:
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:
Dopo che la prima richiesta è stata risolta e restituita all'attaccante, la richiesta della vittima viene aggiunta nella coda:
La vittima riceverà come risposta la risposta HEAD + il contenuto della risposta della seconda richiesta (contenente parte dei dati riflessi):
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.
Impara e pratica Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Impara e pratica Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
