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 conseguirem abusar de uma delegação Kerberos não segura, podem dissimular todo o tipo de atividade maliciosa, fazendo-se passar por um utilizador legítimo. Um agente malicioso com acesso a um servidor web com esta configuração poderia 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 tirar partido dos seus privilégios de acesso ou ampliar o acesso através da escalada 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 à sua escolha — ou, potencialmente, permitir-lhe aceder a uma conta KRBTGT e lançar um ataque «Golden Ticket».
Um atacante pode utilizar o cmdlet Get-ADComputer do módulo do Active Directory para o PowerShell para identificar computadores com esta configuração ativada e, em seguida, passar à ação. Pode, por exemplo, utilizar o Mimikatz para extrair todos os bilhetes de serviço da memória do sistema. As implicações negativas desta situação são evidentes.
Melhorar a segurança do AD desactivando a delegação sem restrições
A boa notícia é que pode colmatar a falha de segurança criada pela delegação sem restrições simplesmente desativando esta configuração. Para que a delegação sem restrições entre em vigor, os administradores do domínio têm de a ativar 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.
Dado o elevado risco associado à ativação desta configuração, as organizações podem melhorar a sua postura de segurança identificando quaisquer servidores com a delegação sem restrições ativada, desativando essa configuração e substituindo-a pela delegação com restrições nos servidores que assim o exijam. 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 «Utilizadores Protegidos». Os administradores podem procurar florestas com relações de confiança de entrada que permitam a delegação de TGT e quaisquer entidades de segurança que permitam a delegação sem restrições, utilizando os scripts do PowerShell. Também é possível detetar a delegação sem restrições através da análise dos 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. É possível analisar esses eventos para determinar se a delegação sem restrições está a ser utilizada nas relações de confiança de entrada. Ou pode descarregar e executar Purple Knight, uma ferramenta gratuita de avaliação de segurança desenvolvida 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 sem restrições.
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.
