Índice
Equipa de investigação da Semperis

Em 10 de Maio de 2022, foi divulgada e corrigida uma vulnerabilidade no Active Directory (AD) e nos Serviços de Certificados do Active Directory (AD CS). Esta vulnerabilidade do AD pode levar a um aumento de privilégios. Nas instalações predefinidas do AD CS, um utilizador com poucos privilégios pode explorar a vulnerabilidade solicitando um certificado de autenticação e, em seguida, utilizando esse certificado para se fazer passar por outra conta de computador, o que resulta numa tomada de controlo total do domínio. De que trata esta vulnerabilidade do AD? Continue a ler para obter um guia completo sobre a CVE-2022-26923.

O que é que leva a esta vulnerabilidade do AD?

O AD foi lançado pela primeira vez em 1999 pela Microsoft como um sistema centralizado de gestão de identidades que consiste num conjunto de processos e serviços. O AD contém vários protocolos que podem ser utilizados para autenticação e autorização de identidades numa empresa. Geralmente, o AD é utilizado para gerir facilmente utilizadores, grupos e computadores dentro de uma empresa. Desde então, o AD tornou-se o sistema de gestão de identidades mais popular, utilizado para gerir as identidades na grande maioria das empresas.

No Windows Server 2008, a Microsoft introduziu o AD CS, que permitiu criar e gerir facilmente certificados de Infra-estrutura de Chave Pública (PKI). Estes certificados podem ser utilizados para assinatura digital, protecção de protocolos e autenticação.

Quando os certificados do AD CS são utilizados para autenticação num ambiente AD (PKINIT), são abertos muitos novos caminhos de ataque, incluindo configurações incorrectas e vulnerabilidades. Em Junho de 2021, Will Schroeder e Lee Christensen publicaram um whitepaper que detalhava várias configurações incorrectas que podem resultar no aumento de privilégios. Algumas destas configurações incorrectas estavam predefinidas no AD CS aquando da instalação e podem levar à tomada de controlo total do domínio. Estas configurações incorrectas são independentes da vulnerabilidade descrita nesta publicação.

Leitura relacionada

Escalonamento de privilégios com a vulnerabilidade CVE-2022-26923 do AD

CVE-2022-26923 é uma vulnerabilidade de escalonamento de privilégios descoberta por Oliver Lyak. A exploração baseia-se em duas acções principais:

  1. Alteração da conta de computador dNSHostName para coincidir com o de outra conta de computador.
  2. Pedido de um certificado para a conta de computador, utilizando um modelo configurado com a opção SubjectAltRequireDns

O sinalizador SubjectAltRequireDns para modelos de certificado significa que os certificados solicitados utilizando este modelo têm um certificado Subject que corresponde ao atributo dNSHostName da conta AD requerente.

Estas duas acções são possíveis numa instalação predefinida do AD e do AD CS.

Ao solicitar um certificado utilizando uma conta de computador que tenha o mesmo dNSHostName que outra conta de computador, os atacantes podem autenticar-se como a conta de computador de destino e aumentar os privilégios. Esta vulnerabilidade pode ser utilizada para atingir qualquer computador activo no AD.

Alterar a conta da máquina dNSHostName

Numa instalação predefinida do AD, qualquer utilizador autenticado pode adicionar contas de máquina. Esta acção é regida pelas seguintes definições:

  • Os Adicionar estações de trabalho ao domínio na política do Controlador de Domínio, que define a quem são concedidos privilégios para adicionar contas de computador ao domínio (definido como Utilizadores Autenticados por predefinição; Figura 1)
"Direito de utilizador "Adicionar estações de trabalho ao domínio
Figura 1
  • A ms-DS-MachineAccountQuota no cabeçalho do contexto de nomeação (NC), que define o número de contas de computador que os utilizadores pouco privilegiados estão autorizados a adicionar (definido para 10 por defeito; Figura 2)
atributo ms-DS-MachineAccountQuota
Figura 2

Com estas predefinições, qualquer conta com poucos privilégios pode criar facilmente até 10 contas de computador no domínio, utilizando o cmdlet New-MachineAccount do Powermadpara adicionar uma conta de computador com o nome LowPrivComputer(Figura 3).

Adicionar contas de computador
Figura 3

A Lista de Controlo de Acesso Discricionário (Dacl) para esta nova conta de computador mostra que a conta do criador tem a permissão de escrita validada no nome de anfitrião DNS(Figura 4).

