AD Certificate Services: Configurações de Risco e Sua Remediação

Os Serviços de Certificados do Active Directory existem há muito tempo, mas os recursos para aprendê-lo não são ótimos. Como resultado, muitas vezes apresentam configurações incorretas que são um vetor crescente para ataques. Na verdade, SpecterOps lançou um whitepaper detalhando uma série de configurações incorretas e ataques potenciais e fornecendo conselhos para reforço da segurança. Neste blog, eu cubro várias das configurações que podem estar mal configuradas e como identificá-las, ofereço várias opções para aumentar ainda mais a segurança e explico como usar uma ferramenta gratuita para verificar seu ambiente.

Contexto

Quando um certificado baseado em autenticação é emitido para uma identidade, o certificado pode ser utilizado para autenticar como a identidade definida no Nome Alternativo do Assunto (SAN); geralmente, trata-se de um UPN ou nome DNS. O certificado é então utilizado em vez de uma senha para autenticação inicial. A referência técnica para esta autenticação inicial é RFC4556 se você deseja descobrir mais detalhes.

Uma vez que um certificado baseado em autenticação tenha sido emitido, ele pode ser usado para autenticar como o sujeito até que seja revogado ou expire. Isso irá contornar planos de resposta a incidentes que dependem de estratégias como redefinir a senha do usuário para expulsar um invasor; o invasor pode ter acesso persistente à conta a menos que os certificados também sejam revogados.

Configurações de Modelo de Risco

Aqui estão algumas das configurações de modelo de certificado que podem levar a configurações incorretas.

EKUs baseadas em autenticação

Primeiro, procure por Usos de Chave Aprimorados (EKUs) que permitam qualquer tipo de autenticação em nível de domínio. Aqui está uma breve lista:

• Qualquer Propósito (2.5.29.37.0)
• SubCA (Nenhum)
• Autenticação de Cliente (1.3.6.1.5.5.7.3.2)
• Autenticação de Cliente PKINIT (1.3.6.1.5.2.3.4)
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

A maneira mais fácil de encontrar manualmente todos os seus modelos de certificado que permitem isso é abrir o snap-in MMC da Autoridade de Certificação, conectar-se à sua Autoridade de Certificação, olhar para a seção Modelo de Certificado e examinar a Coluna de Finalidade Pretendida em busca de qualquer uma dessas EKUs de autenticação. Por exemplo, a figura abaixo mostra que os modelos de Computador, Cópia de Logon de Smartcard e ambos os modelos de Controlador de Domínio contêm pelo menos uma das PKUs.

Depois de tratar os modelos que encontrar, certifique-se de ter em mente que também existem maneiras de abusar de certificados normais. Por exemplo, a função Get-SmartCardCertificate do PoshADCS pode modificar um modelo, solicitar certificados para ele e depois reverter as alterações feitas no modelo.

“Sinalizador de Assunto de Suprimentos do Inscrito”

Quando a flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT está presente na propriedade mspki-certificate-name-flag, o inscrito do certificado pode fornecer seu próprio Nome de Assunto alternativo na solicitação de assinatura do certificado. Isso significa que qualquer usuário que tenha permissão para se inscrever em um certificado com essa configuração pode solicitar um certificado como qualquer usuário na rede, incluindo um usuário privilegiado.

Você pode verificar essa opção na console de Template de Certificado; está na aba de Nome do Assunto como a opção de rádio “Fornecer na solicitação”:

Alternativamente, você pode usar um comando PowerShell como o seguinte para obter os modelos do AD e verificar se a flag está configurada no certificado:

      Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
      

Reduzindo ainda mais o risco

Além de corrigir as más configurações de certificados, considere usar as seguintes opções para controlar a emissão de certificados.

Aprovação do Gerenciador de Certificados CA ou Assinaturas Autorizadas

Primeiro e provavelmente mais importante, verifique a aba de Requisitos de Emissão em cada certificado para ver se é necessária a aprovação do gerente da Autoridade Certificadora (CA) ou de um ou mais autorizados.

Habilitar uma ou ambas as configurações pode reduzir significativamente o risco ao exigir verificações antes da emissão dos certificados. Se você não tem certeza sobre exigir assinaturas autorizadas, exija pelo menos a aprovação do gerente de certificados da CA; assim, toda vez que um certificado for solicitado, ele será enviado para a Autoridade Certificadora para revisão manual antes de ser emitido.

Permissões de Inscrição

Em segundo lugar, verifique as permissões de inscrição em cada modelo, que podem ser encontradas na aba Segurança. Muitas configurações incorretas são críticas apenas quando princípios genéricos ou grandes grupos têm essas permissões. Em particular, verifique se há Usuários Autenticados, Usuários do Domínio e qualquer grande grupo de usuários que não deveriam poder solicitar certificados; se você encontrá-los, considere revogar suas permissões de Inscrição ou Autoinscrição.

Chave de Registro EDITF_ATTRIBUTESUBJECTALTNAME2

Por último, verifique a configuração do registro EDITF_ATTRIBUTESUBJECALTNAME2. Esta configuração é uma das mais interessantes: se estiver habilitada na CA, então qualquer certificado baseado em autenticação que for emitido (incluindo certificados onde o sujeito é automaticamente construído a partir do Active Directory) pode ter valores definidos pelo usuário no SAN.

Para verificar esta configuração, você pode executar este comando:

      certutil –getreg policyEditFlags
      

Se EDITF_ATTRIBUTESUBJECALTNAME2 estiver na lista de saída, você deve removê-lo usando este comando:

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

Mais orientações sobre essa configuração podem ser encontradas aqui.

Verificando configurações de risco usando PSPKIAudit

The PSPKIAudit tool can help you audit your PKI infrastructure. To use PSPKIAudit, simply download the tool from GitHub, import the module and run the Invoke-PKIAudit command. This will enumerate the Certificate Authority from Active Directory and then query it for some of the default options.

Abaixo estão algumas capturas de tela mostrando o resultado desta ferramenta, que revela um certificado mal configurado e configurações incorretas na AC. Se o PSPKIAudit detectar quaisquer configurações incorretas não abordadas neste post, consulte o SpecterOps paper para obter conselhos de remediação.

Conclusão

Espero um número crescente de ataques aos Serviços de Certificados do Active Directory. De fato, um PetitPotam com ataque de ADCS NTLM Relaying já surgiu desde que o artigo da SpecterOps foi publicado, e a SpecterOps está lançando o ForgeCert, o Golden Ticket dos Certificados, na BlackHat 2021. Portanto, é urgente verificar se há configurações incorretas no seu ambiente e corrigi-las prontamente, e depois repetir o processo regularmente.

Para proteção completa, considere a solução de segurança Netwrix Active Directory. Ela ajudará você a:

• Identifique proativamente lacunas de segurança por meio de uma avaliação de risco aprofundada.
• Minimize o tempo de inatividade custoso e as interrupções nos negócios.
• Detecte prontamente até mesmo ameaças avançadas a tempo e responda rapidamente.