I sistemi web dove il frontend accetta connessioni via HTTP/2 e li passa al backend tramite HTTP / 1.1 hsono stati esposti a una nuova versione dell'attacco "HTTP Request Smuggling", Consente, inviando richieste client appositamente progettate, di suddividere nel contenuto le richieste di altri utenti elaborate nello stesso flusso tra frontend e backend.
L'attacco può essere utilizzato per iniettare codice JavaScript dannoso in una sessione con un sito legittimo, aggirare i sistemi di restrizione dell'accesso e intercettare i parametri di autenticazione.
L'autore dello studio ha dimostrato la possibilità di attaccare i sistemi Netflix, Verizon, Bitbucket, Netlify CDN e Atlassiane ha ricevuto $ 56.000 in programmi di ricompensa per l'identificazione delle vulnerabilità. Il problema è stato confermato anche nei prodotti F5 Networks.
Il problema influisce parzialmente su mod_proxy sul server Apache http (CVE-2021-33193), correzioni previste nella versione 2.4.49 (gli sviluppatori sono stati informati del problema all'inizio di maggio e hanno avuto 3 mesi per risolverlo). In nginx, la possibilità di specificare contemporaneamente le intestazioni "Content-Length" e "Transfer-Encoding" era bloccata nella versione precedente (1.21.1).
Il principio di funzionamento del nuovo metodo di richieste corrispondenti nel traffico è simile alla vulnerabilità scoperta dallo stesso ricercatore due anni fa, ma è limitato alle interfacce che accettano richieste su HTTP / 1.1.
Il classico attacco "HTTP Request Smuggling" si basava sul fatto che frontend e backend interpretano l'uso delle intestazioni HTTP "Content-Length" in modo diverso (determina la dimensione totale dei dati nella richiesta) e "Transfer-Encoding: chunked" ( consente di trasferire i dati in blocchi) ...
Ad esempio, se l'interfaccia supporta solo "Content-Length" ma ignora "Transfer-Encoding: Fragmented", un utente malintenzionato può inviare una richiesta che contiene le intestazioni "Content-Length" e "Transfer-Encoding: Fragmented", ma la dimensione it La "Lunghezza del contenuto" non corrisponde alla dimensione della stringa suddivisa in blocchi. In questo caso, il frontend elaborerà e reindirizzerà la richiesta in base alla "Lunghezza contenuto" e il backend attenderà il completamento del blocco in base alla "Codifica trasferimento: chunked".
A differenza del protocollo testuale HTTP/1.1, che viene analizzato a livello di riga, HTTP / 2 è un protocollo binario e manipola i blocchi dati di una dimensione predeterminata. Tuttavia, HTTP / 2 usa pseudo-intestazioni che corrispondono alle normali intestazioni HTTP. Quando si interagisce con il backend utilizzando il protocollo HTTP/1.1, il frontend traduce queste pseudo-intestazioni in intestazioni HTTP / 1.1 simili HTTP. Il problema è che il backend prende decisioni sull'analisi della trasmissione in base alle intestazioni HTTP impostate dal frontend, senza conoscere i parametri della richiesta originale.
Anche sotto forma di pseudo-intestazioni, i valori "Lunghezza del contenuto" e "codifica di trasferimento" possono essere trasmessi in streaming, sebbene non siano utilizzati in HTTP / 2, poiché la dimensione di tutti i dati è determinata in un campo separato. Tuttavia, quando si converte una richiesta HTTP/2 in HTTP/1.1, queste intestazioni passano e possono creare confusione nel backend.
Ci sono due principali opzioni di attacco: H2.TE e H2.CL, in cui il backend viene ingannato da una codifica di trasferimento errata o da un valore di lunghezza del contenuto che non corrisponde alla dimensione effettiva del corpo della richiesta ricevuta dal frontend tramite il protocollo HTTP/2.
Come esempio dell'attacco H2.CL, nella pseudo-intestazione è specificata una dimensione errata lunghezza del contenuto quando si invia una richiesta HTTP / 2 su Netflix. Questa richiesta porta all'aggiunta di un'intestazione Lunghezza contenuto HTTP simile quando si accede al backend tramite HTTP / 1.1, ma poiché la dimensione in Content-Length è inferiore a quello effettivo, una parte dei dati in coda viene elaborata come inizio della richiesta successiva.
Gli strumenti di attacco sono già stati aggiunti al Toolkit di Burp e sono disponibili come estensione Turbo Intruder. I proxy Web, i bilanciatori del carico, gli acceleratori Web, i sistemi di distribuzione dei contenuti e altre configurazioni in cui le richieste vengono reindirizzate in uno schema frontend-backend sono soggetti al problema.
fonte: https://portswigger.net