Validado para escrever na permissão de nome de anfitrião DNS
Figura 4

Por conseguinte, o atributo dNSHostName pode ser modificado pela mesma conta que o criou, utilizando simplesmente o cmdlet Set-DomainObject do PowerView(Figura 5).

Figura 5: Modificar DNShostname
Figura 5

Modelo de certificado com o sinalizador SubjectAltRequireDns

Numa instalação predefinida do AD CS, vários modelos de certificado têm o sinalizador SubjectAltRequireDns definido. Por exemplo, o modelo Máquina é utilizado por predefinição para registar contas de computador para autenticação de certificados. O cmdlet Get-DomainCertificateTemplate do PowerView é utilizado para ver o atributo msPKI-Certificate-Name-Flag do modelo Máquina(Figura 6).

Modelo de certificado
Figura 6

Utilizando a conta de máquina criada anteriormente, é possível pedir um certificado utilizando este modelo para a conta LowPrivComputer com o dnshostname modificado(somethingelse.f105-d01.lab). Para o efeito, é utilizada a ferramenta Python Certipy(Figura 7).

Pedir um certificado
Figura 7

Abusos da vulnerabilidade CVE-2022-26923 do AD

Como já foi referido, este método pode ser utilizado para aumentar os privilégios num domínio AD. Um caminho de ataque comum é visar um controlador de domínio (DC). Depois de criar a conta de computador(LowPrivComputer), os atacantes alteram primeiro o atributo dNSHostName da conta para o mesmo que o DC(F105-D02-DC01.f105-d01.lab), como se mostra na Figura 8.

Direccionar um DC - vulnerabilidade do AD
Figura 8

Para este caminho de ataque, o conteúdo do servicePrincipalName (SPN) precisa de ser limpo. Quando o atributo dNSHostName é actualizado, quaisquer entradas SPN são também actualizadas para corresponder ao novo nome. Isto entra em conflito com as entradas SPN para a conta genuína(F105-D01-DC01), e a alteração falha.

Após a alteração do dNSHostName, pode ser solicitado um certificado para este novo nome(Figura 9).

Certificado solicitado para novo nome - vulnerabilidade do AD
Figura 9

Depois de o certificado ser recuperado, o dNSHostName tem de ser novamente alterado(Figura 10) para que, quando o certificado for utilizado e o DC procurar o nome do cliente, haja apenas uma correspondência (a conta DC genuína).

Alterar novamente o dNSHostName - vulnerabilidade do AD
Figura 10

Agora, é possível autenticar como a conta do computador DC. O Rubeus fornece uma opção /getcredentials para o comando asktgt que usa uma solicitação de usuário para usuário (U2U). Quando um certificado é fornecido para autenticação, o hash NT das contas solicitantes pode ser recuperado devido aos dados da credencial NTLM_SUPPLEMENTAL_CREDENTIAL PAC PAC_INFO_BUFFER(Figura 11).

/getcredentials muda para o comando asktgt
Figura 11

Este hash NT pode ser utilizado para autenticação adicional como o DC (utilizando pass-the-hash ou overpass-the-hash) ou os Silver Tickets podem ser falsificados.

Variações da trajetória de ataque

Para além do caminho de ataque mostrado nos exemplos anteriores, podem ser utilizadas várias variações ligeiras para explorar esta vulnerabilidade do AD.

Em primeiro lugar, um atacante com algum controlo sobre um objecto informático existente não necessita da capacidade de criar uma conta de computador. A Figura 12 mostra que a conta de utilizador com poucos privilégios tem a capacidade de GenericWrite sobre o objecto de computador DatabaseServer.

Permissão GenericWrite
Figura 12

Com este privilégio, um atacante pode limpar os SPNs e alterar o atributo dNSHostName para corresponder ao de outra conta de computador(Figura 13).

Alterar o dNSHostName para corresponder a outra conta
Figura 13

Há dois aspectos que merecem ser assinalados:

  • Um sistema não-DC está a ser visado. Esta vulnerabilidade pode ser utilizada para atingir qualquer sistema ligado a um domínio, não apenas DCs.
  • Esta parte do ataque pode ser executada em DCs totalmente actualizados. Quando a conta que efectua a alteração tem permissões específicas GenericAll ou GenericWrite, o dNSHostName pode ser modificado para corresponder ao pertencente a outra conta de computador. (Isto não é possível quando a permissão Validated write to DNS host name é concedida ao criador de uma conta de computador).

