Diventa Autore per CoreTech | Scopri di più





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

Banner

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.

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

Sicurezza aziendale: da cosa è minacciata e come proteggerla?Il threat modeling per la sicurezza delle applicazioniScanner di vulnerabilità: ecco come funzionanoWeb security: 5 motivi per cui è essenziale contro i ransomwareChe cos'è DevSecOps e come dovrebbe funzionare?Test di penetrazione vs scansione delle vulnerabilitàConsiderazioni sui test di correzione delle applicazioni WebQuattro modi in cui l'analisi AppSec aiuta i tuoi professionisti DevSecOpsQuattro modi per combattere il divario di competenze di sicurezza informaticaDove i framework di cybersecurity incontrano la sicurezza webCome costruire un piano di risposta agli incidenti informaticiRendi i tuoi utenti parte della soluzione di sicurezza webSei l'unico che può proteggere le tue applicazioni webNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaConvergenza Dev-Sec: i progressi e le sfide sulla strada per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?Sei l'unico che può proteggere le tue applicazioni webCos'è la sicurezza del sito Web: come proteggere il tuo sito Web dall'hackingRendi i tuoi utenti parte della soluzione di sicurezza webConvergenza Dev-Sec: la ricerca illustra i progressi per garantire l'innovazioneAggiornamento FISMA: cosa sta cambiando e perché è importanteChe cos'è la sicurezza continua delle applicazioni Web?La differenza tra XSS e CSRFNuovo studio di settore: il 70% dei team salta i passaggi di sicurezzaPrevenzione e mitigazione XSSStop ai compromessi sulla sicurezza delle applicazioni webSfatare 5 miti sulla sicurezza informaticaBasta compromessi sulla sicurezza delle applicazioni webNozioni di base sulla sicurezza web: la tua applicazione web è sicura?Che cos'è l'iniezione dell’header HTTP?Fare shift left o no?Individuazione e correzione di falle di sicurezza in software di terze partiClassi di vulnerabilità Web nel contesto delle certificazioniScripting tra siti (XSS)Che cos'è un attacco CSRFChe cos'è una SQL Injection (SQLi) e come prevenirlaAttacchi di attraversamento di directoryChe cos'è la falsificazione delle richieste lato server (SSRF)?7 migliori pratiche per la sicurezza delle applicazioni WebBlack Hat 2021: la più grande minaccia alla sicurezza informaticaÈ ben fatto? Chiedi allo sviluppatore!Scegli la soluzione di sicurezza delle applicazioni web che fa per teSicurezza fai-da-te: lo stai facendo bene?Sulla sicurezza delle applicazioni web professionali per MSSPLa cattiva comunicazione è al centro delle sfide di AppSecImpostazione e raggiungimento degli obiettivi di sicurezza delle applicazioniMetriche di sicurezza informatica per le applicazioni WebCome evitare attacchi alla supply chainPerché la maggior parte delle misure di sicurezza delle applicazioni fallisceVuoi che la tua sicurezza sia costruita su scuse?Cos'è SCA e perché ne hai bisognoLa scansione ad hoc non è sufficienteEsposizione dei dati sensibili: come si verificano le violazioniHai paura dei test di sicurezza nell'SDLC?Vantaggi di Web Asset DiscoveryStrumenti di scansione delle vulnerabilità: perché non open source?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