i dettagli di un nuovo attacco ai siti che utilizzano un modello front-end-backend, come quelli che operano attraverso reti di distribuzione dei contenuti, bilanciatori o proxy. L'attacco consente di infiltrarsi nel contenuto di altre richieste tramite l'invio di richieste specifiche, interagendo nel flusso tra front-end e back-end. 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 del programma di segnalazione delle vulnerabilità non corrette. L'attacco è applicabile anche ai siti che utilizzano la rete di distribuzione dei contenuti Akamai.
La questione principale è che i front-end e i back-end spesso forniscono livelli diversi di supporto per il protocollo HTTP, pur incapsulando le richieste di diversi utenti in un'unica canalizzazione. Viene stabilita una connessione TCP persistente tra il front-end che riceve le richieste e il back-end che le elabora, attraverso la quale vengono inoltrate le richieste degli utenti, trasmesse in sequenza tramite il protocollo HTTP. Per separare le richieste, possono essere utilizzati gli header "Content-Length" (che definisce la dimensione totale dei dati nella richiesta) e "" (che consente di inviare i dati in parti, specificando blocchi di diverse dimensioni nel formato "{dimensione}\r\n{blocco}\r\n{dimensione}\r\n{blocco}\r\n0").
Il problema si verifica quando il frontend supporta solo "Content-Length" ma ignora "Transfer-Encoding: chunked" (ad esempio, così operava il CDN Akamai) o viceversa. Se "Transfer-Encoding: chunked" è supportato da entrambi i lati, per l'attacco possono essere sfruttate le peculiarità delle implementazioni dei parser degli header HTTP (ad esempio, quando il frontend ignora righe del tipo "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 backend le elabora con successo).
In questo caso, l'attaccante può inviare una richiesta che specifica simultaneamente le intestazioni "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 front-end elabora e reindirizza la richiesta in base a "Content-Length", mentre il back-end si aspetta la conclusione del blocco basata su "Transfer-Encoding: chunked", la fine dei dati basata su "Transfer-Encoding: chunked" sarà determinata prima e il resto della richiesta dell'attaccante verrà collocato all'inizio della richiesta successiva, ossia l'attaccante avrà la possibilità di allegare dati arbitrari all'inizio della richiesta altrui inviata in seguito.
Per identificare il problema nella combinazione front-end-back-end, tramite il front-end è possibile inviare una richiesta del tipo:
POST /about HTTP/1.1
Host: example.com
Transfer-Encoding: chunked
Content-Length: 4
1
Z
Q
Il problema è presente se il back-end non elabora immediatamente la richiesta e attende l'arrivo del blocco finale nullo chiudente dei dati chunked. Per un controllo più completo uno strumento speciale che testa anche i possibili metodi per nascondere l'intestazione "Transfer-Encoding: chunked" dal front-end.
La riuscita di un attacco reale dipende dalle vulnerabilità del sito attaccato. Ad esempio, durante un attacco all'app web Trello, è possibile manipolare l'inizio della richiesta (inserendo dati di 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, comprese le Cookie di autenticazione. Per un attacco a saas-app.com, è stato possibile inserire codice JavaScript nella risposta, attraverso l'inserimento in uno dei parametri della richiesta. Nell'attacco a redhat.com, è stato utilizzato un gestore interno per reindirizzare al sito dell'attaccante (si è utilizzata 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 può essere utilizzato anche per organizzare l'avvelenamento dei contenuti nei sistemi di caching e per estrarre dati sensibili memorizzati nella cache. Il culmine dell'applicazione del metodo è stato l'organizzazione di un attacco su PayPal, che ha permesso 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 la quale non è stata applicata la CSP (Content Security Policy)).
È interessante notare che nel 2005 c'era una tecnica simile per la sostituzione delle richieste, che consentiva di cambiare i dati nei proxy di caching (Tomcat, squid, mod_proxy) o di eludere i firewall specificando più richieste «GET» o «POST» all'interno di una singola sessione HTTP.
Fonte: opennet.ru
