Tal como acontece frequentemente com o Active Diretory, algumas das piores falhas de segurança são causadas por configurações incorrectas que deixam portas abertas a potenciais ciberameaças. Uma configuração comum que os cibercriminosos adoram explorar é a delegação sem restrições.
O que é a delegação sem restrições e porque é que a delegação sem restrições é um risco de segurança? A delegação é a ação de permitir que um computador guarde os bilhetes de autenticação Kerberos de um utilizador e, em seguida, utilize esses bilhetes para se fazer passar pelo utilizador e agir em seu nome. A delegação sem restrições é uma definição de configuração que muitas aplicações Web de vários níveis necessitam para funcionar. Mas a definição tem implicações de segurança, uma vez que um computador que armazena a informação dos bilhetes Kerberos para um conjunto de utilizadores seria um alvo óbvio para os atacantes. Se os atacantes conseguirem obter esses bilhetes, podem agir com a identidade e os privilégios desses utilizadores.
Se esta definição é tão arriscada, porque é que os administradores configuram os servidores com delegação sem restrições em vez da tradicional delegação com restrições? Provavelmente porque nas primeiras versões do ambiente do Active Diretory, esta era a única forma de delegação suportada e é também a mais fácil de configurar, exigindo apenas uma única caixa de verificação. E se a configuração da delegação sem restrições faz com que a aplicação funcione, está tudo bem, certo? Mas há, de facto, uma excelente razão para rever esta definição. A remoção da delegação irrestrita elimina um elo fraco numa cadeia de autenticação fiável que pode causar danos significativos se for utilizada de forma abusiva.
Leitura relacionada
Raízes da delegação sem restrições
As raízes deste potencial risco de segurança remontam a 20 anos atrás. A Microsoft introduziu a delegação sem restrições Kerberos no Windows Server 2000 para permitir que os serviços acedam a outros serviços em nome de um utilizador autenticado, para que não tenham de se autenticar novamente. Por exemplo, se um utilizador se autenticou num servidor Web, esse servidor Web pode fazer-se passar pelo utilizador e aceder a bases de dados back-end sem que o utilizador tenha de voltar a introduzir as suas credenciais. Quando a delegação sem restrições está activada numa conta, esta pode fazer-se passar pelo utilizador para qualquer serviço no mesmo domínio.
Embora esta funcionalidade facilitasse a vida aos utilizadores (e administradores), também apresentava um risco óbvio. Se um servidor com delegação ilimitada activada estivesse sob o controlo de agentes de ameaças, estes poderiam abusar desta confiança para obter acesso generalizado a todo o ambiente. A Microsoft procurou atenuar este risco introduzindo a delegação restrita no Windows Server 2003, que permitia aos administradores de domínio restringir os serviços a que um determinado servidor podia aceder.
Com o lançamento do Windows Server 2012, a Microsoft deu aos administradores de serviços o poder de decidir se os serviços de front-end podiam aceder a recursos de back-end. Antes desta alteração, apenas um administrador de domínio podia controlar os privilégios de delegação, deixando os administradores de serviços sem uma forma fácil de saber que serviços front-end podiam aceder ao recurso que possuíam e, por conseguinte, que potenciais caminhos de ataque poderiam estar abertos. Conhecida como delegação restrita baseada em recursos (RBCD), esta abordagem à delegação do Active Diretory é a mais difícil de abusar.
Em comparação, a delegação sem restrições é a menos segura. Se os atacantes puderem abusar de uma delegação Kerberos não segura, podem mascarar todo o tipo de atividade maliciosa imitando um utilizador legítimo. Um agente de ameaça com acesso a um servidor Web com esta configuração pode roubar o Ticket Granting Ticket (TGT) do utilizador, que está armazenado na memória do servidor, e utilizá-lo para se fazer passar por esse utilizador e aproveitar os seus privilégios de acesso ou melhorar o acesso através do aumento de privilégios. Esta realidade torna a delegação sem restrições um mecanismo ideal para o movimento lateral em todo o ambiente. Um TGT pertencente a um administrador de domínio, por exemplo, poderia dar ao atacante acesso a qualquer serviço de sua escolha - ou potencialmente acessar uma conta KRBTGT e lançar um ataque Golden Ticket.
Um atacante pode utilizar o cmdlet Get-ADComputer do módulo PowerShell do Active Diretory para encontrar computadores com esta definição activada e depois começar a trabalhar. Pode usar o Mimikatz, por exemplo, para extrair todos os tickets de serviço na memória do sistema. As implicações negativas deste facto são claras.
Melhorar a segurança do AD desactivando a delegação sem restrições
A boa notícia é que pode colmatar a lacuna de segurança criada pela delegação sem restrições, desactivando simplesmente esta definição. Para que a delegação sem restrições tenha efeito, os administradores de domínio têm de a activar para as contas, marcando a opção "Confiar neste computador para delegação a qualquer serviço (apenas Kerberos)" no separador Delegação da consola de gestão do ADUC.
Tendo em conta os elevados riscos de activar esta definição, as organizações podem melhorar a sua postura de segurança identificando quaisquer servidores com a delegação irrestrita activada, desactivando a definição e substituindo-a por uma delegação restrita para os servidores que a requerem. As contas de administrador devem ser definidas como "A conta é sensível e não pode ser delegada" e as contas com privilégios elevados devem ser colocadas no Grupo de Segurança de Utilizadores Protegidos. Os administradores podem procurar florestas com fidedignidades de entrada que permitam a delegação de TGT e quaisquer princípios de segurança que permitam a delegação sem restrições utilizando os scripts do PowerShell. Também é possível detectar a delegação sem restrições examinando os eventos do Windows. Quando é emitido um bilhete Kerberos, um controlador de domínio do Active Directory regista eventos de segurança que contêm informações sobre o domínio de destino. Pode examinar esses eventos para determinar se a delegação sem restrições está a ser utilizada em relações de confiança de entrada. Ou pode descarregar e executar Purple Knightuma ferramenta de avaliação de segurança gratuita criada por especialistas em AD da Semperis que analisa o seu ambiente AD em busca de mais de 80 indicadores de segurança, incluindo a delegação irrestrita.
A desactivação da delegação sem restrições pode causar problemas de compatibilidade em algumas aplicações que dependem desta funcionalidade, o que significa que terá de reconfigurar essas aplicações para utilizarem a delegação com restrições ou o RBCD. Como sempre, as organizações precisam de se lembrar que a segurança do AD inclui mais do que apenas corrigir vulnerabilidades de código. Prevenir ataques também significa tomar medidas para reduzir a superfície de ataque e prevenir proactivamente os problemas antes que estes surjam.
