In questi giorni mi sono imbattuto in una discussione con un gruppo di colleghi sul funzionamento di Kerberos per l’autenticazione delle sessioni su Windows. La cosa interessante che ne è venuta fuori è che, sebbene in generale tutti considerano Kerberos più efficace degli altri metodi di autenticazione (a giusta ragione), ben pochi sanno come funziona. Ho deciso quindi di fare un piccolo post dove riassumere in breve il principio di funzionamento e le sue tecniche di exploit.
Come sempre, speriamo possa venir utile.
Kerberos opera con una serie di messaggi fra svariati attori per trasmettere in maniera sicura le informazioni sulla rete. Questo processo è gestito da:
- il Key Distribution Center (KDC)
- l’Authentication Services (AS)
- il Ticket Grating Service (TGS)
- il Ticket Granting Ticket (TGT)
Il processo
- Step 1: Il client, per prima cosa, chiede al KDC (il quale gestisce l’AS e il TGS) un ticket.
- Step 2: Il server risponde con una chiave segreta la quale viene cifrata con l’hashing della password dell’utente che l’Active Directory conosce. Questo è il TGT.
- Step 3: Il client decifra il messaggio ricevuto (in quanto la chiave di decifratura è la password che l’utente conosce) ed invia il TGT indietro al server richiedendo un ticket TGS
- Step 4: Il Server risponde con il ticket il quale verrà utilizzato per loggarsi ed accedere alle risorse di rete.
Com’è chiaro dagli step sopra descritti – siccome la password non viene mai inviata – si ha un aumento considerevole di sicurezza.
Più sicuro? Assolutamente si.
Inviolabile? No.
Vediamo come.
Pass-the-hash (rif. MITRE: T1075)
È una tecnica dove è possibile acquisire i privilegi di tutti gli utenti che si sono connessi alla macchina compromessa e man mano utilizzare quei privilegi per muoversi lateralmente applicando il medesimo attacco (horizontal movement). Se poi si dovesse riuscire a recuperare l’hash – generato dal login di un utente di grado amministrativo maggiore – comparirà una nuova possibilità per muoversi anche in maniera verticale (vertical movement). Il tutto, ovviamente, senza conoscere le credenziali.
Chiaro è che la conditio sine qua non è che prima che un utente malintenzionato possa eseguire un attacco pass-the-hash deve aver già ottenuto un accesso sull’host. Successivamente i pen tester (o chi per loro) possono raccogliere gli hash delle password utilizzando diversi metodi:
- gli hash memorizzati nella cache degli utenti che hanno precedentemente effettuato l’accesso a una macchina (ad esempio via console o tramite RDP) possono essere letti dal SAM da chiunque disponga dei privilegi di amministratore. Il comportamento predefinito circa la memorizzazione nella cache degli hash o delle credenziali per l’utilizzo offline può essere disabilitato dagli amministratori, quindi questa tecnica potrebbe non funzionare sempre se una macchina è stata sufficientemente protetta.
- Eseguendo il dump del database dell’account utente locale (SAM). Questo database contiene solo gli account degli utenti locali della macchina che è stata compromessa. Ad esempio, in un ambiente di dominio, il database SAM di una macchina non conterrà utenti di dominio, ma solo utenti locali a quella macchina che con ogni probabilità non saranno molto utili per autenticarsi ad altri servizi sul dominio. Tuttavia, se le stesse password dell’account amministrativo locale vengono utilizzate su più sistemi, chi attacca può accedere in remoto a tali sistemi utilizzando gli hash dell’account utente locale.
- Sniffando la chanllenge-response LM/NTLM tra client e server e successivamente eseguire un brute force attack su quanto ottenuto (a mio personalissimo avviso è un metodo che richiede tempo, risorse e un DB costruito ad-hoc sul target attaccato, in altre parole poco efficace)
- Eseguendo il dump delle credenziali degli utenti autenticati archiviate da Windows in memoria dal processo lsass.exe. Le credenziali scaricate in questo modo possono includere quelle di utenti o amministratori di dominio.
Pass-the-ticket (rif. MITRE: T1097)
Gli attacchi pass-the-ticket sono una categoria di attacchi post-exploit che coinvolgono il furto e il riutilizzo di un ticket Kerberos per l’autenticazione ai sistemi in un ambiente compromesso. Negli attacchi pass-the-ticket, l’attaccante viene in possesso di un ticket Kerberos da un computer e lo riutilizza per accedere a un altro computer.
Sebbene le due tecniche siano simili è importante capirne le differenze che intercorrono tra il pass-the-ticket e il pass-the-hash. Il primo sfrutta i ticket TGT che hanno una scadenza di poche ore (10 se non è stato cambiato il parametro di default), mentre il secondo utilizza gli hash NTLM che cambiano solo nel caso in cui un utente decida di cambiare la sua password. Un ticket TGT deve essere utilizzato entro la sua data di scadenza oppure va rinnovato per un periodo di tempo più lungo.
La seconda differenza è che questo attacco è l’unica strada percorribile quando l’autenticazione di dominio è stata ristretta unicamente a Kerberos. Qua avevo scritto un articolo (consiglio numero 10) sul come restringere il metodo di autenticazione (credential hardering).
In linea di massima il metodo utilizzato più di frequente per compiere lo scopo è quello già descritto precedentemente: eseguire il dump delle credenziali archiviate nel processo lsass.exe via tool come mimikatz o rebeus.
Rilevamento e mitigazioni
Il rilevamento e la mitigazione degli attacchi pass-the-ticket è davvero qualcosa di realmente impegnativo. Kerberos è un protocollo stateless, il che significa che le transazioni non vengono conservate durante una sessione di autenticazione o dopo. Ciò rende Kerberos (e Active Directory per estensione) vulnerabili agli attacchi pass-the-ticket, nonché agli attacchi Golden Ticket e Silver Ticket (potenzialmente devastanti in quanto utilizzano ticket “contraffatti” per concedere rispettivamente diritti di dominio o di servizio). Il design stateless di Kerberos rende anche il riutilizzo delle credenziali rubate un problema di sicurezza e privacy: è necessaria una convalida esterna del protocollo Kerberos per garantire che ogni ticket presentato da un principal Kerberos – ovvero un client di servizio – sia stato emesso da un KDC legittimo.
Un esempio di rilevamento consiste nel monitorare la tua rete controllando tutti gli eventi di autenticazione Kerberos e verificando eventuali discrepanze. Ad esempio:
- verificare le sessioni di accesso correnti per quel sistema
- esaminare il ticket Kerberos associato a quella sessione
- verificare la presenza di ticket Kerberos che non corrispondono al sistema sotto analisi
EOF