Nuova ricerca dimostra 4 varianti dell'attacco con richieste HTTP
7 Agosto 2020 - Tempo di lettura: 29 minuti
Una nuova ricerca ha identificato quattro nuove varianti di attacchi di contrabbando di richieste HTTP che funzionano contro vari server Web commerciali standard e server proxy HTTP.
Amit Klein, vicepresidente della ricerca sulla sicurezza di SafeBreach, che ha presentato i risultati oggi alla conferenza sulla sicurezza di Black Hat, ha affermato che gli attacchi evidenziano come i server Web e i server proxy HTTP siano ancora suscettibili al traffico di richieste HTTP anche dopo 15 anni dalla loro prima documentazione.
Che cos'è il traffico di richieste HTTP?
Il contrabbando di richieste HTTP (o Desyncing HTTP) è una tecnica utilizzata per interferire con il modo in cui un sito Web elabora sequenze di richieste HTTP ricevute da uno o più utenti.
Le vulnerabilità legate al contrabbando di richieste HTTP si presentano in genere quando il front-end (un bilanciamento del carico o un proxy) e i server back-end interpretano il confine di una richiesta HTTP in modo diverso, consentendo così a un cattivo attore di inviare (o "contrabbandare") un ambiguo richiesta anticipata alla successiva richiesta dell'utente legittima.
Questa desincronizzazione delle richieste può essere sfruttata per dirottare le credenziali, iniettare risposte agli utenti e persino rubare i dati dalla richiesta di una vittima ed estrarre le informazioni su un server controllato da un utente malintenzionato.
La tecnica è stata dimostrata per la prima volta nel 2005 da un gruppo di ricercatori di Watchfire, tra cui Klein, Chaim Linhart, Ronen Heled e Steve Orrin. Ma negli ultimi cinque anni sono stati ideati numerosi miglioramenti, che si sono espansi in modo significativo sulla superficie di attacco per unire le richieste ad altre e "ottenere il massimo privilegio di accesso alle API interne", avvelenare le cache Web e compromettere le pagine di accesso di applicazioni popolari.
Cosa c'è di nuovo?
Le nuove varianti divulgate da Klein prevedono l'utilizzo di varie combinazioni proxy-server, tra cui Abyss di Aprelium, Microsoft IIS, Apache e Tomcat in modalità server Web e Nginx, Squid, HAProxy, Caddy e Traefik in modalità proxy HTTP.
L'elenco di tutte le nuove quattro varianti è il seguente, inclusa una vecchia che il ricercatore ha sfruttato con successo nei suoi esperimenti.
- Variante 1: "Posta indesiderata di intestazione SP / CR: ..."
- Variante 2 - "Aspetta"
- Variante 3 - HTTP / 1.2 per bypassare la difesa mod_security
- Variante 4: una soluzione semplice
- Variante 5 - "Intestazione CR"
Quando si gestivano richieste HTTP contenenti due campi di intestazione Content-Length, Abyss, ad esempio, è risultato che accettava la seconda intestazione come valida, mentre Squid utilizzava la prima intestazione Content-Length, portando così i due server a interpretare le richieste in modo diverso e a soddisfare la richiesta contrabbando.
Nelle situazioni in cui Abyss riceve una richiesta HTTP con un corpo la cui lunghezza è inferiore al valore Content-Length specificato, attende 30 secondi per soddisfare la richiesta, ma non prima di ignorare il corpo rimanente della richiesta. Klein ha scoperto che questo si traduce anche in discrepanze tra Squid e Abyss, con quest'ultimo che interpreta parti della richiesta HTTP in uscita come una seconda richiesta.
Una terza variante dell'attacco utilizza HTTP / 1.2 per aggirare le difese WAF come definito in OWASP ModSecurity Core Rule Set (CRS) per prevenire gli attacchi di contrabbando di richieste HTTP creano un payload dannoso che attiva il comportamento.
Infine, Klein ha scoperto che l'utilizzo del campo di intestazione "Content-Type: text / plain" era sufficiente per aggirare i controlli di livello di paranoia 1 e 2 specificati in CRS e produrre una vulnerabilità del traffico di richieste HTTP.
Quali sono le possibili difese?
Dopo che i risultati sono stati resi noti ad Aprelium, Squid e OWASP CRS, i problemi sono stati risolti in Abyss X1 v2.14 , Squid versioni 4.12 e 5.0.3 e CRS v3.3.0 .
Richiedendo la normalizzazione delle richieste HTTP in uscita dai server proxy, Klein ha sottolineato la necessità di una soluzione firewall per applicazioni web robusta e open source in grado di gestire gli attacchi di contrabbando di richieste HTTP.
"ModSecurity (combinato con CRS) è davvero un progetto open source, ma per quanto riguarda robustezza e genericità, mod_security presenta diversi svantaggi", ha osservato Klein. "Non fornisce protezione completa contro il traffico di richieste HTTP [e] è disponibile solo per Apache, IIS e nginx."
A tal fine, Klein ha pubblicato una libreria basata su C ++ che garantisce che tutte le richieste HTTP in entrata siano completamente valide, conformi e inequivocabili applicando una stretta aderenza al formato dell'intestazione HTTP e al formato della riga di richiesta. È possibile accedervi da GitHub qui.
