Este artigo explora o CVE-2022-26923, uma vulnerabilidade no Active Directory Certificate Service (AD CS) da Microsoft, que permite, que qualquer usuário do AD escale seus privilégios para o Administrador de Domínio em um único salto!

Pesquisas feitas e lançadas como whitepaper pela SpecterOps, mostraram que era possível explorar modelos de certificados, mal configurados para escalonamento de privilégios e movimentação lateral. Com base na gravidade da configuração incorreta, isso pode permitir que qualquer usuário com poucos privilégios no domínio do AD, aumente seu privilégio para um administrador de domínio corporativo com apenas alguns cliques.

Outras pesquisas foram realizadas por Oliver Lyak, que descobriu uma vulnerabilidade adicional (CVE-2022-26923) no Serviço de Certificados. Um patch foi lançado para a vulnerabilidade pela Microsoft em 10 de maio. Você pode ler mais sobre a pesquisa aqui.

Overview sobre Modelos de Certificados

O Windows Active Directory (AD) não serve apenas para gerenciamento de identidade e acesso, mas fornece uma quantidade significativa de serviços para ajudá-lo a executar e gerenciar sua organização. Muitos desses serviços são menos conhecidos ou usados, o que significa que, muitas vezes, são ignorados quando o reforço de segurança é executado. Um desses serviços é o Active Directory Certificate Services (AD CS).

Quando falamos de certificados, geralmente pensamos apenas nos mais comuns, como aqueles usados ​​para atualizar o tráfego do site para HTTPS. Mas eles geralmente são usados ​​apenas para aplicativos que a organização expõe à Internet. E quanto a todos aqueles aplicativos rodando na rede interna? Agora temos que dar a eles acesso à Internet para permitir que eles solicitem um certificado de uma Autoridade de Certificação (CA) confiável? Bem, na verdade não, graças ao AD CS.

AD CS é a implementação de infraestrutura de chave pública (PKI) da Microsoft. Como o AD fornece um nível de confiança em uma organização, ele pode ser usado como CA, para provar e delegar confiança. O AD CS é usado para várias coisas, como criptografar sistemas de arquivos, criar e verificar assinaturas digitais e até mesmo autenticação de usuários, tornando-se um caminho promissor para invasores. O que o torna um vetor de ataque ainda mais perigoso é que os certificados podem sobreviver à rotação de credenciais, ou seja, mesmo que a senha de uma conta comprometida seja redefinida, isso não fará nada para invalidar o certificado gerado de forma maliciosa, proporcionando roubo de credenciais persistente por até 10 anos! O diagrama abaixo mostra como é o fluxo de solicitações e geração de certificados (retirado do whitepaper SpecterOps):

Como o AD CS é uma função privilegiada, ele normalmente é executado em controladores de domínio selecionados. Isso significa que os usuários normais não podem interagir diretamente com o serviço. Por outro lado, as organizações tendem a ser grandes demais para que um administrador crie e distribua cada certificado manualmente. É aí que entram os modelos de certificado. Os administradores do AD CS podem criar vários modelos que permitem que qualquer usuário, com as permissões relevantes, solicite um certificado por conta própria. Esses modelos possuem parâmetros que informam qual usuário pode solicitar o certificado e o que é necessário. O que a SpecterOps descobriu foi que combinações específicas desses parâmetros podem ser incrivelmente tóxicas e ser abusadas para escalonamento de privilégios e acesso persistente!

Terminologia Relevante

• PKI – Public Key Infrastructure é um sistema que gerencia certificados e criptografia de chave pública
• AD CS – Active Directory Certificate Services é a implementação de PKI da Microsoft que geralmente é executada em controladores de domínio
• CA – Autoridade de Certificação é uma PKI que emite certificados
• Modelo de certificado – uma coleção de configurações e políticas que define como e quando um certificado pode ser emitido por uma CA
• CSR – Certificate Signing Request é uma mensagem enviada a uma CA para solicitar um certificado assinado
• EKU – Extended/Enhanced Key Usage são identificadores de objetos que definem como um certificado gerado pode ser usado

