Summary of "Cached and Confused: Web Cache Deception in the Wild"

1. UNIVERSITÀ DEGLI STUDI DI TRIESTE
Dipartimento di Ingegneria e Architettura
Tesi di Laurea Triennale in Ingegneria Elettronica ed Informatica
Summary of “Cached and Confused:
Web Cache Deception in the Wild”
Candidato: Relatore:
Marco SANTERAMO Prof. Alberto BARTOLI
__________________________________________
Anno Accademico 2019-2020

2. Indice:
1 Introduzione 3
2 Attacco WCD 3
3 Ambiente di misura 4
4 Elaborazione dei dati 4
5 Configurazione CDN e implicazioni 5
6 Conclusioni 6
7 Bibliografia 7

3. 1 Introduzione:
La condivisione globale dei contenuti nel web e la loro rapida accessibilità è diventata l’obiettivo dei servizi di
condivisione dati. È stato quindi introdotto uno strumento di memorizzazione condivisa di risorse frequentemente
utilizzate detto “Web Cache”.
Questa tecnologia migliora l’accesso alle risorse, mitigando la latenza delle risposte HTTP e riducendo il traffico Internet.
Esse sono presenti localmente nei “Web Browser”, “Web Server” e nei “Proxies” rendendo inadatte al caching le risposte
HTTP contenenti informazioni private.
In particolare, i “Reverse Caching Proxies” sfruttano il caching per fare da intermediario tra il client e il Web Server con
funzioni di protezione aggiuntiva e bilanciamento del carico.
Per rendere le proprie risorse accessibili rapidamente da tutto il mondo, i gestori di siti internet si affidano a reti di Reverse
Caching Proxy dette “Content Delivery Network” [CDN], rendendo le caches una criticità della rete di condivisione.
L’attacco “Web Cache Deception” [WCD] sfrutta le scarse misure di sicurezza e negligenze nell’applicazione dello
standard HTTP; alcune possibili configurazioni delle CDN possono esserne complici. Esse supportano un’elevata
libertà nel caching delle risorse lasciando all’utente l’onere di analizzare e modificare impostazioni, ad esempio
permettendo di scegliere criteri di caching tramite l’analisi dell’URL della risorsa richiesta al posto degli Header Cache
HTTP. Le impostazioni di default per le CDN considerate in questo studio sono espresse nella Tabella 2.
Tabella 1: Criteri di caching per le principali CDN
I Web Server forniscono delle risorse dinamiche, con le quali è possibile interagire interpretando sequenze di caratteri
presenti nell’URL come una specifica istruzione [URL Rewriting].
Tali sequenze sono presenti successivamente al percorso che individua la risorsa dinamica all’interno del Web Server.
Sono di interesse per lo studio le seguenti tecniche:
- Path Parameter: La parte di URL successiva all’ultimo carattere “/” che segue un percorso valido, viene
interpretata come una o più variabili di input al documento dinamico.
- Encoded Newline: Il web server interrompe l’analisi dell’URL dopo l’identificativo di “nuova riga” [simbolo
“/n”, identificativo “%0A”]
- Encoded Semicolon: Analogo a Path Parameter ma considerato “%3B” identificativo del carattere”;”.
- Encoded Pownd: I web server frammentano l’URL una volta individuato “%23”, identificativo di “asterisco”.
- Encoded Question Mark: Analogo a Path Parameter ed Encoded Semicolon, ma è necessario inserire anche il
nome della variabile di input.
Questo processo, non essendo impiegato anche dai proxy intermedi, porta a due interpretazioni dell’URL [Path
Confusion].
Esempio di Path Confusion con tecnica Path Parameter: “http://website/risorsa.php/val1/val2”
Le variabili val1 e val2 vengono interpretate come tali dal Web Server tramite il processo di URL Rewriting ed elise se
non compatibili con i parametri di ingresso di “risorsa.php”.
Il Proxy non impiega tali processi, interpretando “/val1” come parte del percorso “http://website/risorsa.php/val1/” che
punta alla risorsa “val2”.

