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 non vincolata è la meno sicura. Se gli aggressori possono abusare di una delega Kerberos non sicura, possono mascherare ogni sorta di attività dannosa imitando un utente legittimo. Un attore minaccioso che abbia accesso a un server Web con questa configurazione potrebbe rubare il Ticket Granting Ticket (TGT) dell'utente, che è memorizzato nella memoria del server, e usarlo per impersonare l'utente e sfruttare i suoi privilegi di accesso o migliorare l'accesso attraverso l'escalation dei privilegi. Questa realtà rende la delega non vincolata un meccanismo ideale per il movimento laterale nell'ambiente. Un TGT appartenente a un amministratore di dominio, ad esempio, potrebbe dare all'attaccante l'accesso a qualsiasi servizio di sua scelta, o potenzialmente accedere a un account KRBTGT e lanciare un attacco Golden Ticket.
Un utente malintenzionato può utilizzare il cmdlet Get-ADComputer del modulo PowerShell di Active Directory per trovare i computer con questa impostazione abilitata e quindi mettersi al lavoro. Può utilizzare Mimikatz, ad esempio, per estrarre ogni ticket di servizio presente nella memoria del sistema. Le implicazioni negative sono evidenti.
Migliorare la sicurezza di AD disabilitando la delega non vincolata
La buona notizia è che è possibile colmare la lacuna di sicurezza creata dalla delega non vincolata semplicemente disabilitando questa impostazione. Affinché la delega non vincolata abbia effetto, gli amministratori di dominio devono abilitarla per gli account selezionando "Fidati di questo computer per la delega a qualsiasi servizio (solo Kerberos)" nella scheda Delega della console di gestione ADUC.
Data l'alta posta in gioco dell'attivazione di questa impostazione, le organizzazioni possono migliorare la loro sicurezza identificando tutti i server con delega non vincolata attivata, disabilitando l'impostazione e sostituendola con una delega vincolata per i server che la richiedono. Gli account amministrativi devono essere impostati su "L'account è sensibile e non può essere delegato" e gli account con privilegi elevati devono essere inseriti nel gruppo di sicurezza Utenti protetti. Gli amministratori possono analizzare le foreste con trust in entrata che consentono la delega TGT e tutti i principi di sicurezza che consentono la delega non vincolata utilizzando gli script PowerShell. È inoltre possibile rilevare una delega non vincolata esaminando gli eventi di Windows. Quando viene emesso un ticket Kerberos, un controller di dominio Active Directory registra eventi di sicurezza che contengono informazioni sul dominio di destinazione. È possibile esaminare questi eventi per determinare se la delega non vincolata è utilizzata nei trust in entrata. In alternativa, è possibile scaricare ed eseguire Purple Knight, uno strumento gratuito di valutazione della sicurezza realizzato dagli esperti AD di Semperis che analizza il vostro ambiente AD alla ricerca di oltre 80 indicatori di sicurezza, tra cui la delega non vincolata.
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.