Explanação sobre a Vulnerabilidade CVE-2022-26923

Client Authentication

Conforme discutido na visão geral dos modelos de certificado, eles são convenientes para permitir que usuários e sistemas se inscrevam para obter certificados. Os certificados têm muitos casos de uso na rede. Para CVE-2022-26923 e as configurações incorretas de modelo descobertas pelo SpectorOps, o foco principal está no caso de uso de autenticação de cliente.

A autenticação do cliente permite que o proprietário do certificado o use para verificar sua própria identidade no AD para fins de autenticação. Por exemplo, um certificado de cliente é usado para autenticar em um aplicativo da web. O processo de autenticação ocorre por meio do Kerberos. Se tivermos um certificado válido que tenha o EKU de Autenticação de Cliente, podemos fazer interface com o AD CS e o Centro de Distribuição de Chaves para solicitar um Kerberos TGT que pode ser usado para autenticação adicional.

Como invasor, podemos aproveitar isso para gerar um TGT para representar outro usuário ou sistema, caso tenhamos um certificado válido para eles. Em essência, queremos poder modificar o atributo Subject Alternative Name (SAN) da solicitação de certificado para apontar para alguém ou outra coisa que tenha mais permissões para executar o escalonamento de privilégios.

Modelos Padrão de Certificados

Por padrão, quando o AD CS é instalado em um ambiente, dois modelos de certificado são disponibilizados para solicitações que dão suporte à autenticação de cliente:

• Modelo de Certificado de Usuário – Este modelo de certificado pode ser solicitado por qualquer usuário que pertença ao grupo Usuários do Domínio.
• Modelo de Certificado de Máquina – Este modelo de certificado pode ser solicitado por qualquer host que pertença ao grupo Computadores do Domínio.

O modelo de usuário não é vulnerável por padrão. Quando solicitamos um certificado com base no modelo de usuário, o nome principal do usuário (UPNs) da conta do usuário será incorporado na SAN que pode ser usado para identificação. Como os UPNs devem ser exclusivos e geralmente não temos a capacidade de modificar nosso UPN, não podemos aproveitar esse modelo. Além disso, como não podemos alterar o valor SAN na solicitação de assinatura de certificado, não podemos representar outro usuário especificando seu UPN.

No entanto, as contas de computador não têm um UPN. Em vez de usar um UPN para autenticação, o modelo de máquina usa o nome DNS da máquina para identificação e autenticação. Quando um certificado é solicitado para uma máquina por meio do modelo Máquina, o AD CS incorpora o nome DNS da máquina na SAN, que é usada para autenticação.

Privilégios Padrão para Usuários de Domínio

Por padrão, qualquer usuário que seja membro do grupo Usuários Autenticados (literalmente todas as contas do AD), pode registrar até 10 novas máquinas no domínio. Isso geralmente é usado em organizações para permitir que os usuários tragam seu próprio dispositivo (BYOD) e o registrem para uso no domínio. Isso em si não é realmente uma vulnerabilidade, mas levou a alguns vetores de escalação de privilégios interessantes no caminho, exatamente o que exploraremos para este CVE.

Quando inscrevemos um novo host no AD, somos designados como proprietários desse host. Isso nos fornece certas permissões sobre o objeto AD associado a esse ele. Duas permissões em particular causam um problema aqui:

• Validar gravação no nome do host DNS – Essa permissão nos permite atualizar o nome do host DNS do nosso objeto AD associado ao host.
• Validar gravação no nome principal de serviço (SPN) – essa permissão nos permite atualizar o SPN de nosso objeto AD associado ao host.

Os SPNs são usados ​​pela autenticação Kerberos para associar uma instância de serviço a uma conta de logon de serviço. Por padrão, o objeto AD do computador recebe SPNs associados ao seu nome para permitir a autenticação Kerberos, que o host requer para executar solicitações específicas no AD. Os SPNs devem ser exclusivos, o que significa que dois objetos do AD não podem ter o mesmo SPN.