4. 2 Attacco WCD:
Il Web Cache Deception è una tipologia di attacco informatico presentata da Omer Gil nel 2017.
Essa aggira il normale funzionamento di un proxy, memorizzando le risposte HTTP della vittima nella cache locale e
rendendole accessibili pubblicamente.
L’attaccante individua vittima e sito bersaglio e, adottando la tecnica Path Confusion adeguata, genera un URL ad hoc.
Tale URL contiene un parametro che riferisce ad un file non presente sul Web Server.
Il nome del file è generato appositamente dall’attaccante [URL Mapping] e corrisponde ad un valore ad alta entropia,
ovvero un valore difficile da indovinare casualmente da altri utenti.
Riprendendo l’esempio Path Parameter: http://website/risorsa.php/50835249.css
Procedimento:
1) L’attaccante convince la vittima a collegarsi a tale URL.
2) Si avvia il processo Path Confusion:
La richiesta della vittima viene processata dal Web
Server che in base a uno o più criteri di URL Rewriting
può ignorare parte dell’URL richiesta [es. “Encoded
Newline”] o variabili di input non valide, per praticità o
negligenza. Se questo processo ha successo, il risultato
dell’elaborazione è un URL che potenzialmente punta a
una risorsa contenente informazioni protette.
Il Web Server genera una risposta HTTP e la trasmette
alla vittima. Il proxy intermedio, essendo all’oscuro dei
processi di URLRewriting e URLMapping, individua
una risposta contenente una risorsa statica, inserendola
in cache.
3) L’attaccante visita la medesima URL e il proxy
intermedio fornisce la risposta della vittima.
3 Ambiente di misura:
Considerata la lista “Alexa Top 5K”, si determinano una popolazione di siti e relativi sottodomini
[Seed Pool].
Essendo alla ricerca di informazioni private della vittima, si considera il sottoinsieme del Seed
Pool che richiede autenticazione. Il campione estratto implementa la tecnologia di autenticazione
“Google OAuth”, permettendo la generazione automatica degli account “vittima” e “attaccante”
dove i campi sensibili sono riempiti con appositi marker ad alta entropia.
Per entrambe le identità e per ciascun sito vengono impiegati dei software [Crawlers] che
individuano un set di pagine obiettivo e ne immagazzinano i cookies.
Si individuano criteri di similitudine delle URL, considerandone un campione per ridurre il carico
di lavoro [URL Grouping].
Ad esempio, un insieme di pagine generate da una stessa applicazione web è probabile mostri le
stesse vulnerabilità.
Successivamente si effettua l’attacco, registrando le risposte di attaccante e vittima per ciascuna
pagina.
Si ricerca nella risposta dell’attaccante (es. Javascript, query string, FORM HTML) la presenza di
valori randomici o markers precedentemente inserite nell’account “vittima”.
Seguendo queste fasi sono stati effettuati due studi a distanza di 14 mesi.
Il primo studio ha impiegato solamente la tecnica Path Confusion di tipo Path Parameter.
Il secondo studio ha impiegato tutte le tecniche descritte nell’introduzione, aggiungendo ai siti che
implementano Google OAuth un campione di 45 siti con differenti tipologie di autenticazione.
Il basso numero di elementi appartenenti al campione è causato dall’impossibilità di una creazione
di account automatica.
Figura 1: Schematizzazione del processo di attacco
Figura 2:
Schematizzazione del
processo di analisi