Com o dNSHostName alterado, pode ser solicitado um certificado utilizando o nome do anfitrião DNS de destino(Figura 14).

Pedido de certificado
Figura 14

Com o dNSHostName alterado novamente, como no caminho de ataque anterior, o atacante pode agora usar o certificado adquirido para se autenticar como a conta do computador de destino.

Outra diferença entre a trajetória de ataque anterior e esta: o atacante não precisa de utilizar o certificado para se autenticar no Kerberos e solicitar um pedido Ticket Granting Ticket (TGT) para a conta alvo. O atacante pode utilizar o certificado para se autenticar diretamente em alguns serviços. O exemplo seguinte utiliza o certificado para se ligar diretamente ao LDAP e configurar a delegação restrita baseada em recursos (RBCD) no objeto de computador de destino (Figura 15).

Ligação ao LDAP
Figura 15

Note que a configuração do RBCD é apenas um exemplo do que um atacante pode fazer ao utilizar o certificado para autenticar directamente nos serviços. O WinRM, o RDP e o IIS suportam a autenticação de clientes utilizando certificados, pelo que existem muitas mais possibilidades. Outras acções, como a configuração de credenciais sombra, podem ser executadas através de LDAP, dependendo do ambiente e das permissões da conta de computador comprometida.

Para concluir o percurso do ataque, o atacante pode utilizar a extensão Kerberos Service-for-User (S4U) para obter um bilhete de serviço para o sistema alvo como utilizador administrativo (desde que o utilizador administrativo não tenha sido protegido contra a delegação), como se mostra na Figura 16 e na Figura 17.

Finalizar o caminho de ataque (1)
Figura 16
Finalizar o caminho de ataque (2)
Figura 17

O atacante pode utilizar o bilhete de serviço resultante para aceder ao serviço no sistema alvo como utilizador personificado. Uma boa demonstração é utilizar o WinRM/PowerShell Remoting para produzir o valor de "whoami", que requer um bilhete de serviço para o serviço HTTP no sistema alvo(Figura 18).

Utilização da ficha de serviço
Figura 18
ServicePrincipalNames

Para ambos os caminhos de ataque demonstrados, os SPNs precisavam de ser limpos antes de alterar o dNSHostName. Isto pode parecer um requisito difícil para a exploração da vulnerabilidade, mas não é. Usando o protocolo MS-SAMR para criar uma conta de computador usando o método SamrCreateUser2InDomain, um atacante pode criar uma conta de computador sem nenhum SPN, simplesmente usando o script de exemplo addcomputer.py do impacketpara criar uma conta de computador chamada NoSPNComputer (Figura 19).

Utilização do MS-SAMR
Figura 19

A conta de computador resultante não tem SPNs e não requer que estes sejam limpos (ver Figura 20).

Sem SPNs
Figura 20

Factores atenuantes

Restringir a capacidade de utilizadores com poucos privilégios criarem contas de máquina, definindo o atributo ms-DS-MachineAccountQuota na cabeça NC para 0 ou alterando o direito de utilizador Adicionar estações de trabalho ao domínio na política do Controlador de Domínio para um grupo específico em vez de Utilizadores Autenticados, reduz os caminhos de ataque viáveis para esta vulnerabilidade. Outras acções para reduzir o potencial de exploração:

  • Altere todos os modelos de certificado de "DNS name" para algo como "User principal name (UPN)"(Figura 21).
Alterar o nome do modelo
Figura 21
  • Configure os modelos de certificado para exigir a aprovação do gestor para o registo(Figura 22).
Configurar a aprovação para o registo
Figura 22

DSP detecção desta vulnerabilidade do AD

Como este exploit inclui apenas duas acções obrigatórias, a Semperis Directory Services Protector (DSP) tem duas oportunidades para o detectar:

  • Quando ocorre a alteração do dNSHostName
  • Quando o certificado é solicitado

DSP já recolhe os dados de alteração do AD, pelo que a escolha óbvia é detectar uma tentativa de explorar esta vulnerabilidade quando o dNSHostName é alterado. O indicador DSP faz isto primeiro monitorizando uma alteração ao atributo dNSHostName de uma conta de computador.

