I ricercatori delle università di Amburgo e Colonia
una nuova tecnica di attacco alle reti di distribuzione dei contenuti e ai proxy di caching — (Cache-Poisoned Denial-of-Service). L'attacco consente di ottenere un'interruzione dell'accesso alla pagina tramite l'avvelenamento della cache.
Il problema è legato al fatto che i CDN memorizzano nella cache non solo le richieste riuscite, ma anche le situazioni in cui il server HTTP restituisce un errore. In generale, quando ci sono problemi nella formazione delle richieste, il server restituisce un errore 400 (Bad Request), fatta eccezione per IIS, che restituisce un errore 404 (Not Found) per intestazioni troppo grandi. Lo standard consente di memorizzare nella cache solo gli errori con i codici 404 (Not Found), 405 (Method Not Allowed), 410 (Gone) e 501 (Not Implemented), ma alcuni CDN memorizzano anche le risposte con codice 400 (Bad Request), che dipende dalla richiesta inviata.
Gli aggressori possono indurre il ritorno dell'errore '400 Bad Request' sulla risorsa originale inviando una richiesta con intestazioni HTTP formattate in un modo specifico. Queste intestazioni non vengono tenute in considerazione dai CDN, quindi nella cache finirà l'informazione sull'impossibilità di accedere alla pagina, e tutte le altre richieste corrette degli utenti fino alla scadenza del timeout possono portare a un errore, nonostante il sito originale restituisca correttamente il contenuto.
Per costringere il server HTTP a restituire un errore sono stati proposti tre tipi di attacco:
- HMO (HTTP Method Override) — l'aggressore può sovrascrivere il metodo originale della richiesta tramite le intestazioni 'X-HTTP-Method-Override', 'X-HTTP-Method' o 'X-Method-Override', supportate da alcuni server, ma non considerate dai CDN. Ad esempio, è possibile cambiare il metodo originale 'GET' in un metodo 'DELETE' vietato dal server o in un metodo 'POST' non applicabile per contenuti statici;
- HHO (HTTP Header Oversize) — l'aggressore può scegliere la dimensione dell'intestazione in modo che superi il limite del server originale, ma non rientri nei limiti dei CDN. Ad esempio, Apache httpd limita la dimensione dell'intestazione a 8 KB, mentre il CDN Amazon Cloudfront consente intestazioni fino a 20 KB;
- HMC (HTTP Meta Character) — l'aggressore può inserire nella richiesta caratteri speciali (\n, \r, \a), che sono considerati non validi sul server originale, ma ignorati dai CDN.
Il CDN CloudFront, utilizzato in Amazon Web Services (AWS), è stato particolarmente vulnerabile all'attacco. Attualmente, l'azienda Amazon ha già risolto il problema vietando la memorizzazione nella cache degli errori, ma gli esperti hanno impiegato oltre tre mesi per ottenere l'implementazione della protezione. Il problema ha colpito anche Cloudflare, Varnish, Akamai, CDN77 e
Fastly, ma l'attacco attraverso di loro è limitato ai server target che utilizzano IIS, ASP.NET, e . , con il potenziale per colpire l'11% dei domini del Ministero della Difesa degli Stati Uniti, il 16% degli URL del database HTTP Archive e circa il 30% dei 500 siti web principali secondo la classifica di Alexa.
Come metodo alternativo per bloccare l'attacco sul lato del sito, è possibile utilizzare l'intestazione "Cache-Control: no-store", che vieta la memorizzazione nella cache delle risposte. In alcuni CDN, come
CloudFront e Akamai, è possibile disattivare la memorizzazione nella cache degli errori a livello di impostazioni del profilo. Per la protezione è possibile utilizzare anche firewall per applicazioni web (WAF, Web Application Firewall), ma devono essere implementati sul lato CDN prima degli host che effettuano la memorizzazione nella cache.
Fonte: opennet.ru
