Partendo dal presupposto che il server esegue azioni in base a determinate condizioni, analizziamo una situazione in cui il server effettua calcoli a seconda del risultato di tali condizioni e successivamente trasmette una risposta all’utente. In entrambi i casi, cioè sia quando i calcoli vengono effettuati, sia quando non lo sono, il server restituisce una risposta all’utente. Vale la pena notare che, nel caso in cui il server effettua calcoli, consuma una certa quantità di risorse, il che porta a un aumento del tempo di risposta del server. Di solito, queste differenze nei tempi di risposta sono così piccole da non essere percepibili dall’utente finale. Tuttavia, rivelare queste sottili differenze nei tempi di risposta può portare a una fuga di dati non intenzionale.
Consideriamo ora un esempio pratico di questa situazione, che si basa sul processo di login di un’applicazione. Supponiamo che il login fornito sia corretto ma la password sia errata: in tal caso, il server può decidere di eseguire calcoli, come la verifica della password. Se il server esegue questi calcoli, potrebbe richiedere risorse extra e causare un tempo di risposta più lungo rispetto al caso in cui i calcoli non vengono effettuati. Sebbene le differenze nei tempi di risposta siano generalmente piccole, esse sono presenti e possono essere misurate da un attaccante.
Lo stesso processo, ma quando anche il login è errato:
In caso di tali sottili differenze nei tempi di risposta, un attaccante potrebbe provare a utilizzare queste informazioni per dedurre la correttezza del login. Ad esempio, l’attaccante potrebbe eseguire un attacco di tipo timing attack, analizzando il tempo che il server impiega per rispondere a richieste con vari login. Confrontando i tempi di risposta, l’attaccante può dedurre quale richiesta ha impiegato più tempo, suggerendo che il login era corretto. Rivelare il login dell’utente consente agli attaccanti di eseguire un attacco di forza bruta per indovinare la password. In alcuni casi, può anche significare la rivelazione di informazioni sensibili, soprattutto quando il login è un indirizzo email associato a una persona specifica e l’applicazione testata è un portale con contenuti controversi.
Testare con Burp Suite – Request Timer
Durante la ricerca di questo tipo di vulnerabilità, sarà utile il plugin per Burp chiamato Request Timer. Questo plugin ci consentirà di analizzare il tempo di risposta del server per le richieste che definiamo.
Il primo passaggio sarà catturare la richiesta responsabile del login dell’utente e inviarla al modulo Intruder:
Successivamente, cambiamo la password in una lunga sequenza di caratteri per aumentare il carico sul server durante la generazione dell’hash della password. Indichiamo dove si trova il login dell’utente. Nel caso dell’applicazione esaminata, è necessario anche aggiungere l’intestazione “X-Forwarded-For” e assegnarle un indirizzo IP casuale per aggirare il blocco dei tentativi di login multipli dallo stesso indirizzo IP. Di conseguenza, dobbiamo cambiare il tipo di attacco su “Pitchfork”.
Aggiungiamo un elenco di login da verificare:
Nel plugin Request Timer definiamo che deve ascoltare il modulo Intruder:
Dopo aver avviato il test, nella scheda appariranno le richieste generate insieme ai tempi di risposta. Come si può notare, per il login corretto il tempo di risposta è molto più lungo. In questo modo abbiamo dimostrato che l’applicazione è vulnerabile all’enumerazione dei login degli utenti tramite l’analisi del tempo di risposta del server.
Cosa fare, come vivere?
Una delle soluzioni a questo problema è aggiungere una funzione responsabile di ritardare casualmente la risposta del server:
Tuttavia, il problema con questo tipo di soluzione è che non abbiamo ancora il controllo su situazioni come la riduzione della velocità della rete durante una connessione al database o le differenze che emergono quando il database cresce in modo significativo.
Una soluzione migliore sembra essere l’esecuzione delle operazioni di verifica dei dati forniti dall’utente in modo asincrono in background e notificare immediatamente l’utente del tentativo di login. In questo caso, i calcoli e i ritardi associati rimarranno invisibili per l’attaccante.
