Vulnerabilidade de Segurança Certifried

Certifried é uma vulnerabilidade de segurança divulgada em maio de 2022 como CVE-2022-26921 e CVE-2022-26923. Oliver Lyak descreveu uma vulnerabilidade de Elevação de Privilégio que ele havia descoberto usando autenticação por certificado. Ele descreve que um atacante poderia inscrever um certificado que lhe permita autenticar-se como conta de computador de Controlador de Domínio e assim assumir um domínio AD (e um locatário AAD, se conectado). A Microsoft tratou as vulnerabilidades com um patch no KB5014754. Este artigo descreve como isso afeta organizações que executam o SCEPman e como o SCEPman pode ajudar a mitigar o problema de segurança.

Resumo Executivo

• Certificados do SCEPman não podem ser usados para ataques Certifried na maioria dos casos

• Usar o SCEPman ajuda a mitigar ataques Certifried, porque ao contrário dos certificados da CA da Microsoft, os certificados CA do SCEPman geralmente não precisam estar no repositório NTAuth

• O patch da Microsoft não afetará instalações do SCEPman na maioria dos casos. Nesses casos, habilitar o modo de Aplicação Completa é uma boa ideia.

Consequências do Patch da Microsoft

O patch em KB5014754 apenas adiciona alguns eventos de auditoria adicionais por padrão. O modo de Aplicação Completa começa em 11 de fevereiro de 2025 — ou antes se ativado manualmente. Com o modo de Aplicação Completa, certificados só podem ser usados para autenticação de usuário e dispositivo se eles contiverem o SID de uma conta ou, no caso de certificados de usuário, se o objeto AD do usuário contiver uma referência ao certificado específico. O primeiro requer uma nova extensão proprietária X.509, o segundo é chamado de Mapeamento Forte de Certificado e usa o atributo altSecurityIdentities.

De modo geral, isso tem efeito apenas nas autenticações AD. Requer adicionar o certificado da CA ao Repositório NTAuth da Floresta. Por padrão, o SCEPman não é adicionado ao repositório NTAuth se você não fizer isso explicitamente e manualmente. Se você ainda não fez isso e não planeja fazê-lo, o patch não tem efeito na sua instância do SCEPman. Há um caso de uso onde a documentação do SCEPman recomenda adicionar o certificado CA do SCEPman ao repositório NTAuth, que é quando você quer permitir que o SCEPman emita certificados de Controlador de Domínio para Autenticação Kerberos.

Certificados de Dispositivo do Intune

Certificados de Dispositivo podem ser utilizáveis para Confiança de Certificado do Windows Hello for Business. Se você adicionou o nome DNS do AD aos certificados de dispositivo para usá-los para Confiança de Certificado, você pode ser afetado. Isso requer um objeto de dispositivo tanto em AAD quanto em AD. Para esse caso de uso raro, recomendamos mudar para WHfB Cloud Trust.

Certificados de Usuário do Intune

Certificados de Usuário podem ser usados para a Confiança de Certificado do Windows Hello for Business. Eles também poderiam ser usados para outras formas de autenticação baseada em certificado no AD, como sessões RDP para máquinas ingressadas no domínio ou autenticação WiFi baseada em NPS. Se você quiser fazer isso, pode usar a configuração AppConfig:AddSidExtension para permitir que o SCEPman crie certificados de Mapeamento Forte de Certificado. Certificados de usuário para usuários sincronizados entre AD e Entra ID recebem automaticamente a extensão com OID 1.3.6.1.4.1.311.25.2 para mapeá-los fortemente aos usuários do AD. A equipe do Intune adicionalmente planeja adicionar um valor SAN para implementar o mapeamento forte de certificado. Você também pode usar este método como alternativa à extensão SID.

Certificados de DC

Certificados de Controlador de Domínio não são afetados pela vulnerabilidade e, portanto, geralmente também não são afetados pelo patch. Pode acontecer de certificados de DC serem usados para Autenticação de Cliente, para a qual foram permitidos anteriormente. Isso não funcionará mais uma vez que a Aplicação Completa seja ativada. Procure por eventos de auditoria após a aplicação do patch para descobrir se isso pode afetar você. Na maioria dos casos, isso não deve ser um problema.

Ataques usando Certificados do SCEPman

O ataque Certifried só pode ser usado com certificados CA no repositório NTAuth. Por padrão, esse não é o caso para o certificado CA do SCEPman. Assim, se você estiver usando o SCEPman para inscrever certificados via Intune em vez do Microsoft Active Directory Certificate Services, é provável que seu ambiente seja imune ao ataque. No entanto, se seu SCEPman emite certificados de Controlador de Domínio, o certificado CA do seu SCEPman está no repositório NTAuth e você deve continuar lendo.

