Diventa Autore per CoreTech | Scopri di più
23/04/21 CoreTech Blog
Gli attacchi legati all'avvelenamento della cache rappresentano una tendenza alla sicurezza web chiaramente visibile che è emersa negli ultimi anni. La comunità della sicurezza continua a fare ricerche in quest'area, trovando nuovi modi per attaccare.
In questo articolo, vorrei condividere con voi alcune tecniche relative a uno dei nuovi controlli: Cache Poisoning DoS (CPDoS) .
Nel 2019 Hoai Viet Nguyen e Luigi Lo Iacono hanno pubblicato un white paper relativo agli attacchi CPDoS . Hanno spiegato varie tecniche di attacco e analizzato diverse reti di distribuzione di contenuti e server Web che potrebbero essere interessati da tali attacchi.
Gli attacchi CPDoS sono possibili se è presente un server proxy cache intermedio, situato tra il client (l'utente) e il server web (il back-end), che è configurato per memorizzare nella cache le risposte con codici di stato relativi all'errore (es. 400 Bad Request ). L'autore dell'attacco può manipolare le richieste HTTP e costringere il server Web a rispondere con un codice di stato di errore di questo tipo per una risorsa esistente (percorso). Quindi, il server proxy memorizza nella cache la risposta di errore e tutti gli altri utenti che richiedono la stessa risorsa ottengono la risposta di errore dal proxy della cache invece di una risposta valida.
Il white paper presenta 3 tipi di attacco che consentono all'autore dell'attacco di forzare un'applicazione Web a restituire un codice di stato 400:
Analizzando questi attacchi e lavorando al mio progetto dedicato ai proxy inversi , sono riuscito a escogitare un paio di trucchi che possono essere utilizzati per eseguire un attacco HHO.
Fondamentalmente, un attacco HHO è possibile quando la lunghezza massima dell'intestazione è definita in modo diverso nel proxy della cache e nel server web. Diversi server Web, server cache e bilanciatori del carico hanno limiti predefiniti diversi. Se il proxy della cache ha un limite di intestazione massimo superiore al limite definito nel server Web, una richiesta con un'intestazione molto lunga può passare attraverso il server della cache al server Web e causare il server Web a restituire un errore 400 (che verrà quindi memorizzato nella cache dal server cache).
Ad esempio, la lunghezza massima dell'intestazione predefinita per CloudFront è 20.480 byte. D'altra parte, la lunghezza massima dell'intestazione predefinita per il server Web Apache è 8.192 byte. Pertanto, se un utente malintenzionato invia una richiesta con un'intestazione lunga 10.000 byte e il proxy della cache CloudFront la passa a un server Apache, il server Web Apache restituisce un errore 400.
Tuttavia, un attacco HHO è possibile anche se il server cache ha lo stesso limite di lunghezza dell'intestazione del server Web o uno leggermente inferiore. Ci sono due ragioni per questo:
Un pratico attacco HHO potrebbe essere eseguito come segue:
Se il limite di lunghezza massima dell'intestazione del proxy della cache è leggermente inferiore al limite del server web, non possiamo utilizzare il trucco descritto sopra (1 byte non è sufficiente). Tuttavia, in tal caso, possiamo abusare di un'altra caratteristica.
Molti server proxy aggiungono intestazioni alle richieste che vengono inoltrate al server web. Ad esempio, X-Forwarded-For, che contiene l'indirizzo IP dell'utente. Tuttavia, se la richiesta originale contiene anche l'intestazione X-Forwarded-For, il server proxy spesso concatena il valore originale con il valore impostato dal server proxy (l'IP dell'utente).
Questo ci permette di eseguire il seguente attacco:
A seconda del tipo di proxy e della sua configurazione, tali intestazioni aggiunte possono essere diverse e anche le lunghezze dei valori aggiunti possono essere diverse. Puoi controllarne alcuni nella pagina del mio progetto .
Quando stavamo testando il nostro nuovo script CPDoS su siti di bug bounty, abbiamo notato che molti siti sono vulnerabili a tali attacchi. Tuttavia, in alcuni casi, l'impatto dell'attacco è discutibile. Questo perché alcuni proxy della cache sono configurati per memorizzare nella cache le risposte con codici di stato di errore solo per pochi secondi, il che rende difficile l'utilizzo.