Aparentemente é tão simples quanto alterar o nome do host DNS para outro nome de host, talvez o nome do host de um controlador de domínio para escalonamento de privilégios, certo? No entanto, se você alterar o nome do host DNS, a Microsoft atualizará automaticamente o atributo SPN. Como eles devem ser exclusivos, o sistema informará um erro se tentarmos representar outro host por meio do atributo DNS hostname. Mas como também temos a capacidade de alterar o SPN, podemos contornar essa restrição.

As peças do quebra-cabeça devem agora começar a se encaixar. Se tivéssemos apenas uma das duas permissões, não teríamos uma vulnerabilidade. No entanto, a combinação de ter essas duas permissões nos permite realizar o escalonamento de privilégios.

Juntando Tudo

Usando essas configurações (o modelo de certificado de máquina AD CS padrão, a capacidade padrão de registrar uma nova máquina e as permissões padrão atribuídas no objeto AD do computador criado), temos um vetor de escalonamento de privilégios em nossas mãos. O pior é que esse vetor de escalonamento de privilégios requer um esforço mínimo, o que significa que o nível de habilidade do invasor para explorar esse problema é bastante baixo. Os passos básicos são os seguintes:

1. Comprometa as credenciais de um usuário do AD com poucos privilégios.
2. Use essas credenciais para registrar um novo host no domínio.
3. Altere o atributo de nome de host DNS do Objeto AD do Computador para o de um host privilegiado, como um Controlador de Domínio.
4. Remova o SPN atribuído para contornar o problema de conflito de SPN exclusivo.
5. Solicite um certificado de máquina usando o modelo padrão.
6. Execute a autenticação Kerberos com o modelo recebido, agora como a conta de máquina privilegiada em vez de nossa conta de máquina falsa.

Explorando a Vulnerabilidade CVE-2022-26923

A máquina de testes é um controlador de domínio Windows 2012, rodando um serviço de SSH para facilitar a demonstração, e responde no hostname lundc.lunar.eruca.com e no IP 10.10.252.186.

A máquina atacante é um Kali Linux.

Configurando o DNS

Primeiro, precisamos configurar alguns valores de DNS, na máquina atacante, modificando o arquivo /etc/hosts com a entrada abaixo.

Testando a Geração de Certificados

Semelhante ao post do blog da SpectorOps, o Certipy é usado para a exploração. O Certipy é uma ferramenta ofensiva para enumeração e exploração de vulnerabilidades e configurações incorretas do AD CS. Ele se integra ao Impacket para algumas das explorações. Para mantermos a exploração isolada, é criado um ambiente virtual Python exclusivo para este fim.

Inicialmente, gera-se um certificado para o usuário AD com poucos privilégios, que já temos acesso (Nome de usuário=thm Senha=Senha1@) usando o modelo de certificado de usuário:

Pode-se verificar se este certificado é válido e se também pode ser usado para autenticação Kerberos através do Certipy:

O Certipy executa a autenticação com o certificado e usa o Impacket para recuperar o hash NTLM associado ao UPN especificado no certificado. Poderíamos, é claro, usar algo como Rubeus para solicitar um TGT e depois importá-lo com o Mimikatz para ataques, mas isso pelo menos prova que o certificado é válido e pode ser usado para autenticação Kerberos.

Adicionando Computador ao Domínio

É necessário adicionar um novo computador ao domínio para gerar um certificado de máquina. Felizmente, não é preciso adicionar um computador físico à rede. Para isso, usa-se o script addcomputer.py do Impacket, para simplesmente fazer parecer que se está adicionando um novo computador:

Parâmetros usados:

• lunar.eruca.com/thm:Password1@ – Precisamos fornecer credenciais válidas do AD para adicionar um novo computador.
• method – O método de autenticação. O LDAPS fará interface com o serviço LDAP no controlador de domínio.
• computer-name – O nome do computador. Isso pode ser escolhido livremente, desde que não seja o mesmo nome de um objeto de computador existente.
• computer-pass – A senha associada à conta de máquina do computador.

Primeiro, gera-se um certificado para o novo computador criado. Para usar a conta de máquina do referido computador, é preciso adicionar um “$” no final do nome:

