I sistemi di autenticazione con username e password sono i più diffusi grazie alla loro semplicità d’implementazione. I più comuni attacchi di cui sono vittima questi sistemi sono: username enume-ration, password guessing ed eavesdropping.
2.2.1 Username enumeration
L’username enumeration (letteralmente “elencare i nomi utente”), consiste nello sfruttare le infor-mazioni date dal sistema per identificare la lista degli username esistenti nel sistema. Questo permet-te di velocizzare nettamenpermet-te il successivo processo d’individuazione della password.
Di seguito sono elencati alcuni metodi per determinare l’esistenza di uno username: 1. Messaggi di errore nel login
Accedendo con credenziali invalide, solitamente i sistemi restituiscono un messaggio di er-rore. Quando questo messaggio è troppo specifico, è possibile risalire all’esistenza dell’utente. Per esempio se un sistema restituisce i seguenti messaggi:
a) Nome utente errato b) Password errata
c) Nome utente o password errata l’attaccante può sapere se un utente esiste (b).
2. Messaggi di errore nei meccanismi di recupero password
Simile al precedente, ma la vulnerabilità risiede nel meccanismo di recupero password (il classico “Hai dimenticato la password?” delle più comuni applicazioni web). Di solito que-sti meccanismi richiedono l’inserimento del nome utente o dell’indirizzo e-mail associato a quell’account. Questo metodo “autentica” l’utente, dando per scontato che solo lui può ac-cedere al contenuto dell’e-mail associata all’account. Tuttavia, una cattiva implementazione di tale meccanismo spesso riferisce se il nome utente o l’indirizzo e-mail inserito è valido. Da queste informazioni si può risalire all’esistenza dell’username. Inoltre, se il sistema
im-27
plementa un meccanismo di SSPR (Self-Service Password Reset), è possibile, tramite un at-tacco DoS, sommergere l’account degli utenti il cui username è stato scoperto con continue e-mail contenenti nuove password.
3. Registrazione
Molte applicazioni permettono agli utenti di registrarsi scegliendo il proprio username. Du-rante la procedura di registrazione, se viene selezionato un nome utente già in uso da un al-tro account, viene visualizzato un messaggio di errore che specifica di inserire un nome utente diverso.
4. Attacchi temporizzati
Se nessuna delle tecniche precedenti fornisce risultati accettabili, l’ultima risorsa per gli at-taccanti è temporizzare i tempi di risposta dei messaggi di errore. A seconda dell’algoritmo implementato per controllare gli accessi, è possibile che un messaggio di errore dovuto ad un nome utente errato, venga generato più velocemente di uno dovuto all’inserimento sba-gliato della password (ciò capita spesso perché la password attraversa delle procedure di ci-fratura prima di essere controllata). Osservando le differenze di tempo intercorse tra un ten-tativo e l’altro, è possibile ottenere indizi sull’esistenza dell’username. Tuttavia perché que-sta tecnica sia efficace, le differenze di tempo devono essere sufficientemente grandi da compensare le fluttuazioni dovute al carico e alla latenza della rete.
Per proteggersi da questo tipo di attacco è sufficiente prestare attenzione alle informazioni che ven-gono restituite in fase di accesso. Purtroppo però, nelle applicazioni che prevedono sistemi di regi-strazione degli utenti automatici, le contromisure non sono facilmente realizzabili. Per questo moti-vo molti web master hanno accettato i rischi legati alla possibilità di indovinare gli username, in cambio di una maggiore libertà e flessibilità delle loro applicazioni.
2.2.2 Password guessing
Solitamente, le tecniche di password guessing (letteralmente “tirare a indovinare la password”) pos-sono essere eseguite a prescindere dal protocollo di autenticazione in uso.
1. Password guessing manuale
Indovinare manualmente la password è un compito noioso, ma i vantaggi dell’intuito uma-no lo rendouma-no spesso più efficiente e veloce di uuma-no strumento automatico, soprattutto quando i messaggi di errore sono particolarmente dettagliati. Questa tecnica si appoggia a dizionari di password comunemente utilizzati e facilmente reperibili in rete. Attraverso strumenti appositi, è possibile inviare un intero dizionario di coppie username/password a un’applicazione. Inoltre, se si è a conoscenza delle politiche di creazione delle password adottate dall’applicazione, si può ridurre l’insieme delle possibili password da inserire nel dizionario. Per esempio, se la politica permette l’utilizzo solo di password con almeno un numero al loro interno, è inutile includere nel dizionario parole che non ne hanno.
2. Password guessing automatico
Esistono principalmente due approcci al password guessing automatico: depth first e breadth first. Il primo prova tutte le combinazioni possibili di password per un determinato username. Questo può portare facilmente al blocco dell’account, se tale caratteristica è stata implementata nell’applicazione in cui accedere. Il secondo invece lavora al contrario: la
stes-28
sa password viene provata per diversi username. In questo modo si evita il rischio di blocco dell’account in applicazioni dotate di questa caratteristica.
Alcuni dei principali software per scovare le password sono: THC-Hydra [23], WebCrac-ker [24] e Brutus [25].
Figura 2.1. Un’esecuzione di Brutus per un sistema di autenticazione base HTTP.
Le contromisure più efficienti contro attacchi di questo tipo consistono nella combinazione di rigi-de politiche di creazione rigi-delle password e di blocco rigi-degli account. Va tenuto conto però, che un’applicazione che implementa il blocco degli account è vulnerabile ad attacchi di tipo DoS. Un utente malevolo potrebbe tentare di bloccare tutti gli account del sistema con tentativi di autentica-zione ripetuti. Un buon compromesso consiste nel bloccare solo temporaneamente l’account utente. Questo rallenterebbe notevolmente la velocità richiesta per indovinare le password e quindi ridurre l’efficienza dell’attacco. Una politica severa di creazione delle password, riduce il rischio di indovina-re casualmente le password.
Recentemente, alcuni siti hanno iniziato a tracciare l’indirizzo IP dei client che accedono al sistema, legandoli all’account. L’accesso da un IP insolito fa scattare dei meccanismi di autenticazione ag-giuntivi, come i CAPTCHA (Completely Automated Public Turing Tests to Tell Computers and Humans Apart) [26], dei test composti da una o più domande (solitamente un immagine con carat-teri alfanumerici da riconoscere e inserire in un apposito campo) capaci di determinare dalle risposte se l’utente è un essere umano o un bot. Queste tecniche permettono di prevenire gli attacchi distri-buiti o di password guessing.
Infine, è buona norma salvare in un log di sistema tutti gli eventi relativi ad autenticazioni fallite e monitorare tale log periodicamente per individuare segni di possibili attacchi a forza bruta.
29
2.2.3 Eavesdropping
Qualsiasi protocollo di autenticazione che espone le credenziali in transito sulla rete, è potenzial-mente vulnerabile ad attacchi eavesdropping (letteralpotenzial-mente “origliare”), detti anche attacchi di snif-fing (letteralmente “fiutare”). L’eavesdropping è alla base degli attacchi di tipo replay, il quale uti-lizza le credenziali “origliate” per simulare, in risposta, l’identità dell’utente originale.
L’autenticazione base viene inizializzata nel momento in cui un client invia una richiesta di una risorsa protetta a un web server. A questa richiesta, il server risponde con un HTTP 401 Unautho-rized, un messaggio che specifica la richiesta di autenticazione causando la comparsa di una finestra nel browser, simile a quella in Figura 2.2.
Figura 2.2. La finestra di autenticazione base di un browser.
L’utente inserisce le sue credenziali e un messaggio simile al seguente viene inviato via HTTP:
GET /test/secure HTTP/1.0
Authorization: Basic dGVzdDp0ZXN0
Username e password sono incapsulate nella sezione Authorization dell’header, codificate con l’algoritmo Base64 [27]. L’intero flusso è riassunto in Figura 2.3. Trattandosi di un sistema di nu-merazione posizionale, il Base64 è facilmente decodificabile e pertanto l’autenticazione base è vulne-rabile agli attacchi di tipo eavesdropping. L’utilizzo dell’HTTPS (HyperText Transfer Protocol over Secure socket layer), che applica un protocollo di cifratura asimmetrica al protocollo standard HTTP, permette di mitigare questa limitazione.
30
L’autenticazione tramite digest è stata appositamente pensata per fornire un maggiore livello di sicurezza rispetto a quella di base. L’autenticazione con digest si basa sul modello di autenticazione challenge-response, in cui una delle parti pone una domanda (“challenge”) e l’altra deve fornire una valida risposta per autenticarsi (“response”). Il meccanismo è illustrato in Figura 2.4. In seguito ad una richiesta di accesso da parte del client, il server risponde inviando un valore casuale detto nonce (contrazione di number used once), un numero che viene utilizzato una solta volta e poi scartato. Il browser usa quindi una funzione di cifratura asimmetrica per generare un messaggio di digest con la richiesta, il nome utente, la password e il nonce stesso. Il server quindi confronta l’hash e se coincide la richiesta viene soddisfatta.
Figura 2.4. Funzionamento dell'autenticazione con digest.
L’autenticazione con digest è un notevole passo avanti rispetto all’autenticazione di base, in quanto le credenziali utente non sono inviate in chiaro sulla rete.