La trasmissione di informazioni sul web è resa possibile da una moltitudine di funzioni e protocolli. A vari livelli, ci si assicura che le informazioni arrivino, che lo facciano correttamente e, soprattutto, all’indirizzo giusto.
Tra questi, ve ne sono alcuni, come l’HTTP, che determinano un ciclo di richiesta-risposta tra due host. La struttura delle comunicazioni, però, non è impenetrabile. I cybercriminali trovano spesso il modo di sfruttare a proprio vantaggio ogni aspetto dell’ambiente in cui operano. Ad esempio, negli attacchi Web Cache Poisoning è possibile indurre la cache di un server a distribuire del codice malevolo affinché tutti gli utenti che visitano una determinata pagina ne siano colpiti.
In questo articolo gli esperti di Cyberment affrontano questa tipologia di attacco informatico e divulgano una serie di consigli utili a difendersi dal Web Cache Poisoning.
- Panoramica introduttiva sul Web Cache Poisoning
Il Cache Poisoning è un attacco lato server in cui l’hacker sfrutta il web server e la sua cache per distribuire contenuti malevoli agli utenti attraverso richieste HTTP.
L’obiettivo dell’hacker è quello di forzare il server ad inviare una risposta compromessa, nella quale sia contenuto un payload malevolo.
Se riesce nell’intento, l’attaccante fa sì che questo tipo di risposta venga salvata nella cache del server, in modo tale che possa distribuirsi a tutti gli utenti che la sollecitano.
In questo modo, si apre un ventaglio di possibilità di attacco, arrivando persino alla manipolazione del servizio attaccato. I rischi, però, sono per di più per l’utente, che può arrivare a subire attacchi XSS (cross-site scripting) e successivo code injection.
Per comprendere meglio il fenomeno, occorre capire per quale motivo la web cache è un obiettivo così ambito.
- Web Cache: perché è un obiettivo degli hacker
Quando si visita un sito web, si sta inviando una richiesta dalla propria macchina ad un’altra, notoriamente un server di web hosting.
Se si superano correttamente tutti i check relativi al protocollo di comunicazione, la macchina che ha ricevuto la richiesta risponde presentando il documento corretto.
Nel caso di servizi reali, però, il traffico non si limita ad una sola interazione.
Nella realtà di tutti i giorni, infatti, per singole pagine vengono fatte molteplici richieste in tempi molto brevi.
Di conseguenza, il server deve fornire a più utenti lo stesso documento, recuperandolo dalla memoria.
Ora, le prestazioni e l’esperienza utente devono essere ottimali, dunque i tempi di risposta devono essere i più brevi possibile.
A tal proposito, vengono spesso utilizzati dei particolari server, detti proxy, che si interpongono tra il client e il server vero.
I proxy fungono da cache, il che vuol dire che memorizzano i documenti che vengono richiesti più spesso e li girano immediatamente al richiedente, tagliando di netto i tempi di attesa.
Dunque, più un’informazione viene richiesta, più è probabile che passerà nella cache e sarà dunque più rapidamente fruibile.
Sintetizzando, dunque, il termine cache significa letteralmente “deposito temporaneo di dati” frequentemente utilizzati o richiesti da un processore o da altri dispositivi di calcolo.
Pertanto, terreno fertile del web poisoning sono quelle particolari richieste le cui risposte sono memorizzate in cache.
Il riconoscimento avviene grazie alle cache key.
Ogni richiesta, infatti, ha dei parametri oltre al contenuto; tra di essi ce ne sono alcuni che vengono denominati cache key, poiché le cache possono usarli per identificare il tipo di risposta correlato ad una particolare richiesta.
Di contro, i parametri che non fanno parte della cache key sono detti “unkeyed”.
Dunque, quando arriva una richiesta, la cache analizza i parametri della cache key e, in caso di corrispondenza, inoltra una risposta.
Il comportamento è lo stesso per tutte le richieste inoltrate dai vari utenti.
I parametri che non fanno parte della cache key vengono di solito ignorati, poiché non servono a identificare la risposta.
Quest’ultimo comportamento è quello che verrà sfruttato dagli attaccanti.
- La dinamica di avvelenamento della cache
Per capire come potersi difendere da questa tipologia di attacchi, è importante osservarne il processo operativo.
Da qui potranno risultare più chiare le misure di prevenzione.
Come già accennato, dunque, i parametri unkeyed sono quelli utili all’attaccante.
L’hacker cerca questi parametri e, una volta trovati, passa alla fase operativa. L’attacco consta, dunque, di tre fasi:
- Identificazione dei parametri unkeyed (fase preliminare)
La riuscita dell’attacco dipende dalla possibilità di trovare i parametri che non costituiscono la cache key.
Questo è motivato dal fatto che, per come funziona la web cache, essi vengono ignorati durante la fase di identificazione della richiesta. Costituiscono, perciò, un cavallo di Troia perfetto per immettere del payload malevolo nelle risposte date dalla cache.
È dunque cruciale per l’attaccante scovare un insieme di intestazioni “silenziose” supportate dal servizio vittima.
Fortunatamente queste operazioni preliminari richiedono un cospicuo lavoro manuale e necessitano di tempo.
L’attaccante può evincere la struttura del servizio vittima inviando degli input specifici ed analizzando la risposta ricevuta.
Tuttavia, l’analisi è spesso più complicata di così e richiede degli strumenti software specifici per scandagliare approfonditamente le risposte.
Nonostante ciò, l’attaccante è tenuto ad operare in prima persona: non è un processo interamente automatizzabile e, dunque, richiede una quantità di tempo relativamente grande.
Una volta completata la fase preliminare di analisi, l’hacker procede a sfruttare le conoscenze ottenute.
- Sollecitare una risposta malevola dal server (fase operativa)
A questo punto, è fondamentale per l’hacker trovare vulnerabilità su cui fare leva.
Sommando un punto debole nel servizio ad una esaustiva comprensione della modalità di gestione delle richieste, è possibile sollecitare delle risposte malevole utilizzabili a proprio vantaggio.
Ad esempio, se il valore di un parametro della richiesta è utilizzato attivamente per generare del contenuto sulla pagina, un attaccante potrebbe operare una Javascript Injection, inserendo nel parametro delle istruzioni.
Queste potrebbero dapprima essere utilizzate per segnalare visivamente all’hacker la riuscita dell’attacco ma, successivamente, verrebbero senza dubbio tramutate in qualcosa di nocivo per gli utenti.
In entrambi i casi, la risposta fornita dal server risulta modificata rispetto a quella “standard”, già presente in cache.
A questo punto l’obiettivo dei cybercriminali è quello di far memorizzare alla cache la propria versione della risposta, in modo tale da distribuirla alle vittime.
- Far si che la risposta sia posta in cache (fase finale)
Una volta constatata la possibilità di modificare le richieste in modo “produttivo”, giunge il momento di renderle fruibili agli utenti.
La maniera in cui vengono memorizzate le richieste in cache, però, non è scontata.
L’hacker arriva ad intuirla solamente dopo un’altra attenta analisi sul comportamento della memoria cache.
Non è scontato, infatti, che la richiesta malevola inviata vada a sostituire quella precedente con la stessa cache key.
La riuscita dell’attacco può venire verificata, volta per volta, usando un altro terminale.
È un procedimento alquanto macchinoso, ma rende l’idea sul funzionamento del Cache Poisoning.
Se sul secondo terminale si osserva la versione modificata della pagina richiesta, vuol dire che l’attacco è andato a buon fine e toccherà tutti gli utenti che visitano quella pagina.
- Conseguenze della Cache Poisoning
Il cache poisoning di per sé non causa danni né al sistema né agli utenti.
Perciò, i risvolti di questo tipo di attacchi dipendono fortemente dal payload che si riesce a inserire nei parametri della richiesta.
Da ciò deriva che:
- il web cache poisoning va sempre in coppia con altri attacchi
- non è direttamente l’avvelenamento della cache, ma sono gli attacchi collaterali a causare i veri e propri danni per sito ed utenti
Inoltre, l’impatto che deriva dalla manomissione di una cache è direttamente proporzionale al traffico diretto verso il servizio vittima: più utenti sollecitano la risposta corrotta, più aumenta il raggio d’azione dell’attacco.
I risvolti effettivi, però, dipendono dagli obiettivi dell’operazione offensiva. Ciò che è possibile stimare a priori è solamente l’impatto in termini di soggetti colpiti.
Infine, è bene notare che una volta trovato il modo di manomettere la cache, è possibile automatizzare un processo che reiteri la violazione nel tempo.
In sostanza, ciò fa sì che nella cache rimanga stabilmente la risposta malevola.
Ne consegue che, la persistenza dell’attacco serve ad aumentare ulteriormente il numero di soggetti colpiti.
- Misure di prevenzione
Per prevenire questi attacchi c’è bisogno di una attenta cooperazione tra tecnici, amministratori di rete e sviluppatori.
I primi hanno le conoscenze necessarie per configurare adeguatamente il server, affinché i parametri delle risposte inviate da esso non mostrino il fianco a facili manipolazioni, come il cache poisoning.
- A tal fine, ad esempio, sarebbe opportuno evitare che parametri dipendenti dagli input degli utenti facciano parte della cache key. Gli sviluppatori, inoltre, sono i responsabili di un corretto utilizzo degli input provenienti dalle richieste HTTP. Tale protocollo fa parte del livello applicativo in una comunicazione di rete, perciò, il suo corretto e sicuro utilizzo è responsabilità di chi produce l’applicazione.
- Occorre quindi verificare che non sia possibile, per un attaccante, manomettere i dati in cache attraverso l’uso di parametri unkeyed. Possibili punti vulnerabili possono essere introdotti, ad esempio, da moduli di terze parti usati nell’applicazione.
- A questo proposito, è cruciale validare gli input degli utenti ad ogni livello, anche lato client. Questo fa sì che anche nel caso in cui la cache sia violata, l’attacco non possa sortire alcun effetto.
- Infine, per una maggiore sicurezza, in alcuni casi è possibile pensare di consentire il caching dei soli file statici (ad esempio, pagine di testo per un blog), eliminando la possibilità di usare gli input utente per generare dinamicamente del contenuto.
- Conclusioni
Abbiamo visto come sia possibile, per un attaccante, portare avanti un’azione di Cache Poisoning al fine di proiettare un attacco su una moltitudine di utenti.
Sebbene possa sembrare che il problema risieda nei principi di funzionamento delle comunicazioni, in realtà è possibile operare alcuni accorgimenti per limitarne l’efficacia.
Oltre ad una attenta cooperazione tra tecnici e sviluppatori, è possibile utilizzare dei servizi di caching offerti da terzi, che prevedono anche dei controlli di sicurezza automatici.
https://cyberment.it/cyber-attacchi/cose-e-come-difendersi-dal-web-cache-poisoning/