Novamente, pode-se verificar se o certificado é válido usando o Certipy:

Podemos verificar o hash NTLM recuperado em relação à senha que definimos para a conta da máquina usando um Gerador NTLM.

Atualizando Hostname e Atributos SPN

Para atualizar os atributos do objeto AD, usaremos os cmdlets AD-RSAT PowerShell. O controlador de domínio disponibilizado para o teste é acessado por SSH.

Uma vez conectado, inicia-se o Poweshell:

Obtendo os atributos atuais do objeto AD do computador adicionado, usando o cmdlet Get-ADComputer:

Podemos ver que tanto o nome do host DNS quanto os atributos SPN estão definidos para corresponder ao nome do computador adicionado. Vamos tentar atualizar o atributo do nome do host DNS para o do DC usando o cmdlet Set-ADComputer:

Como podemos ver na saída, a Microsoft altera automaticamente o atributo SPN quando definimos o nome do host DNS. Como já existe um SPN para LUNDC, o comando falha. Para mitigar isso, primeiro remove-se o atributo SPN atual:

Sem erro desta vez. Em seguida, verifica-se se as alterações foram feitas:

Perfeito! Simplesmente removendo os SPNs, a Microsoft não tenta mais alterá-los quando alteramos o nome de host DNS, o que significa que se pode alterá-lo para o nome de host DNS de um host legítimo.

Forjando um Certificado Malicioso

Hora de regenerar alguns certificados! Voltando a máquina de ataque, executa-se o mesmo comando do Certipy novamente, para solicitar um novo certificado para o computador:

Desta vez nota-se algo diferente. Apesar de ser solicitado um certificado para THMPC, obtém-se um certificado para LUNDC. Verifica-se se este certificado está funcionando e retornando o hash NTLM da conta da máquina LUNDC:

Temos oficialmente o hash NTLM para a conta de máquina da LUNDC! Como o LUNDC é um controlador de domínio e temos acesso administrativo ao DC, comprometemos totalmente o domínio em pouco passos!

Mitigações e Correções

Para se defender contra o CVE-2022-26923, o melhor curso de ação é aplicar o patch lançado pela Microsoft:

• Um novo Object ID (OID) foi introduzido em novos certificados para imprimir ainda mais a impressão digital do usuário. Isso é feito incorporando o objectSid do usuário no novo OID szOID_NTDS_CA_SECURITY_EXT.
• A permissão “Validated write to DNS hostname” agora só permite que você defina o DNSHostname para um atributo que corresponda ao nome da conta SAM ou à conta do computador, o que significa que não pode ser usado para falsificar o nome da conta de outros hosts.

Junto com isso, existem algumas outras medidas de segurança que você pode tomar:

• Certifique-se de que seus modelos de certificado sejam restritos. Permita o registro automático de Máquina e Usuário apenas se for necessário. Caso contrário, por meio da configuração de segurança, as permissões para esses modelos podem ser reduzidas.
• Se não houver nenhum caso de negócios para permitir que os usuários registrem hosts no AD, altere o atributo MS-DS-Machine-Account-Quota para 0 em todas as contas que não devem ter a capacidade de registrar novos hosts. No entanto, isso não resolverá o problema, pois um invasor só precisa obter acesso administrativo em um único host associado a um domínio para poder realizar uma solicitação de certificado.

Como a EximiaCo pode lhe ajudar

Neste artigo, mostramos um possível método para explorar o CVE-2022-26923. Como mencionado anteriormente, este é um dos novos CVEs que vieram à tona no AD Certificate Service da Microsoft. Existem outros problemas, como combinações de parâmetros tóxicos que nem são classificados como CVEs e que podem ser usados para escalonamento de privilégios. Leia o whitepaper SpecterOps se estiver interessado em saber mais.

Caso você tenha dúvidas sobre as vulnerabilidades presentes em seu ambiente, conheça nossa Consultoria e Assessoria em Gestão da Segurança da Informação para conversarmos a respeito e ajudarmos você a tornar seu negócio mais seguro.