Come spesso accade con Active Directory, alcune delle peggiori falle nella sicurezza sono causate da configurazioni errate che lasciano aperte le porte a potenziali minacce informatiche. Un'impostazione comune che i criminali informatici amano sfruttare è la delega non vincolata.
Che cos'è la delega non vincolata e perché la delega non vincolata è un rischio per la sicurezza? La delega è l'azione che consente a un computer di salvare i ticket di autenticazione Kerberos di un utente e di utilizzare tali ticket per impersonare l'utente e agire per suo conto. La delega senza vincoli è un'impostazione di configurazione che molte applicazioni web a più livelli richiedono per funzionare. Ma questa impostazione ha implicazioni per la sicurezza, in quanto un computer che memorizza le informazioni dei ticket Kerberos per un gruppo di utenti sarebbe un ovvio bersaglio per gli aggressori. Se gli aggressori riescono a impossessarsi di quei ticket, possono agire con l'identità e i privilegi di quegli utenti.
Se questa impostazione è così rischiosa, perché gli amministratori configurano i server con la delega non vincolata invece della tradizionale delega vincolata? Probabilmente perché nelle prime versioni dell'ambiente Active Directory era l'unica forma di delega supportata ed è anche la più semplice da configurare, in quanto richiede solo una singola casella di controllo. E se la configurazione della delega non vincolata fa funzionare l'applicazione, va bene, no? Ma c'è un'ottima ragione per rivedere questa impostazione. La rimozione della delega non vincolata elimina un anello debole nella catena dell'autenticazione fidata, che potrebbe causare danni significativi in caso di abuso.
Lettura correlata
Radici della delega non vincolata
Le radici di questo potenziale rischio per la sicurezza possono essere fatte risalire a 20 anni fa. Microsoft ha introdotto la delega non vincolata Kerberos in Windows Server 2000 per consentire ai servizi di accedere ad altri servizi per conto di un utente autenticato, in modo da non dover effettuare una nuova autenticazione. Ad esempio, se un utente si è autenticato a un server Web, questo può impersonare l'utente e accedere ai database di back-end senza che l'utente debba reinserire le proprie credenziali. Quando la delega non vincolata è abilitata su un account, questo può impersonare l'utente in qualsiasi servizio dello stesso dominio.
Se da un lato questa funzionalità semplificava la vita agli utenti (e agli amministratori), dall'altro presentava un rischio evidente. Se un server con delega non vincolata era sotto il controllo di soggetti minacciosi, questi potevano abusare di questa fiducia per ottenere un accesso diffuso in tutto l'ambiente. Microsoft ha cercato di mitigare questo rischio introducendo la delega vincolata in Windows Server 2003, che consentiva agli amministratori di dominio di limitare i servizi a cui un particolare server poteva accedere.
Con il rilascio di Windows Server 2012, Microsoft ha dato agli amministratori dei servizi il potere di decidere se i servizi front-end possono accedere alle risorse back-end. Prima di questa modifica, solo un amministratore di dominio poteva controllare i privilegi di delega, lasciando agli amministratori dei servizi un modo semplice per sapere quali servizi front-end potevano accedere alla risorsa di loro proprietà e, quindi, quali potenziali percorsi di attacco potevano essere aperti. Conosciuto come resource based constrained delegation (RBCD), questo approccio alla delega di Active Directory è il più difficile da abusare.
In confronto, la delega senza restrizioni è la meno sicura. Se gli aggressori riescono a sfruttare una delega Kerberos non sicura, possono mascherare ogni tipo di attività dannosa fingendo di essere un utente legittimo. Un attore malintenzionato con accesso a un server web con questa configurazione potrebbe rubare il Ticket Granting Ticket (TGT) dell’utente, memorizzato nella memoria del server, e utilizzarlo per impersonare quell’utente e sfruttare i suoi privilegi di accesso o ampliare l’accesso tramite l’escalation dei privilegi. Questa realtà rende la delega senza restrizioni un meccanismo ideale per il movimento laterale all’interno dell’ambiente. Un TGT appartenente a un amministratore di dominio, ad esempio, potrebbe consentire all’autore dell’attacco di accedere a qualsiasi servizio di sua scelta, oppure di accedere potenzialmente a un account KRBTGT e lanciare un attacco Golden Ticket.
Un malintenzionato può utilizzare il cmdlet Get-ADComputer del modulo PowerShell di Active Directory per individuare i computer su cui questa impostazione è abilitata e quindi passare all'azione. Può utilizzare, ad esempio, Mimikatz per estrarre tutti i ticket di servizio presenti nella memoria del sistema. Le conseguenze negative di questa situazione sono evidenti.
Migliorare la sicurezza di AD disabilitando la delega non vincolata
La buona notizia è che è possibile colmare la falla di sicurezza causata dalla delega senza restrizioni semplicemente disabilitando questa impostazione. Affinché la delega senza restrizioni abbia effetto, gli amministratori di dominio devono abilitarla per gli account selezionando l'opzione "Considera affidabile questo computer per la delega a qualsiasi servizio (solo Kerberos)" nella scheda "Delega " della console di gestione ADUC.
Data l’elevata criticità dell’abilitazione di questa impostazione, le organizzazioni possono migliorare il proprio livello di sicurezza identificando eventuali server su cui è abilitata la delega senza restrizioni, disabilitando l’impostazione e sostituendola con la delega con restrizioni per i server che ne necessitano. Gli account amministratore dovrebbero essere impostati su “L’account è sensibile e non può essere delegato”, mentre gli account con privilegi elevati dovrebbero essere inseriti nel gruppo di sicurezza “Utenti protetti”. Gli amministratori possono eseguire una scansione alla ricerca di foreste con relazioni di fiducia in entrata che consentono la delega TGT e di eventuali entità di sicurezza che consentono la delega senza restrizioni utilizzando gli script di PowerShell. È inoltre possibile rilevare la delega senza restrizioni esaminando gli eventi di Windows. Quando viene emesso un ticket Kerberos, un controller di dominio di Active Directory registra eventi di sicurezza contenenti informazioni sul dominio di destinazione. È possibile esaminare tali eventi per determinare se la delega senza restrizioni viene utilizzata nelle relazioni di fiducia in entrata. In alternativa, è possibile scaricare ed eseguire Purple Knight, uno strumento gratuito di valutazione della sicurezza sviluppato dagli esperti AD di Semperis che esegue una scansione dell’ambiente AD alla ricerca di oltre 80 indicatori di sicurezza, tra cui la delega senza restrizioni.
La disattivazione della delega non vincolata potrebbe causare problemi di compatibilità per alcune applicazioni che si basano su questa funzione, il che significa che dovrete riconfigurare tali applicazioni per utilizzare la delega vincolata o RBCD. Come sempre, le organizzazioni devono ricordare che la sicurezza dell'AD non si limita a correggere le vulnerabilità del codice. Prevenire gli attacchi significa anche adottare misure per ridurre la superficie di attacco e prevenire proattivamente i problemi prima che si presentino.
