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".
Lo strumento cerca di impiegare molteplici tecniche di smuggling modificando un'intestazione in vari modi. Nessuna di esse è nuova e allo stesso tempo non ovvia.
Per contrabbandare un'intestazione, aggiungiamo uno spazio ad essa. È il metodo più comune e classico. Speriamo che l'intestazione non venga elaborata dal frontend ma venga inviata così com'è al backend, che rimuove lo spazio.
Lo strumento prova una varietà di caratteri come spazi: include , \t, \v, \x00 e quelli Unicode.
Per contrabbandare un'intestazione, sostituiamo il trattino (-) con un underscore (_). Se il backend è ispirato a CGI in qualche modo, potrebbe convertire intestazioni come Header-Name nella forma HEADER_NAME; quindi il trattino diventerà comunque underscore. Mentre determina come analizzare il corpo, tale backend presumibilmente richiede il valore di CONTENT_LENGTH / TRANSFER_ENCODING dal suo dizionario di intestazioni, e sarà lì.
Questa è specifica di HTTP/2. Poiché HTTP/2 è un protocollo binario, possiamo provare a inviare nuove righe nel nome o nel valore dell'intestazione. Lo standard lo proibisce, ma speriamo di trovare un'implementazione che lo accetti ancora.
Durante la conversione HTTP/2 -> HTTP/1.1, l'intestazione si divide in due diverse intestazioni, il che significa che la richiesta apparirà diversa per il backend.
Per contrabbandare un'intestazione, mettiamo il suo nome e valore dopo una nuova riga: un'intestazione con nome "Transfer-Encoding" e valore "chunked" diventa una con nome "fake" con valore "fake\r\ntransfer-encoding: chunked".
Supponiamo che il backend utilizzi un linguaggio di alto livello e non esegua una sufficiente validazione delle intestazioni. In tal caso, potrebbe convertire i nomi in maiuscolo prima di fare qualsiasi altra cosa e farlo utilizzando funzioni sensibili a Unicode. Fortunatamente, TRANSFER-ENCODING contiene la lettera S, che è ſ (\u017f) in maiuscolo.
Allo stesso modo, possiamo cercare un backend che converta il valore di Transfer-Encoding in minuscolo: inviamo chunKed invece di chunked con \u212a al posto di K.
Ovviamente, è richiesto che il frontend trasmetta nomi/valori di intestazioni UTF-8 al backend.
Per installare lo strumento, esegui go install github.com/neex/http2smugl@latest.
Lo strumento contiene due sottocomandi: request e detect. Il primo è solo per creare richieste HTTP/2: la maggior parte degli strumenti client non accetta intestazioni non valide, quindi è comodo averne uno che invia l'input dell'utente al server così com'è.
L'altro è detect. Prova varie tecniche di HTTP request smuggling per rilevare se il target è vulnerabile. L'algoritmo di rilevamento è complicato; apprezzo se lo leggi e mi invii i tuoi commenti. È descritto di seguito nella sezione corrispondente.
http2smugl requestUsa questo sottocomando per inviare una richiesta http2 (probabilmente leggermente malformata). Il primo parametro è l'URL, gli altri sono solo intestazioni nel formato nome:valore (nota che non c'è spazio dopo i due punti). È supportato l'escape con barra rovesciata: puoi usare i codici di escape \r, \n e \xXX. Ad esempio, per inviare un nome di intestazione che contiene due punti, usa \x3a (es. nome\x3acon\x3aduipunti:valore).
http2smugl detectQuesto sottocomando tenta di rilevare l'HTTP request smuggling utilizzando varie tecniche. Per usarlo, esegui semplicemente http2smugl detect [URL HTTPS].
Il comando produrrà output solo se può rilevare che il server analizza un'intestazione contrabbandata. Per capire cosa significa, leggi la sezione corrispondente.
È stato implementato un supporto sperimentale per HTTP/3 (quic). Tuttavia, sconsiglio di usarlo poiché non ho trovato un singolo bug relativo a HTTP/3.
Per usare HTTP/3 con il sottocomando request, fornisci il proto https+h3:// nell'URL invece di https. Lo stesso è supportato nel comando detect.
C'è anche un flag --try-http3 per il sottocomando request, che modifica il comportamento nel caso in cui il protocollo non sia specificato nell'URL (solo hostname). Se il flag è presente, il comando proverà il proto https+h3 per tali voci nella riga di comando o nel file dei target (oltre a HTTP/2). Ad esempio, http2smugl detect --try-http3 www.example.com proverà sia HTTP/3 che HTTP/2, ma http2smugl detect --try-http3 https://www.example.com/ proverà ancora solo HTTP/2.
In questa sezione descrivo alcuni casi in cui lo strumento dice che le risposte sono "distinguibili", ma non potrebbe esistere alcuna vulnerabilità.
L'Elastic Load Balancer di Amazon implementa molteplici mitigazioni contro l'HTTP Request Smuggling. Sebbene non tutte respingano la richiesta per impostazione predefinita, ELB non riutilizzerà una connessione dopo aver inviato una richiesta con intestazioni "sospette". Quindi un attacco effettivo non è possibile.
Per rilevare se hai a che fare con ELB, puoi usare l'intestazione di risposta Server. Se è filtrata, puoi inviare una richiesta con l'intestazione content__length (nota due underscore) e valore -1: se è 400, probabilmente è ELB o un altro WAF (vedi sotto).
Apache Traffic Server è usato principalmente da Yahoo. Elabora HTTP/2 in modo insolito: lo converte in HTTP/1.1 in memoria e poi ri-analizza la richiesta risultante. Quindi, sebbene un'intestazione tecnicamente possa essere "contrabbandata", non c'è modo che risulti in una vulnerabilità: potresti inviare gli stessi byte a una connessione HTTP/1.1.
Il modo più semplice per rilevare se hai a che fare con ATS (oltre all'intestazione Server) è inviare una richiesta TRACE. Se nell'intestazione è presente Max-Forwards: 0, ATS restituirà una risposta alle richieste TRACE per impostazione predefinita senza inoltrarle al backend.
Sembra che Microsoft IIS supporti la decodifica della codifica chunked all'interno dei corpi HTTP/2. È un comportamento strano; tuttavia, è innocuo dal punto di vista della sicurezza.
Per rilevare se hai a che fare con IIS, puoi inviare una richiesta con un'intestazione "transfer-encoding:chunked" e un corpo chunked errato. Se vedi Microsoft-HTTPAPI o qualcosa di simile nell'intestazione Server, allora è quello.
I WAF cercano di rilevare intestazioni sospette - è il loro lavoro. A volte ciò fa sì che lo strumento dica "distinguibile": un WAF potrebbe bloccare qualcosa come content_length:-1 e consentire content_length:1 solo perché i suoi filtri arrivano a queste decisioni.
Se vedi un WAF nell'intestazione Server, probabilmente è un falso positivo.
Se hai idee su questo argomento, contattami su Twitter tramite @emil_lerner o su Telegram tramite @neexemil - o apri un issue qui su GitHub.