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 a una pagina attraverso l'avvelenamento della cache.
Il problema è legato al fatto che i CDN memorizzano nella cache non solo le richieste eseguite con successo, ma anche le situazioni in cui il server HTTP restituisce un errore. In genere, in caso di problemi nella formulazione delle richieste, il server restituisce un errore 400 (Bad Request), eccezione fatta per IIS, che restituisce un errore 404 (Not Found) per intestazioni troppo grandi. Lo standard consente di memorizzare nella cache solo gli errori con 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 provocare un errore «400 Bad Request» sul sito originale inviando una richiesta con intestazioni HTTP formattate in un certo modo. Queste intestazioni non sono considerate dalla CDN, quindi nella cache finiranno informazioni sull'impossibilità di accedere alla pagina e tutte le altre richieste valide degli utenti fino alla scadenza del timeout possono portare a un errore, anche se il sito originale restituisce correttamente il contenuto.
Per forzare il server HTTP a restituire un errore, sono proposte tre varianti 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 dalla CDN. Ad esempio, è possibile cambiare il metodo originale «GET» in un metodo «DELETE» vietato sul server o in un metodo «POST» non applicabile per le risorse statiche;
- HHO (HTTP Header Oversize) — l'aggressore può scegliere una dimensione dell'intestazione in modo che superi il limite del server originale, ma non rientri nei limiti della CDN. Ad esempio, Apache httpd limita la dimensione dell'intestazione a 8 KB, mentre la CDN Amazon Cloudfront consente intestazioni fino a 20 KB;
- HMC (HTTP Meta Character) — un attaccante può inserire caratteri speciali nella richiesta (\n, \r, \a), considerati non validi sul server di origine, ma ignorati nel CDN.
Il CDN CloudFront, utilizzato in Amazon Web Services (AWS), è stato il più vulnerabile all'attacco. Attualmente, Amazon ha già risolto il problema vietando la memorizzazione nella cache degli errori, ma agli esperti sono servuti oltre tre mesi per ottenere l'aggiunta di misure di protezione. Il problema ha riguardato anche Cloudflare, Varnish, Akamai, CDN77 e
Fastly, ma l'attacco attraverso di essi è limitato ai server target che utilizzano IIS, ASP.NET, e . , il che significa che circa 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 più grandi secondo il rating di Alexa sono potenzialmente vulnerabili all'attacco.
Come misura di bypass per bloccare l'attacco lato sito, si può utilizzare l'intestazione "Cache-Control: no-store", che proibisce la memorizzazione nella cache delle risposte. In alcuni CDN, ad esempio in
CloudFront e Akamai consentono di disattivare la cache degli errori a livello delle impostazioni del profilo. Per la protezione, è possibile utilizzare anche i firewall per applicazioni web (WAF, Web Application Firewall), che devono però essere implementati sul lato CDN prima degli host che effettuano la cache.
Fonte: opennet.ru