Quando tal alteração é detectada, DSP efectua uma consulta LDAP a todas as contas de computador com esse valor dNSHostName, excluindo o nome distinto (DN) do objecto da conta que desencadeou a consulta LDAP. DSP assinala cada resultado como um indicador de compromisso (IoC). Esse sinalizador deve detectar qualquer tentativa de explorar essa vulnerabilidade, independentemente de o ataque completo ter sido bem-sucedido. Conforme mostrado na Figura 23, o IoC retorna informações que incluem:

  • A conta que efectuou a alteração
  • Os DNs de ambas as contas de computador envolvidas
  • O dNSHostName original da conta cujo atributo foi alterado
  • O atributo dNSHostName da conta que está a ser visada
DSP bandeiras
Figura 23

Outras detecções do CVE-2022-26923

Vários eventos relevantes do Windows podem também ser utilizados para ajudar a identificar tentativas de exploração desta vulnerabilidade.

Compensação de SPNs

Quando um caminho de ataque requer a limpeza dos SPNs da conta de computador utilizada no ataque, é criado um evento 5136 para cada um dos SPNs configurados com o tipo de operação Value Deleted(Figura 24).

5136 eventos
Figura 24

Alterar o dNSHostName

Quando o atributo dNSHostName é alterado, é criado um evento 4742(Figura 25).

"Direito de utilizador "Adicionar estações de trabalho ao domínio
Figura 25

A secção Atributos alterados deste evento mostra o novo valor do Nome do anfitrião DNS(Figura 26).

Novo valor do nome do anfitrião DNS
Figura 26

Juntamente com o evento 4742, são criados dois eventos 5136. O primeiro mostra o valor dNSHostName original e é do tipo de operação Value Deleted(Figura 27).

Valor eliminado
Figura 27

A segunda mostra o novo valor dNSHostName e é do tipo de operação Value Added(Figura 28).

Valor acrescentado
Figura 28

Criação de computadores sem SPNs

Como mencionado anteriormente, os atacantes podem criar contas de computador sem nenhum SPN inicial usando o MS-SAMR. Quando o fazem, é criado um evento 4741(Figura 29).

4741 evento
Figura 29

Na secção Attributes (Atributos ) deste evento, os Service Principal Names (Nomes do Responsável pelo Serviço) estão vazios, como mostra a Figura 30.

Nomes de directores de serviços vazios
Figura 30

Pedir certificado

Quando um certificado é solicitado, é criado um evento 4887 na autoridade de certificação (CA). Este evento mostra o nome da conta requerente(Requester). O valor do atributo dNSHostName é apresentado como o Assunto(Figura 31).

Pedido de conta
Figura 31

Correção de vulnerabilidades do AD

Foi lançada uma correção para esta vulnerabilidade como parte das atualizações de segurança de maio de 2022. Esta correção introduziu algumas alterações:

  • As contas com a permissão Validated write to DNS host name já não conseguem alterar o atributo dNSHostName para corresponder ao de outra conta em DCs com patch. As tentativas de o fazer resultam numa violação de restrição (Figura 32).
Violação de restrições
Figura 32

Nota: Como mencionado anteriormente, mesmo após esta correcção, os atacantes podem alterar o atributo dNSHostName de uma conta de computador para corresponder ao de outra conta de computador, mesmo que essa acção exija agora permissões mais elevadas, como GenericAll/GenericWrite.

  • Os certificados solicitados às ACs corrigidas contêm o novo OID szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2.1)(Figura 33).
Novo OID
Figura 33

Este campo contém uma cadeia ASCII (em hexadecimal) do SID da conta que solicitou o certificado. Quando um certificado utilizado para tirar partido desta vulnerabilidade é utilizado para autenticar contra um CD corrigido, é devolvido um erro CERTIFICATE_MISMATCH(Figura 34).

Erro devolvido
Figura 34

Nota: Se este certificado for utilizado para autenticar um DC não corrigido, a autenticação será bem sucedida e a vulnerabilidade poderá ser explorada(Figura 35). Por conseguinte, é muito importante actualizar todos os DCs e CAs com o patch relevante.

Utilizar um certificado não corrigido
Figura 35

Saiba mais

Para saber mais sobre esta vulnerabilidade do AD e como proteger a sua organização, consulte as seguintes referências e recursos.

Recursos

Saiba mais sobre o Directory Services Protector (DSP) da Semperis

"Saiba mais sobre Purple Knight, a ferramenta de avaliação da segurança do Active Directory"

Referências