neex/http2smuglRileva e sfrutta le vulnerabilità di smuggling delle richieste HTTP tramite la conversione da HTTP/2 a HTTP/1.1, utilizzando tecniche automatiche di smuggling di header per identificare discrepanze di parsing nel backend.
Questo strumento aiuta a rilevare e sfruttare lo smuggling di richieste HTTP nei casi in cui può essere ottenuto tramite la conversione HTTP/2 -> HTTP/1.1 da parte del server frontend.
Lo schema è il seguente:
L'attaccante vuole trovare una richiesta tale che venga vista come due richieste separate dal server backend.
Se la connessione HTTP/1.1 tra frontend e backend utilizza keep-alive, il frontend potrebbe inviare richieste di altri utenti sulla stessa connessione. Se riusciamo ad "avvelenare" la connessione con una richiesta parziale che segue una legittima, possiamo recuperare la richiesta di un altro utente.
Altri possibili scenari includono il bypass della protezione del server frontend e riscritture, avvelenamento della cache o inganno della cache.
Per maggiori informazioni sull'HTTP Request Smuggling, fare riferimento a Portswigger Web Security Academy.
In HTTP/2, i nomi e i valori di tutte le intestazioni HTTP sono binari. Ciò significa che tecnicamente possono contenere spazi aggiuntivi o addirittura nuove righe.
RFC7540#10.3 afferma che le implementazioni che traducono richieste HTTP/2 in HTTP/1 devono tenere conto delle limitazioni sul set di caratteri che derivano da tale conversione; la maggior parte delle implementazioni le rifiuta effettivamente. Nonostante ciò, speriamo di trovarne alcune che consentano tali intestazioni. Esse corromperanno la richiesta HTTP/1.1 convertita verso il backend.
Un altro punto è che alcune correzioni recenti relative all'HTTP Request Smuggling potrebbero essere implementate solo per i parser HTTP/1.1.
In generale, speriamo che esistano implementazioni di HTTP/2 che non siano molto a conoscenza delle recenti ricerche sull'HTTP Request Smuggling in HTTP/1.1 e non includano le relative mitigazioni.
Sorprendentemente, sì!
Ho trovato la possibilità di contrabbandare un'intestazione con un carattere spazio attraverso Cloudflare, aprendo così una porta per lo smuggling Cloudflare<->client (nel caso in cui il software di un client Cloudflare accetti e tronchi i nomi delle intestazioni). Ecco il post del blog.
C'è anche un altro report di bug bounty non ancora pubblico. Sfrutta il fatto che il software personalizzato non filtra le nuove righe nelle intestazioni HTTP/2, e lo smuggling avviene al 100% (posso vedere le richieste di altri utenti).
Tuttavia, capisco che questo tipo di vulnerabilità deve essere frustrantemente raro: a differenza di HTTP/1.1, non ci sono molte implementazioni di HTTP/2, e la maggior parte di esse è realizzata con la sicurezza in mente, quindi rifiuta intestazioni sospette o non valide.
Lo strumento ha un sottocomando che tenta di rilevare automaticamente se un target è vulnerabile all'attacco di HTTP Request Smuggling. L'algoritmo alla base di questa funzione è descritto in questa sezione.
Per eseguire un attacco di HTTP Request Smuggling, abbiamo effettivamente bisogno di "contrabbandare" prima una singola intestazione (sia Content-Length che Transfer-Encoding). Significa che dobbiamo inviare un'intestazione che a) controlla dove finisce il corpo della richiesta e b) non viene elaborata dal frontend ma viene elaborata dal backend.
Ciò si ottiene solitamente modificando un'intestazione in qualche modo: aggiungendo spazi o tabulazioni alla fine del nome, sostituendo il valore con uno semi-equivalente, ecc.
L'idea di base dell'algoritmo di rilevamento delle vulnerabilità è rilevare se il server elabora effettivamente un'intestazione contrabbandata come se fosse Content-Length o Transfer-Encoding. Lo facciamo inviando più richieste: alcune con valori validi e altre con valori non validi per l'intestazione. Quindi cerchiamo di rilevare se esiste un modo per distinguere le risposte di questi due gruppi.
Ecco perché l'output dello strumento non contiene le parole "vulnerabile/invulnerabile": dice solo se può distinguere le risposte arrivate sulle richieste di questi due gruppi.
Lo strumento considera due insiemi di risposte HTTP distinguibili se è soddisfatta almeno una delle seguenti due condizioni:
I timeout sono trattati come un valore unico di codice di stato non uguale a nessun altro; quindi lo strumento supera lo schema classico di "rilevamento tramite temporizzazione".
Consideriamo un esempio. Supponiamo di provare a contrabbandare l'intestazione transfer-encoding sostituendo il trattino con un underscore.
Se appare che il server risponde con stato 400 ogni volta che inviamo transfer_encoding:zalupa e si blocca quando è transfer_encoding:chunked, possiamo dire che il server probabilmente elabora l'intestazione come il valore per transfer encoding. Teoricamente, potrebbe essere il server frontend o backend.
Il primo caso non è interessante poiché potremmo comunque inviare la versione non contrabbandata dell'intestazione, e il secondo è ciò che stiamo cercando. Poiché tutto avviene su HTTP/2, il primo caso è evitabile la maggior parte delle volte: il server HTTP/2 determina la fine del corpo della richiesta in un altro modo non correlato alle intestazioni della richiesta e non si aspetta mai che il corpo sia nel formato chunked HTTP/1.1 (quello con lunghezze esadecimali dei blocchi).
Le variazioni concrete delle tecniche di rilevamento sono:
Inviamo una versione contrabbandata di Transfer-Encoding: chunked (es. transfer_encoding:chunked) e corpi diversi: valido è 0\r\n\r\n e non valido è 999\r\n.
Se le risposte sono differenti, possiamo essere certi che il server backend riceve ed elabora l'intestazione contrabbandata. Non c'è motivo per il frontend di farlo: HTTP/2 non utilizza il formato chunked che abbiamo inviato, quindi sarebbe non valido.
Ci aspettiamo che il backend si blocchi (cioè la richiesta vada in timeout) per le richieste non valide mentre aspetta l'arrivo di più dati.
Questa è la variante di rilevamento più affidabile: se il server si blocca durante la lettura del corpo, probabilmente qualcosa è andato storto poiché non c'è uso per la codifica di trasferimento HTTP/1.1 in una richiesta HTTP/2.
Inviamo di nuovo una versione contrabbandata di Transfer-Encoding e corpi diversi: 0\r\n\r\n come corpo valido e X\r\n\r\n come corpo non valido.
Il caso è lo stesso di sopra, ma invece di leggere il corpo, ci aspettiamo che il backend lo convalidi almeno.
Inviamo una versione contrabbandata dell'intestazione Content-Length con valori 1 e -1.
Entrambi i valori sono non validi dal punto di vista del frontend: esiste un altro meccanismo per determinare la lunghezza del corpo in HTTP/2, e in entrambi i casi non viene effettivamente inviato alcun corpo della richiesta. Se le risposte sono differenti, supponiamo che sia il server backend ad aver analizzato le intestazioni.
Questo metodo è il meno affidabile: il frontend potrebbe emettere errori diversi quando Content-Length ha un valore non valido e quando non corrisponde alla lunghezza effettiva.
Inviando più coppie di richieste valide/non valide, possiamo ridurre la probabilità di falsi positivi casuali. D'altro canto, possiamo fermarci presto se vediamo che non c'è modo di separare le risposte alle richieste "valide" da quelle alle richieste "non valide".
