Attacchi a Kerberos
Da Security e-Book.
Anche Kerberos non è immune agli attacchi, tuttavia possiamo rendere più difficile l'accesso ad un potenziale agressore in quanto esistono delle contromisure che possiamo adottare. Vediamo in particolare quali sono i possibili attacchi.
Tipi di attacchi
Compromissione del KDC. Una compromissione a livello di root di uno qualsiasi dei KDC (sia il master, sia uno degli slave) dà la possibilità all'eventuale attaccante di prendere il controllo totale del sistema di autenticazione Kerebros. Anche se il database è criptato su disco con la master key, quest'ultima è anche tenuta sul disco del KDC in quanto è possibile avviare il server senza intervento manuale quando il servizio viene avviato. In più l'accesso al database Kerberos viene sempre garantito all'amministratore di sistema (root o Administrator), per cui un eventuale break-in sul KDC potrebbe potenzialmente portare ad una compromissione dell'intero database di autenticazione Kerberos. Il suggerimento in questo caso è quello di proteggere il KDC attraverso l'hardening della macchina, rimuovendo tutti i servizi non necessari, applicando un personal firewall e applicando una password policy.
Compromissione dell'amministratore Kerberos. Se un potenziale intruso ottiene la password del principal collegato all'amministratore Kerberos, allora l'attaccante ha completo accesso al database Kerberos. Molte implementazioni del KDC permettono ad un amministratore di fare un dump remoto del contenuto del database per effettuare il backup dei dati: un attaccante può usare questa funzionalità per scaricare il database sulla sua macchina e tentare un brute-force attack in off-line. In più, avendo pieno accesso alle funzionalità del KDC, l'intruso potrà creare e modificare utenti Kerberos. Il suggerimento è quello di dare l'accesso di amministratore ad un numero molto ristretto di persone e su queste applicare una policy di password molto stretta, ad esempio costringendo gli amministratori a cambiare password ogni mese.
Compromissione di una macchina server. Per effettuare una mutual authentication in Kerberos tra server e client, il servizio deve accedere al principal associato. I service principal risiedono nel filesystem del server, sia esso in un keytab Unix o negli LSA Secret in Microsoft (rif. KnowledgeBase Microsoft Q184017). Quando un attaccante ottiene accesso di root alla macchina, tutti i servizi Kerberos erogati dalla stessa sono compromessi. Inoltre alcuni servizi come l'Andrew Filesystem (AFS) hanno lo stesso principal in tutti i server, per cui anche tutti i file nella cella AFS sono compromessi. Una volta che l'intruso viene in possesso del principal, può impersonare quel servizio e decriptare il traffico tra client e server. Ovviamente la sicurezza di un servizio Kerberos dipende dalla macchina su cui questo è eseguito, per cui si consiglia di fare l'hardening anche delle macchine in cui si stanno erogando i servizi Kerberos.
Compromissione di una macchina client. Una compromissione della macchina client può permettere ad un intruso di prendere i Kerberos ticket in cache sulla macchina. Siccome i ticket sono limitati nel tempo, non è una gravissima compromissione; avendo l'accesso alla macchina client, l'attaccante potrebbe installare un key logger e rilevare tutte le password inserite dall'utente. Il suggerimento è in caso di compromissione di cambiare immediatamente le password e di impostare tra le password policy un cambio password più frequente.
Compromissione delle credenziali di un utente. Ci sono due possibilità in questo caso: catturare le credenziali utente (ticket) presenti nella cache o la password utente. Come espresso precedentemente, il ticket in cache ha un tempo limitato e alla scadenza del ticket l'attaccante non avrebbe più modo di accedere ai servizi. Il secondo è più importante ed è necessario cambiare immediatamente la password.
Brute force attack e attacchi tramite dizionari. Un classico degli attacchi: l'intruso cercherà di ottenere le password di amministratore o di un utente, tentando di indovinarla tramite un dizionario ben definito o di ricavarla tramite un attacco di forza bruta. In questo caso il consiglio è di rendere complicata la password, impostando le policy in modo da introdurre caratteri non facili da indovinare.
Replay attack. Uno degli attacchi che potrebbero perpetrarsi ai danni di Kerberos è un replay attack. Il replay attack avviene quando un utente legittimo si sta autenticando al KDC per accedere ad un determinato servizio e un intruso si impossessa del traffico di autenticazione. In questo modo, l'intruso userà il ticket ottenuto per riproporsi al servizio e autenticarsi. È da notare che in questo scenario non viene cercata la password dell'utente in nessun modo. Vediamo come avviene in pratica. Esistono tre protezioni già implementate in Kerberos, ovvero Address field in tickets, Time-based authenticators e le Replay caches. La prima protezione inserisce l'IP address della workstation per cui il ticket è valido; la seconda inserisce un timestamp (o authenticator) nel ticket di accesso al servizio, in modo che la sessione non sia valida dopo il tempo di emissione del ticket (più il clockskew di tolleranza). L'ultimo livello di protezione implementato in Kerberos 5 è la replay cache, che impedisce ad un attaccante di riusare il ticket di accesso durante la tolleranza temporale del clockskew. Ogni servizio mantiene una cache di authenticator che ha ricevuto recentemente: se il servizio trova una copia dell'authenticator già in cache, rigetta la richiesta, altrimenti la accetta e aggiunge l'authenticator nella cache per validare le richieste successive.
Attacchi di tipo Man-in-the-Middle. In questo attacco l'intruso cerca di impersonare il KDC o il server di accesso, in modo che l'utente pensi di essere collegato al server legittimo, mentre in realtà sta parlando con un server fittizio, introdotto illecitamente, che redirige l'utente al server reale. In questo modo l'attaccante ha il controllo della sessione, per cui può impersonare l'utente durante la conversazione e cambiare i messaggi che transitano. Il programma KDCspoof è disponibile all’indirizzo http://www.monkey.org/~dugsong/kdcspoof.tar.gz e dimostra l'efficacia dell'attacco man-in-the-middle. Il suggerimento in questo caso è di abilitare la mutual authentication, così che anche il server debba dimostrare la sua identità all'utente: il server sfrutterà la propria chiave per criptare una risposta e mandarla al client. Se il server non fosse quello lecito, e quindi non in possesso della service key, allora non riuscirebbe ad inviare una risposta valida e il client si disconnetterebbe automaticamente.
Contromisure
Tutti questi scenari inducono ad un concetto fondamentale: installare Kerberos nella propria rete non diminuisce l'importanza di rendere sicure tutte le macchine installate, compresi i desktop. La compromissione di una macchina potrebbe comunque avere ripercussione sulla sicurezza dell'ambiente Kerberos. Riassumiamo brevemente i sei semplici passi che possiamo implementare per proteggerci da questi tipi di attacchi.
- Fare l'hardening di tutti i server che erogano i servizi Kerberos, in particolare dei server che svolgono il ruolo di KDC.
- Proteggere i KDC attraverso IP filtering e segmentazione della rete.
- Impostare una corretta policy delle password, ad esempio costringendo l'utente a scegliere una password di almeno 8 caratteri alfanumerici e facendola cambiare spesso senza reinserire password già usate in precedenza. Nell'implementazione MIT di Kerberos si implementa attraverso il comando kadmin: add_policy [-maxlife time] [-minlife time] [-history num] policy_name; per maggiori informazioni, si faccia riferimento alle man page. Su Windows invece si trova in Domain Security Policy, aprire Security Settings, Account Policies e infine Password Policy; i parametri sono Minimum password age, Maximum password age ed Enforce password history.
- Proteggere i client con un personal firewall, un antivirus, un anti-spyware e assegnando all'utente i minori privilegi possibili sulla macchina.
- Usare la pre-autenticazione: sul KDC di Microsoft è abilitata di default, invece sul MIT Kerberos è necessario immettere il seguente comando kadmin: modify_principal +requires_preauth principal.
- Usare sessioni criptate attraverso SSL o SSH.
