Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-16 09:48:14 +00:00

Translator workflow 99e7865a3e Translated to Italian

2024-02-10 13:03:23 +00:00

11 KiB

Raw Blame History

HTTP Response Smuggling / Desync

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

Altri modi per supportare HackTricks:

Se vuoi vedere la tua azienda pubblicizzata in HackTricks o scaricare HackTricks in PDF Controlla i PACCHETTI DI ABBONAMENTO!
Ottieni il merchandising ufficiale di PEASS & HackTricks
Scopri The PEASS Family, 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 github repos.

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 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.

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).

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

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

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:

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:

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:

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:

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

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:

Dopo che la prima richiesta viene risolta e inviata all'attaccante, la richiesta della vittima viene aggiunta alla 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 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.