5. 4 Elaborazione dei dati:
Le analisi sono iniziate rispettivamente in data 05/2018 e 07/2019.
Riferendoci al primo studio, dalla Figura 3 notiamo come la distribuzione delle vulnerabilità sia indipendente dalla
popolarità.
Nonostante l’attacco teoricamente impatti ugualmente sia cache autonome che CDN, tramite particolari header nelle
risposte HTTP si è evidenziato come tutti i siti vulnerabili fossero distribuiti dalle CDN. Considerato che il 74% di
Alexa Top 1K si rimette a CDN, sono necessarie nuove ricerche in merito.
Dall’analisi delle risposte HTTP pervenute all’attaccante, sono state
individuate le seguenti informazioni protette:
- Personal Identifiable Informations [PII]: Informazioni identificative
(nome, cognome, …), di salute (calorie bruciate, peso…), finanziarie
(saldo, transazioni…) etc., individuate in coppie ‘keyword =
variabile’ impiegabili per attacchi phishing mirati [Spearphishing].
- Security Tokens: Cross-Site Request Forgery (CSRF Tokens) segreti
conosciuti solo al client e impiegati per prevenire gli attacchi di tipo
CSRF, i quali inducono la vittima a effettuare delle richieste HTTP,
ad esempio tramite tag HTTP (Iframe, img etc.) nascosti,
condividendo inconsapevolmente informazioni o autorizzando operazioni.
- Tokens Application Programming Interface [API] o Identificatori di
Sessione: Segreti che l’attaccante può impiegare per impersonare la vittima e individuati all’interno di
Javascript generati dinamicamente.
Le misurazioni sono state ripetute con attaccanti non autenticati riscontrando risultati analoghi. L’autenticazione risulta
quindi superflua.
Siti totali Siti Vulnerabili
Google
OAuth
Autenticazioni
varie
Vulnerabili Tasso
rispetto al
totale
Vulnerabili con
informazioni
protette
Tasso rispetto
ai siti
vulnerabili
ANALISI
[05/18]
295 0 16 4,7% 14 87,5%
ANALISI
[07/19]
295 45 25 8,5% 23 92%
Tabella 2: Tassi di Vulnerabilità
Dal confronto delle due analisi emerge come, grazie alla varietà di tecniche Path Confusion applicate, nel secondo
studio si sia verificato un incremento delle positività, dove il 44% dei siti risulta vulnerabile solamente a tecniche
differenti da Path Parameter.
Tali fattori hanno portato inoltre ad un elevato incremento delle risposte HTTP di tipo “200 OK”, vettori di una
maggiore densità di informazioni rispetto alle risposte “404 Not Found”, implicando un aumento delle informazioni
protette ottenute dall’attaccante che per alcuni siti è più che triplicato.
Per verificare che il tasso di vulnerabilità sia indipendente dal campione preso in esame si impiega il test del chi quadro
di Pearson’s, dimostrando l’ininfluenza della tipologia di autenticazione.
La mancata adozione di contromisure durante i 14 mesi che separano i due studi genera preoccupazione nei ricercatori.
5 Configurazioni CDN e implicazioni:
Un dato allarmante riguarda l’accessibilità delle cache dei Reverse Proxy in funzione della posizione geografica.
A differenza delle cache lato server, vulnerabili indipendentemente dalla posizione geografica dell’attaccante, i siti che
si affidano alle CDN dovrebbero possedere un’ulteriore protezione.
Infatti, per architettura delle CDN, zone geografiche differenti vengono gestite da reverse proxy differenti.
Figura 3: Grafico delle vulnerabilità

6. Per l’attaccante diventa necessario conoscere l’indirizzo IP del
Caching Proxy obiettivo e produrre delle richieste con header
“Host” che nascondano la sua effettiva posizione geografica.
Per verificare la veridicità di tali ipotesi è stato effettuato il
seguente test empirico durante la seconda analisi:
Considerata una vittima a Boston (USA) e un attaccante a Trento
(ITA) è stata ripetuta la procedura illustrata nel punto 2,
constatando che 6 su 25 attacchi hanno avuto successo.
Nonostante la risposta HTTP della vittima non fosse presente nel
Caching Proxy italiano [PT], essa è stata recuperata dall’attaccante.
Ignorando l’effettiva struttura interna delle CDN considerate, è
impossibile fornire delle risposte esaustive riguardo alle cause dei
successi. Una delle ipotesi è la presenza di una cache centralizzata e
di riferimento per tutti gli Caching Proxy ma non individuabile
direttamente dall’esterno.
Questo avrebbe permesso al proxy italiano di contattare quello
statunitense [PB] recuperando la risposta HTTP fornita dal Web
Server [WS] alla vittima.
6 Conclusioni:
In conclusione, le vulnerabilità non risiedono nella configurazione errata del singolo Web Server o Caching Proxy bensì
nella loro interazione fornendo all’attaccante un’ampia scelta di tecniche Path Confusion efficaci.
Per evitare questa vulnerabilità è necessario configurare correttamente le caches, andando oltre le configurazioni
standard delle CDN e considerando una visione olistica del sistema.
Servono quindi ulteriori ricerche a causa delle limitazioni sulla popolazione presa in esame e delle tecniche utilizzate,
evidenziando come i risultati di questi studi illustrino solamente le basi delle potenzialità del WCD.
Figura 4: Schematizzazione dell’attacco da differenti
posizioni geografiche

7. 7 Bibliografia:
Seyed Ali Mirheidari, Kaan Onarlioglu, KU Leuven; “Cached and Confused:
Web Cache Deception in the Wild”, in the Proceedings of the
29th “USENIX Security Symposium”; August 2020.