Contatta il reparto vendite 800 13.40.41 | Richiedi il Supporto Partner EN flag

Articoli

Icona delle News




Tecniche di attacco Denial-of-Service con avvelenamento della cache

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) .

Che cos'è un attacco Denial of Service con avvelenamento della cache

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.

Banner

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:

  • HTTP Header Oversize (HHO): quando la dimensione di un'intestazione supera la lunghezza massima dell'intestazione
  • HTTP Meta Character (HMC): quando l'intestazione della richiesta dell'aggressore contiene un simbolo speciale "illegale"
  • HTTP Method Override (HMO): quando l'intestazione della richiesta dell'aggressore cambia il verbo (metodo) in uno non supportato

Nuovi trucchi di attacco HHO

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:

  • Il limite di lunghezza massima dell'intestazione del server Web è un limite di lunghezza della stringa. I server web che ho testato non eseguono alcuna normalizzazione e probabilmente non analizzano nemmeno l'intestazione prima di applicare il controllo della lunghezza.
  • Tuttavia, i proxy della cache inviano intestazioni corrette (normalizzate) al back-end.

Esempio di attacco HHO con lo stesso limite

Un pratico attacco HHO potrebbe essere eseguito come segue:

  1. L'aggressore invia una richiesta con un'intestazione lunga 8192 byte (inclusi \ r \ n) ma senza spazi tra il nome dell'intestazione e il valore. Ad esempio:
    nome-intestazione: abcdefgh (…)
    (8192 caratteri in totale)
  2. Il proxy della cache controlla la lunghezza dell'intestazione e rileva che non supera gli 8192 caratteri. Pertanto, analizza l'intestazione e ignora lo spazio mancante.
  3. Quindi, il proxy della cache prepara la versione corretta dell'intestazione da inviare al server web:
    nome-intestazione: abcdefgh (…)
    (8193 caratteri in totale)
  4. Il proxy della cache non controlla che la lunghezza finale dell'intestazione superi 8192 caratteri e invia l'intestazione al server web.
  5. Il server web che riceve l'intestazione vede che supera il limite di un byte e quindi restituisce la pagina di errore 400.

Esempio di attacco HHO con limite simile

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:

  1. L'aggressore invia una richiesta con la seguente intestazione:
    X-Forwarded-For: abcdefgh (…)
    (8192 caratteri in totale)
  2. Il proxy concatena questa richiesta con il proprio valore:
    X-Forwarded-For: abcdefgh (…) 12.34.56.78
    (8203 caratteri in totale)
  3. Il proxy invia il valore al server web, che risponde con un codice di errore perché l'intestazione è troppo lunga.

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 .

L'impatto degli attacchi CPDoS

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.


Articoli su Sicurezza

Protezione WAF - Ottieni il massimo dal tuo firewall per applicazioni webL'errore di comunicazione è al centro delle sfide di AppSecDebugger remoti come vettore di attaccoDAST è una parte essenziale di un programma completo per la sicurezza delle applicazioniCome difendersi dagli attacchi recenti su Microsoft Exchange5 principali vantaggi dei primi test di sicurezzaTecniche di attacco Denial-of-Service con avvelenamento della cacheQuali principali attacchi web possiamo aspettarci nella nuova top 10 di OWASP?Hack di SolarWindsPillole di Sicurezza | Episodio 38Pillole di Sicurezza | Episodio 37Perché gli sviluppatori evitano la sicurezza e cosa puoi fare al riguardoPillole di Sicurezza | Episodio 36Cos'è l'attacco RUDYCos'è la navigazione forzataCome gli scanner trovano le vulnerabilitàPillole di Sicurezza | Episodio 34Pillole di Sicurezza | Episodio 35Come eseguire il benchmark di uno scanner di vulnerabilità Web?Pillole di Sicurezza | Episodio 33Pillole di Sicurezza | Episodio 325 proposte di vendita comuni sulla sicurezza delle applicazioni web5 motivi per non fare affidamento sui programmi BountyPillole di Sicurezza | Episodio 315 motivi per cui la sicurezza web è importante quanto la sicurezza degli endpointPillole di Sicurezza | Episodio 305 motivi per cui la sicurezza web è importante per evitare il ransomwarePillole di Sicurezza | Episodio 293 motivi per cui DAST è il migliore per la sicurezza delle applicazioni WebPillole di Sicurezza | Episodio 28Pillole di Sicurezza | Episodio 27Pillole di Sicurezza | Episodio 24Pillole di Sicurezza | Episodio 25Pillole di Sicurezza | Episodio 21Pillole di Sicurezza | Episodio 22Pillole di Sicurezza | Episodio 20Pillole di Sicurezza | Episodio 17Il flag HttpOnly: protezione dei cookie da XSSPillole di Sicurezza | Episodio 16Il Bug Heartbleed – I vecchi Bug sono duri a morirePillole di Sicurezza | Episodio 15Pillole di Sicurezza | Episodio 14Pillole di Sicurezza | Episodio 13Pillole di Sicurezza | Episodio 12Pillole di Sicurezza | Episodio 11Pillole di Sicurezza | Episodio 10Sicurezza delle reti: gli hacker puntano CitrixCyber hacking: la Germania chiede l’intervento dell’UESicurezza informatica: Cisco rilascia aggiornamentiOcchio al cryptojacking: malware infiltrato in Docker HubSIGRed: bug di sistema in Windows Server scovato dopo 17 anniPillole di Sicurezza | Episodio 9Summit Live - Disponibili le registrazioni delle live di MonteleoneCriminalità informatica: Schmersal sventa un cyber-attaccoPillole di Sicurezza | Episodio 8Pillole di Sicurezza | Episodio 7Analisi pratica dei rischi per il SysAdmin, DevOps e Dev | Summit LivePillole di Sicurezza | Episodio 6Pillole di Sicurezza | Episodio 5Pillole di Sicurezza | Episodio 4Pillole di Sicurezza | Episodio 3Pillole di Sicurezza | Episodio 2Pillole di Sicurezza | Episodio 1Pillole di Sicurezza | Episodio 23
Ripe Ncc Member
vmware
CloudLinux
Plesk
HP
Microsoft