Um atacante precisa de um certificado com ou um UPN forjado na extensão Subject Alternative Name (SAN) e o Extended Key Usage (EKU) Smart Card Logon, ou um nome DNS forjado no SAN e o EKU Client Authentication.

Certificados de Usuário do Intune

Suponha que um atacante assuma o controle de uma conta de usuário AAD para fazer o SCEPman inscrever um certificado de usuário. Como o atacante poderia fazer o SCEPman emitir um certificado utilizável para o ataque?

Certificados de Usuário normalmente contêm o EKU Client Authentication. Mas se você seguir as recomendações, eles não contêm um nome DNS no SAN. Portanto, esses certificados não podem ser usados.

Se você configurou o EKU Smart Card Logon, o certificado pode ser usado para autenticação, mas apenas para a conta no UPN. O UPN vem do AAD e é verificado, então o atacante não pode colocar um UPN de uma conta no certificado que ele não possua de qualquer forma. Se você também usar Mapeamento Forte de Certificado, você pode garantir que certificados não funcionem para contas diferentes se o UPN mudar.

Certificados de Dispositivo do Intune

Seguindo nossas recomendações básicas, certificados de dispositivo têm o EKU Client Authentication. Seu SAN contém uma entrada URI no SAN, a qual não pode ser usada para o exploit. No entanto, você pode adicionar um nome DNS ao SAN além disso, por exemplo DeviceName.contoso.com. Se você também importou o certificado CA do SCEPman no repositório NTAuth, esses certificados podem ser usados para autenticar on-prem como um dispositivo com o mesmo nome DNS. Como os usuários podem definir seus nomes de dispositivo como quiserem, eles poderiam nomear seu dispositivo "PrimaryDomainController" e autenticar on-prem como PrimaryDomainController.contoso.com, mesmo que tal computador já exista no AD. Isso não é específico do SCEPman, a propósito, e afetaria outras implementações SCEP como o NDES também.

Portanto, você não deve adicionar entradas de nome DNS baseadas em dados controlados pelo usuário, como o nome do dispositivo, com nomes de domínio que também são usados para domínios on-prem se você usar a mesma instância do SCEPman também para certificados de DC! Se você ainda precisar disso, deve habilitar o modo de Aplicação Completa para prevenir o ataque de elevação. Você também pode executar duas instâncias separadas do SCEPman, uma para certificados de DC e outra para inscrição via Intune.

Certificados de Usuário e Dispositivo do Jamf Pro

Certificados emitidos via Jamf Pro terão o EKU Client Authentication. Se você seguir nossa documentação, nenhum tipo de certificado terá um nome DNS no SAN. Portanto, esses certificados são inutilizáveis para um ataque Certifried. Se você tiver a CA do SCEPman no NTAuthStore do seu AD, por exemplo porque você emite certificados de DC, você não deve adicionar nomes DNS ao SAN ou garantir que ative o modo de Aplicação Completa no seu domínio AD.

Certificados do Certificate Master

Existem três maneiras de emitir certificados através do componente Certificate Master a partir da versão 2.1 do SCEPman.

Certificados de Servidor TLS são inafetados, pois não contêm nem Smart Card Logon nem Client Authentication como EKU.

Certificados Manuais de Cliente também são inafetados. Eles contêm o EKU Client Authentication, mas nenhuma entrada DNS no SAN.

Requisições CSR Personalizadas são livremente configuráveis e incluem certificados de autenticação. Como qualquer pessoa com acesso ao aplicativo Certificate Master pode emitir tal certificado, você deve tomar ao menos uma das seguintes precauções:

• Certifique-se de que apenas contas privilegiadas possam acessar o Certificate Master. Você poderia, por exemplo, conceder acesso ao componente Certificate Master apenas a um único Grupo AAD que você designe como grupo de Acesso Privilegiado.

• Use instâncias separadas do SCEPman e certificados CA para Certificados de DC (cujo certificado CA está no repositório NTAuth) e para o Certificate Master.

• Habilite o modo de Aplicação Completa no seu domínio AD.

Certificados de Controlador de Domínio

Se um atacante tiver os direitos de acesso necessários para emitir certificados de Controlador de Domínio, esse atacante provavelmente já controla um Controlador de Domínio e já possui o domínio. O atacante não precisa do ataque Certifried.