L’autenticazione Kerberos
Prima di spiegare come funzionano le due tecniche di attacco in oggetto, inglobate nell’arsenale di ZAIUX® Evo, è necessario capire come funziona l’autenticazione Kerberos in un ambiente di tipo Active Directory.
All’interno di Active Directory il protocollo Kerberos è delegato alla gestione della maggior parte delle autenticazioni, sia a livello degli utenti che dei servizi. A differenza dell’autenticazione NTLM, che lavora su un principio challenge-response, l’autenticazione di tipo Kerberos utilizza un sistema di ticket.
Quando un utente effettua un login manda una richiesta al Domain Controller, il quale svolge il ruolo di “Key Distribution Center” (KDC). La richiesta iniziale di autenticazione, denominata AS_REQ, contiene un timestamp criptato, derivato dal nome utente corrente e dalla sua password. Quando il server riceve la richiesta di autenticazione, richiede l’hash della password dell’utente e tenta di decriptare il timestamp con esso. Se l’operazione di decrittazione va a buon fine l’autenticazione viene considerata come valida.
A questo punto il servizio risponde al client con un “Authentication Server Reply” (AS_REP) che contiene una session-key criptata con la password dell’utente, e un Ticket Granting Ticket (TGT).
Una volta che il client ha ricevuto la session-key e il TGT, il KDC considera l’autenticazione completata e considererà valido il TGT per dieci ore. Durante questo arco di tempo all’utente non verrà più chiesto di ripetere la password.
Accesso ad un servizio
Un altro caso in cui il KDC viene contattato è quello in cui l’utente cercasse di accedere ad una risorsa aziendale come ad esempio un servizio Exchange, SQL o una share di rete con un Service Principal Name (SPN) registrato.
In questo caso il client andrà a confezionare un Ticket Granting Service Request (TGS_REQ) che conterrà ancora una volta l’utente corrente, un timestamp criptato, l’SPN della risorsa alla quale si desidera accedere ed il TGT criptato.
Il Server KDC riceverà la richiesta TGS_REQ e se l’SPN esiste tenterà di decriptare il TGT, utilizzando una chiave nota solo al KDC stesso. Se la decrittazione avviene con successo verrà estratta la session-key, che a sua volta verrà utilizzata per decrittare lo username ed il timestamp. Se quest’ultimo risulterà valido allora la richiesta verrà accettata.
A questo punto il Ticket Granting Service risponderà al client con un Ticket Granting Server Reply (TGS_REP) che a sua volta è composto da 3 parti:
- l’SPN per il quale si sta richiedendo l’accesso
- Un Service-Ticket contenente le informazioni sullo user
- La session-key che dovrà essere utilizzata fra il cliente e l’SPN
A questo punto può avere inizio l’autenticazione del servizio.
Per prima cosa il client invia una Application Request (AP_REQ) la quale contiene lo username e un timestamp criptato con una session-key associata al Service-Ticket. Quando il servizio riceve l’AP_REQ ne decripta il ticket estraendo la session-key e il nome utente. Se c’è corrispondenza sul nome utente allora la richiesta viene autorizzata.
Kerberos in uno scenario di attacco
Ora che abbiamo capito come funziona l’autenticazione Kerberos vediamo quali problematiche di sicurezza potrebbero essere sfruttate da attaccanti per effettuare operazioni di Privilege Escalation o Lateral Movement all’interno della nostra infrastruttura IT.
KERBEROASTING
Il Kerberoasting è un attacco che appartiene alla fase del post-exploitation, ovvero quando l’attaccante ha già accesso alla rete interna e dispone di un’utenza di dominio valida, anche con minimi privilegi.
Attraverso questa tecnica l’attaccante sarà in grado di richiedere un TGS per un servizio specificandone solo il suo SPN. Active Directory stesso ritornerà un ticket criptato utilizzando l’hash NTLM dell’account associato all’SPN. L’attaccante a questo punto potrà estrarre il ticket dalla memoria e tentare di decrittarlo offline, anche attraverso attacchi a dizionario, senza rischiare di bloccare l’utenza.
Per difendersi da questo tipo di attacco è opportuno assicurarsi che i Service Accounts che utilizzano degli SPN abbiano password lunghe e complesse e, per quanto possibile, cambiare le password regolarmente. È anche possibile tener monitorate le autenticazioni anomale attraverso opportuni tool.
ASREP ROASTING
L’AS-REP Roasting è una tecnica che sfrutta il protocollo Kerberos ed in particolare gli account utente che non richiedono nessuna preauthentication. La preauthentication è appunto il primo step dell’autenticazione Kerberos ed è stata introdotta per prevenire attacchi di tipo brute-force, ed è impostata di default in un ambiente Active Directory.
Tuttavia, questa fase può essere disabilitata per ogni account utente per ragioni di compatibilità con librerie che non supportano le ultime versioni di Kerberos.
A differenza del Kerberoasting non è necessario conoscere le credenziali di alcun utente per far leva su questa vulnerabilità, basterà una richiesta di un TGT al KDC per gli utenti che non richiedono preauthentication. Inviando l’AS_REQ al KDC, ed ottenendo in risposta l’AS_REP, sarà quindi possibile procedere immediatamente all’estrazione della Session-Key che, come visto precedentemente, è criptata con la password dell’utente. A questo punto, come con il Kerberoasting, l’attaccante potrà tentare l’hashcracking della password in locale senza correre il rischio di bloccare l’utente in oggetto.
Per mitigare questa tipologia di attacco è opportuno verificare che per tutti gli account utente sia abilitata la preauthentication, e laddove fossimo obbligati a disabilitare questa fase sarebbe opportuno utilizzare password complesse e con un’alta frequenza di rotazione.
Un Penetration Test permette di validare la sicurezza della tua rete contro gli attacchi rivolti a Kerberos, e con l’approccio automatico e continuativo di ZAIUX® Evo è ora possibile eseguire in autonomia test frequenti e mantenere costante il livello di sicurezza.