I criminali informatici in genere si affidano a falle di sicurezza irrisolte o a configurazioni deboli o errate per lanciare attacchi e, in molti casi, possono anche essere finalizzati perché gli amministratori IT o gli utenti regolari non installano patch cruciali o non riescono in tempo a farlo. Quindi, adottare misure di sicurezza troppo lassiste, commettere errori o semplicemente configurare i sistemi in modo “leggero” può attirare gli aggressori a sferrare un attacco informatico.

Cos'è Kerberos e perché Microsoft si è recentemente affrettata a distribuire patch correttive out-of-band al di fuori del tipico ciclo di rilascio?

Il protocollo di rete Kerberos, che controlla le procedure di autenticazione nelle applicazioni client-server utilizzando la crittografia a chiave simmetrica o segreta, è l'obiettivo dell'attacco noto come "Kerberoasting".
Da Windows 2000, Microsoft utilizza questo protocollo come metodo di autenticazione predefinito in Windows ed è parte integrante del servizio Windows Active Directory (AD). Anche i fornitori di servizi a banda larga utilizzano il protocollo per autenticare i modem via cavo e i set-top box che accedono alle loro reti.

Kerberos è in sostanza un protocollo per l'autenticazione delle richieste di servizio tra host trusted (affidabili) attraverso una rete untrusted (non affidabile), come Internet. Il supporto di Kerberos è integrato in tutti i principali sistemi operativi, tra cui Microsoft Windows, Apple macOS, FreeBSD e Linux.

Il cane a tre teste Cerbero, che custodiva le porte dell'Ade nella mitologia greca, è ciò da cui prende il nome. Le tre teste del protocollo Kerberos rappresentano:

• il client che intende accedere alla risorsa di rete
• la risorsa di rete, ovvero il server che fornisce l'accesso alla risorsa di rete
• il Key Distribution Center (KDC) che funge da servizio di autenticazione affidabile di terze parti di Kerberos

Il KDC, a sua volta, ha tre componenti principali:

• un server di autenticazione che ha il compito di riconoscere gli utenti ed emettere i tickets per coloro che ne fanno richiesta
• un server di concessione di tickets che emette tickets di servizio basati sui tickets di concessione iniziali
• un database di principals con le chiavi segrete di tutti gli utenti e dei servizi che mantiene

Solo il KDC dovrebbe essere considerato attendibile da utenti, sistemi e servizi che utilizzano Kerberos, che funziona come un unico processo e offre due servizi: un servizio di autenticazione e un servizio di ticketing TGS (Ticket Granting Service).

Kerberoasting sfrutta il fatto che con Kerberos qualsiasi utente di dominio autenticato può richiedere un ticket per accedere a un servizio, anche se non ha i diritti per connettersi ad esso. In questo attacco, l'aggressore richiede un TGS per il nome principale del servizio (SPN) dell'account del servizio di destinazione. Questa richiesta viene inoltrata al controller di dominio utilizzando un ticket di autenticazione TGT (Ticket Granting Ticket) valido per l'utente del dominio. Il controller di dominio potrebbe non avere alcun record ma, se l'utente ha accesso alle risorse di rete, si limita a cercare il Service Principal Name (SPN) in Active Directory e risponde con un ticket crittografato. Il tipo di crittografia utilizzato per il service ticket (ST) richiesto è RC4_HMAC_MD5, ciò indica che per crittografare l'ST viene utilizzato l'hash della password NTLM. Per decifrare l'ST, l'aggressore esporta i ticket TGS dalla memoria e li salva sul sistema locale. Successivamente utilizzando diversi hash NTLM procede al cracking del ST per ottenere la password dell'account di servizio.

Generalmente si utilizzano strumenti come Kerberoast per eseguire attacchi Kerberoasting sull'autenticazione Kerberos e le fasi principali sono le seguenti:

• l'attaccante richiede per conto di un utente un ticket di autenticazione (TGT) al controller di dominio o KDC
• il controller di dominio verifica l'account utente e risponde con un TGT crittografato
• con un ticket di autenticazione utente (TGT) valido, l'attaccante può richiedere con discrezione il TGS al server oppure floodarlo (inondarlo di richieste) in funzione delle circostanze e della propensione al rischio
• il controller di dominio verifica il TGT e risponde con un ticket TGS
• l'aggressore memorizza il ticket TGS offline e procede al cracking per ottenere la password dell'account di servizio e accedere alla risorsa di rete (in questo caso, il server delle applicazioni)

Si noti che Kerberos è inoltre attaccabile sfruttando il Pass-the-Ticket Attack o l'AS-REP Roasting, ma non soltanto.
Come precedentemente detto l'algoritmo di crittografia utilizzato è RC4_HMAC_MD5, ormai obsoleto e notoriamente vulnerabile, che, se utilizzato al posto di AES, permette all'attaccante di ottenere rapidamente e facilmente le credenziali dell'account di servizio, spesso senza dover effettuare ulteriori richieste, guadagnando l'accesso illimitato ai sistemi e alle risorse a cui l'account compromesso può accedere avendo i privilegi.
Una volta ottenuto l'accesso, l'aggressore può rapidamente elevare i propri privilegi (escalation privileges) o muoversi lateralmente (lateral movements) all'interno della rete dell'organizzazione, secondo strategia e obiettivi.
L'attacco kerberoasting è di tipo post-exploitation, richiede pertanto che l'aggressore abbia già ottenuto l'accesso alla rete aziendale tramite l'utilizzo di un utente di dominio legittimo, le cui credenziali possono essere ottenute in svariati modi che non tratteremo in questo articolo.

Alla luce di quanto detto, la necessità di esaminare e affrontare la questione della sicurezza delle infrastrutture IT in modo olistico piuttosto che frammentato è resa abbondantemente chiara ancora una volta, partendo dal presupposto che il 99% delle aziende utilizza Active Directory nelle proprie infrastrutture.
Dedurre che la stragrande maggioranza delle aziende possa essere vulnerabile all'attacco Kerberoasting non è molto complicato.

Come contrastare un attacco Kerberoasting.

È possibile implementare una serie di misure per disarticolare attacchi come Kerberoasting.
Tra gli obiettivi prioritari per l'attaccante c'è di certo quello di stabilire a quali account di servizio l'amministratore di sistema ha attribuito specifici privilegi e come sfruttarli. Quindi, se non sono richiesti, è preferibile, quando possibile, evitare di avere account privilegiati che possono eseguire servizi. Inoltre, qualora l'account non fosse stato creato per essere utilizzato al di fuori di Active Directory potrebbe essere indicato utilizzare Managed Service Accounts (MSA).
"Potrebbe" essere indicato solo perchè, purtroppo, sono note vulnerabilità già sfruttate anche in riferimento a MSA e gMSAs.
Gli account di servizio gestiti, abbreviati in MSA, hanno una password complessa gestita automaticamente che elimina la necessità di provvedere manualmente alla rotazione e alla messa in sicurezza. In Server 2012, questa funzione è stata implementata in Group Managed Service Accounts (gMSAs), che consente l'uso di questi account su più server contemporaneamente.
Utilizzare una password più lunga di 32 caratteri quando un account viene utilizzato al di fuori di Active Directory può senz'altro aiutare.
Ultimo ma non meno importante, che l'account utente deve essere impostato per supportare l'algoritmo AES, abbandonando definitivamente l'uso dell'obsoleto RC4.

In altre parole, proteggere l'infrastruttura IT di un'azienda richiede l'adozione di buone pratiche di sicurezza e strategie applicate da professionisti, che vanno ben oltre la semplice applicazione di patches ai sistemi.