Attacco ai sistemi front-end-backend, che consente di infiltrarsi in richieste esterne

Rivelati Dettagli di un nuovo attacco a siti che utilizzano il modello front-end-back-end, ad esempio, quelli che operano attraverso reti di distribuzione dei contenuti, bilanciatori di carico o proxy. L'attacco consente di infiltrarsi nel contenuto di altre richieste, elaborando nello stesso flusso tra front-end e back-end, inviando richieste specifiche. Il metodo proposto è stato applicato con successo per organizzare un attacco che permette di intercettare i parametri di autenticazione degli utenti del servizio PayPal, che ha pagato ai ricercatori circa 40.000 dollari nell'ambito di un programma di reporting per vulnerabilità non corrette. L'attacco è applicabile anche a siti che utilizzano la rete di distribuzione dei contenuti Akamai.

La questione principale è che front-end e back-end spesso forniscono un diverso livello di supporto per il protocollo HTTP, ma incapsulano le richieste di diversi utenti in un unico canale. Per la comunicazione tra il front-end che riceve le richieste e il back-end che elabora le richieste, viene stabilita una connessione TCP a lungo termine, attraverso la quale vengono trasmesse le richieste degli utenti, trasmesse in sequenza, separate tramite il protocollo HTTP. Per separare le richieste possono essere utilizzati gli header 'Content-Length' (che determina la dimensione totale dei dati nella richiesta) e 'Transfer-Encoding: chunked’ (consente di inviare dati in parti, specificando blocchi di dimensioni diverse nel formato '{dimensione}\r\n{blocco}\r\n{dimensione}\r\n{blocco}\r\n0').

Il problema si presenta se il front-end supporta solo 'Content-Length' ma ignora 'Transfer-Encoding: chunked' (ad esempio, questo è stato il caso del CDN Akamai) o viceversa. Nel caso in cui 'Transfer-Encoding: chunked' sia supportato su entrambi i lati, possono essere utilizzate le peculiarità dell'implementazione dei parser di intestazioni HTTP per l'attacco (ad esempio, quando il front-end ignora righe come 'Transfer-Encoding: xchunked', 'Transfer-Encoding: chunked', 'Transfer-Encoding:[tab]chunked', 'X: X[\n]Transfer-Encoding: chunked', 'Transfer-Encoding[\n]: chunked' o 'Transfer-Encoding : chunked', mentre il back-end le elabora con successo).

In questo caso, l'attaccante può inviare una richiesta in cui sono contemporaneamente specificati gli header «Content-Length» e «Transfer-Encoding: chunked», ma la dimensione in «Content-Length» non corrisponde alla dimensione della catena chunked, che è inferiore al valore effettivo. Se il frontend elabora e reindirizza la richiesta in base a «Content-Length», mentre il backend si aspetta la conclusione del blocco basata su «Transfer-Encoding: chunked», la fine dei dati sulla base di «Transfer-Encoding: chunked» sarà determinata prima e il resto della richiesta dell'attaccante si troverà all'inizio della richiesta successiva, ovvero, l'attaccante avrà la possibilità di allegare dati arbitrari all'inizio di una richiesta straniera inviata subito dopo.

Per determinare il problema nella combinazione frontend-backend utilizzata, si può inviare una richiesta dal frontend del tipo:

POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4

1
Z
Q

Il problema è presente se il backend non elabora immediatamente la richiesta e attende l'arrivo del blocco finale nullo dei dati chunked. Per una verifica più completa è stata preparata è utile un'apposita utilità che testa anch'essa possibili metodi per nascondere l'header «Transfer-Encoding: chunked» dal frontend.

La realizzazione di un attacco reale dipende dalle capacità del sito attaccato; ad esempio, nell'attacco a un'applicazione web come Trello, è possibile sostituire l'inizio della richiesta (inserire dati del tipo «PUT /1/members/1234… x=x&csrf=1234&username=testzzz&bio=cake») e inviare un messaggio che include la richiesta originale di un altro utente insieme ai cookie di autenticazione specificati. Per un attacco a saas-app.com, si è rivelato possibile inserire codice JavaScript nella risposta, attraverso la sua inclusione in uno dei parametri della richiesta. Per l'attacco a redhat.com, è stato utilizzato un gestore interno per reindirizzare al sito dell'attaccante (è stata inserita una richiesta del tipo «POST /search?dest=.. /assets/idx?redir=//redhat.com@evil.net/ HTTP/1.1»).

L'applicazione del metodo per le reti di distribuzione dei contenuti consentiva di sostituire facilmente il sito richiesto tramite la sostituzione dell'intestazione "Host:". L'attacco era applicabile anche per organizzare l'avvelenamento dei contenuti nei sistemi di caching e l'estrazione di dati riservati memorizzati nella cache. Il culmine dell'applicazione del metodo è stata l'organizzazione di un attacco a PayPal, che permetteva di intercettare le password inviate dagli utenti durante l'autenticazione (è stata effettuata una modifica della richiesta iframe per eseguire JavaScript nel contesto della pagina paypal.com/us/gifts, per cui non era stato applicato il CSP (Content Security Policy)).

È interessante notare che nel 2005 c'era stata offerta una tecnica simile di sostituzione delle richieste, che consentiva di sostituire i dati nei proxy di caching (Tomcat, squid, mod_proxy) o di aggirare le restrizioni dei firewall specificando più richieste "GET" o "POST" all'interno di un'unica sessione HTTP.

Fonte: opennet.ru