Un attacco ai sistemi front-end-back-end che ci consente di incunearci nelle richieste di terze parti

divulgato dettagli di un nuovo attacco ai siti che utilizzano un modello front-end-back-end, come quelli che attraversano reti di distribuzione di contenuti, bilanciatori di carico o proxy. L'attacco permette, attraverso l'invio di determinate richieste, di incunearsi nel contenuto di altre richieste elaborate nello stesso thread tra frontend e backend. Il metodo proposto è stato utilizzato con successo per organizzare un attacco che ha permesso di intercettare i parametri di autenticazione degli utenti del servizio PayPal, che ha pagato ai ricercatori circa 40mila dollari come parte di un programma per informare sulla presenza di vulnerabilità non risolte. L'attacco è applicabile anche ai siti che utilizzano la rete di distribuzione dei contenuti di Akamai.

Il nocciolo del problema è che frontend e backend spesso forniscono diversi livelli di supporto per il protocollo HTTP, ma allo stesso tempo incapsulano le richieste di utenti diversi in un canale comune. Per connettere il frontend che riceve le richieste e il backend che elabora le richieste, viene stabilita una connessione TCP di lunga durata, attraverso la quale vengono trasmesse le richieste degli utenti, trasmesse lungo la catena una dopo l'altra, separate mediante il protocollo HTTP. Per separare le richieste, le intestazioni "Content-Length" (determina la dimensione totale dei dati nella richiesta) e "Transfer-Encoding: chunked"(consente di trasferire i dati in parti, specificando blocchi di dimensioni diverse nel formato "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Il problema sorge se il frontend supporta solo “Content-Length” ma ignora “Transfer-Encoding: Chunked” (ad esempio, Akamai CDN lo ha fatto) o viceversa. Se Transfer-Encoding: Chunked è supportato su entrambi i lati, le funzionalità di implementazione dei parser di intestazione HTTP possono essere utilizzate per un attacco (ad esempio, quando il front-end ignora righe come "Transfer-Encoding: xchunked", "Transfer-Encoding: Chunked" ”, “Codifica di trasferimento” :[tab]chunked", "X: X[\n]Codifica di trasferimento: Chunked", "Codifica di trasferimento[\n]: Chunked" o "Codifica di trasferimento: Chunked" e il backend li elabora con successo).

In questo caso, un utente malintenzionato può inviare una richiesta che contiene entrambe le intestazioni "Content-Length" e "Transfer-Encoding: Chunked", ma la dimensione in "Content-Length" non corrisponde alla dimensione della catena in blocchi, che è inferiore al valore reale. Se il frontend elabora e inoltra la richiesta in base a "Content-Length" e il backend attende il completamento del blocco in base a "Transfer-Encoding: Chunked", la fine dei dati in base a "Transfer-Encoding: Chunked" verrà essere determinato in precedenza e la coda rimanente della richiesta dell'aggressore si troverà all'inizio della richiesta successiva, ad es. l'aggressore potrà allegare dati arbitrari all'inizio della richiesta di qualcun altro trasmessa successivamente.

Per determinare il problema nella combinazione frontend-backend utilizzata, puoi inviare una richiesta come questa tramite il frontend:

POST /su HTTP/1.1
Host: esempio.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 di dati in blocchi con limite zero. Per un controllo più completo preparato un'utilità speciale che testa anche i possibili metodi per nascondere l'intestazione "Transfer-Encoding: Chunked" dal frontend.

L'esecuzione di un vero attacco dipende dalle capacità del sito attaccato, ad esempio, quando si attacca l'applicazione web Trello, è possibile sostituire l'inizio della richiesta (sostituire dati come “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) e inviare un messaggio contenente la richiesta originaria di un utente terzo e il Cookie di autenticazione in esso specificato. In caso di attacco a saas-app.com è stato possibile sostituire il codice JavaScript nella risposta sostituendolo in uno dei parametri della richiesta. Per l’attacco a redhat.com è stato utilizzato un gestore interno per reindirizzare al sito web dell’aggressore (una richiesta nel formato “POST /search?dest=../assets/idx?redir=//[email protected]/HTTP/1.1").

Utilizzando il metodo per le reti di distribuzione dei contenuti è stato possibile sostituire semplicemente il sito richiesto sostituendo l'intestazione "Host:". L'attacco può essere utilizzato anche per avvelenare il contenuto dei sistemi di caching dei contenuti ed estrarre dati riservati memorizzati nella cache. L'apice del metodo è stata l'organizzazione di un attacco a PayPal, che ha permesso di intercettare le password inviate dagli utenti durante l'autenticazione (la richiesta iframe è stata modificata per eseguire JavaScript nel contesto della pagina paypal.com/us/gifts, per quale CSP (Content Security Policy) non è stata applicata).

È interessante notare che nel 2005 c'era proposto una tecnica di spoofing delle richieste essenzialmente simile che consente di eseguire lo spoofing dei dati nei proxy di memorizzazione nella cache (Tomcat, squid, mod_proxy) o di aggirare il blocco del firewall specificando diverse richieste "GET" o "POST" all'interno di una sessione HTTP.

Fonte: opennet.ru