Come ormai tutti sapranno, da giorni gli enti pubblici italiani e in particolare la Polizia di Stato sono entrati in cyber-guerra con il gruppo di “hacktivisti” russo Killnet che nel giro di poche ore è riuscito a mettere K.O. diversi siti web, portali e sistemi dello stato italiano.
Analizziamo qui nel dettaglio l’attacco alla Polizia di Stato, accusata da Killnet di essersi “vantata” pubblicamente di aver bloccato una serie di attachi hacker da parte della Russia contro l’Eurovision.
In risposta, Killnet ha reso irraggiungibile il sito della Polizia per più di 30 ore, rincarando la dose con una serie di prese in giro e “meme” pubblicati sui propri canali di comunicazione.
Fortunatamente dopo una lunga analisi e un lungo lavoro il sito è tornato online, ma la figuraccia ormai è di dominio pubblico. Parlo di “figuraccia” perché Killnet non ha avuto bisogno di scervellarsi per trovare un attacco all’avanguardia e compromettere così i sistemi dello Stato Italiano, ma si sono avvalsi di un attacco molto vecchio, identificato con CVE-2007-6750, chiamato per l’appunto “Slow HTTP Attack”.
Per capire meglio di cosa si tratta, Gruppo3c ha simulato l’attacco contro un proprio server per dimostrare quanto sia stato facile per gli “hacktivisti” di Killnet mandare fuori produzione le infrastrutture delle pubbliche amministrazioni.
In cosa consiste lo Slow HTTP Attack?
Per spiegare questo attacco, faccio riferimento ad un articolo molto interessante che potete trovare qui.
Lo Slow HTTP Attack, anche detto Slow Loris, consiste nell’inviare richiesta HTTP con una velocità molto rallentata, inviando una lettera alla volta in un arco di tempo molto lungo, in questo modo la connessione può rimanere aperta, dato che il server sta ancora aspettando la sequenza di caratteri \n\n.
Ricordiamo infatti che una richiesta HTTP solitamente è composta solamente da testo contenente il tipo di richiesta (GET, POST, etc etc…) ed informazione riguardante il client, come tipo di browser, tipo di dispositivo, etc. La cosa da notare è che ogni richiesta HTTP termina con due caratteri di newline, ovvero “\n\n”. Questa sequenza di caratteri indica a fine della richiesta HTTP.
Questo comporta un continuo utilizzo del server, bloccando a tutti gli effetti qualsiasi utente provi a collegarsi al server attaccato.
Lo Slow HTTP Attack consiste nell’inviare richiesta HTTP con una velocità molto rallentata. Questo comporta un continuo utilizzo del server.
I server di oggi hanno una sorta di timeout per i client che perdono connessione al server durante una richiesta HTTP. Ma l’attacco Slow Loris funziona perché non fa scadere il timeout, ma ogni 10/20/30 secondi (appena prima del timeout) invia un’altro carattere della richiesta GET, mantenendo la connessione aperta.
Proof of concept.
Come si può vedere sul lato destro dalla GIF qui sotto, il server usato come cavia hosta il template open source di un sito trovato su GitHub.
Sulla sinistra si può vedere in alto il terminale che verrà usato per effettuare l’attacco, mentre in basso il file access_log del server Apache che attaccheremo.
Come vedete, aggiornando la pagina il server risponde immediatamente senza dare alcun problema.
Passiamo dunque all’attacco tramite il tool slowhttptest installato di default sul Sistema Operativo Kali Linux, il più utilizzato per quanto riguarda attività di Penetration Test.
Come si può vedere, pochi secondi dopo che l’attacco viene lanciato, ricaricando il sito web si nota un primo forte rallentamento, la pagina non carica più fluidamente come prima:
Infine, dopo poco più di un minuto di attacco, il server collassa e non riesce più a restituire nulla agli altri client che provano a collegarsi.
Come si può vedere, l’attacco è veramente molto veloce da sferrare.
Questa vulnerabilità è sofferta dai web-server Apache, che a oggi è ancora uno dei dei più diffusi del mondo, come si può evincere dal grafico qui sotto gentilmente offerto da questo articolo.
Remediation.
Per proteggere il tuo web server da Slow Loris, consigliamo quanto segue:
- Rifiuta/elimina connessioni con metodi HTTP (verbs) non supportati dall’URL.
- Limitare l’header e il body della richiesta a una lunghezza minima ragionevole. Imposta limiti specifici dell’URL più severi appropriati per ogni risorsa che accetta un body della richiesta.
- Impostare un timeout di connessione assoluto, se possibile. Ovviamente, se il timeout è troppo breve, si rischia di far cadere le connessioni lente legittime; se è troppo lungo, invece, non si ottiene alcuna protezione dagli attacchi. Raccomandiamo un valore di timeout basato sulle statistiche di lunghezza della connessione, ad es. un timeout leggermente maggiore della durata media delle connessioni dovrebbe soddisfare la maggior parte dei client legittimi.
- Definisci la velocità minima dei dati in entrata ed elimina le connessioni che sono più lente di quella velocità. Bisogna fare attenzione a non impostare il minimo troppo basso, o si rischia di far cadere le connessioni legittime.