# Vulnerabilidade de Segurança Certifried Certifried é uma vulnerabilidade de segurança divulgada em maio de 2022 como [CVE-2022-26921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26921) e [CVE-2022-26923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26923). [Oliver Lyak descreveu uma vulnerabilidade de Escalada de Privilégios](https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4) que ele descobriu usando autenticação por certificado. Ele descreve que um atacante pode inscrever um certificado que lhe permite autenticar-se como uma conta de computador Controlador de Domínio e, assim, assumir o controlo de um domínio AD (e de um tenant AAD, se estiver ligado). A Microsoft tratou as vulnerabilidades com [um patch no KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap). Este artigo descreve como isso afeta organizações que executam SCEPman e como o SCEPman pode ajudar a mitigar o problema de segurança. ## Resumo Executivo * Os certificados 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 Microsoft CA, os certificados SCEPman CA normalmente não precisam de estar no armazenamento NTAuth * O patch da Microsoft não afetará as instalações SCEPman na maioria dos casos. Nesses casos, ativar o modo Full Enforcement é uma boa ideia. ## Consequências do patch da Microsoft O patch em [KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap) apenas adiciona alguns eventos de auditoria adicionais por predefinição. O modo Full Enforcement começa em 11 de fevereiro de 2025 — ou mais cedo se for ativado manualmente. Com o modo Full Enforcement, os certificados só podem ser usados para autenticação de utilizador e dispositivo se contiverem o SID de uma conta ou, no caso de certificados de utilizador, se o objeto AD do utilizador contiver uma referência ao certificado específico. O primeiro requer uma nova extensão X.509 proprietária; o segundo chama-se mapeamento de certificado e usa o atributo altSecurityIdentities. De um modo geral, isto tem efeito apenas em autenticações AD. Requer adicionar o certificado CA ao NTAuth Store da floresta. Por predefinição, o SCEPman não é adicionado ao NTAuth Store se não o fizer explicitamente e manualmente. Se ainda não o fez e não tenciona fazê-lo, o patch não terá efeito na sua instância SCEPman. Há um caso de uso em que a documentação do SCEPman recomenda adicionar o certificado SCEPman CA ao NTAuth Store, que é quando pretende [permitir que o SCEPman emita certificados de Controlador de Domínio para Autenticação Kerberos](https://docs.scepman.com/pt/gerenciamento-de-certificados/domain-controller-certificates#trust-the-ca-certificate-in-the-domain-for-kerberos-authentication). ### Certificados de Dispositivo Intune Os Certificados de Dispositivo podem ser utilizáveis para [Windows Hello for Business Certificate Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust). Se adicionou o nome DNS do AD aos certificados de dispositivo para os usar com Certificate Trust, pode ser afetado. Isto requer um objeto de dispositivo tanto no AAD como no AD. Para este caso de uso pouco frequente, recomendamos mudar para [WHfB Cloud Trust](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust). ### Certificados de Utilizador Intune Os Certificados de Utilizador podem ser usados para Windows Hello for Business Certificate Trust. Também poderiam ser usados para outras formas de autenticação AD baseada em certificados, como sessões RDP em máquinas associadas ao domínio ou autenticação WiFi baseada em NPS. Se quiser fazer isso, pode usar a configuração [AppConfig:AddSidExtension](https://docs.scepman.com/pt/configuracao-do-scepman/application-settings/certificates#appconfig-addsidextension) para permitir que o SCEPman crie certificados Strong Certificate Mapping. Os certificados de utilizador para utilizadores sincronizados entre AD e Entra ID recebem automaticamente a extensão com o OID 1.3.6.1.4.1.311.25.2 para os mapear fortemente para utilizadores AD.\ A equipa do Intune adicionalmente [planeia adicionar um valor SAN](https://docs.scepman.com/pt/configuracao-do-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates) para implementar o mapeamento forte de certificados. Também pode usar este método como alternativa à extensão SID. ### Certificados DC Os 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 que os certificados DC sejam usados para Autenticação de Cliente, para a qual eram permitidos anteriormente. Isso deixará de funcionar assim que o Full Enforcement for ativado. Procure [eventos de auditoria](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_auditevents) depois de aplicar o patch para descobrir se isso o poderá afetar. Na maioria dos casos, isso não deverá ser um problema. ## Ataques usando certificados SCEPman O ataque Certifried só pode ser usado com certificados CA no armazenamento NTAuth. Por predefinição, este não é o caso do certificado SCEPman CA. Assim, se estiver a usar o SCEPman para inscrever certificados via Intune em vez de Microsoft Active Directory Certificate Services, é provável que o seu ambiente esteja imune ao ataque. No entanto, se o seu SCEPman emitir certificados de Controlador de Domínio, o seu certificado SCEPman CA está no NTAuth Store e deve continuar a leitura. Um atacante precisa de um certificado com um UPN falsificado na extensão Subject Alternative Name (SAN) e a Extended Key Usage (EKU) Smart Card Logon, ou um nome DNS falsificado no SAN e a EKU Client Authentication. ### Certificados de Utilizador Intune Suponha que um atacante assume o controlo de uma conta de utilizador AAD para permitir que o SCEPman inscreva um certificado de utilizador. Como poderia o atacante fazer com que o SCEPman emitisse um certificado utilizável para o ataque? Os Certificados de Utilizador geralmente contêm a EKU Client Authentication. Mas se seguir as recomendações, eles não contêm um nome DNS no SAN. Portanto, estes certificados não podem ser usados. Se configurar a EKU Smart Card Logon, o certificado pode ser usado para autenticação, mas apenas para a conta no UPN. O UPN é obtido do AAD e é verificado, pelo que o atacante não consegue introduzir no certificado um UPN de uma conta que não esteja já na sua posse. Se também usar [Strong Certificate Mapping](https://docs.scepman.com/pt/configuracao-do-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates), pode garantir que os certificados não funcionem para uma conta diferente se o UPN mudar. ### Certificados de Dispositivo Intune Seguindo as nossas recomendações básicas, os certificados de dispositivo têm a EKU Client Authentication. O seu SAN contém uma entrada URI no SAN, que não pode ser usada para o exploit. No entanto, pode adicionar adicionalmente um nome DNS ao SAN, por exemplo DeviceName.contoso.com. Se também tiver importado o certificado SCEPman CA para o NTAuth Store, estes certificados podem ser usados para autenticar no local como um dispositivo com o mesmo nome DNS. Como os utilizadores podem definir os nomes dos seus dispositivos como quiserem, poderiam chamar ao seu dispositivo "PrimaryDomainController" e autenticar-se no local como PrimaryDomainController.contoso.com, mesmo que tal computador já exista no AD. Isto não é específico do SCEPman, aliás, e também afetaria outras implementações SCEP, como NDES. Portanto, não deve adicionar entradas de nome DNS com base em dados controlados pelo utilizador, como o nome do dispositivo, com nomes de domínio que também são usados para domínios no local, se estiver a usar a mesma instância SCEPman também para certificados DC! Se ainda assim precisar disto, deve ativar o modo Full Enforcement para impedir o ataque de escalada de privilégios. Também pode executar duas instâncias SCEPman separadas, uma para certificados DC e outra para inscrição Intune. ### Certificados de Utilizador e Dispositivo Jamf Pro Os certificados emitidos via Jamf Pro terão a EKU Client Authentication. Se seguir a nossa documentação, nenhum tipo de certificado terá um nome DNS no SAN. Por isso, estes certificados são inutilizáveis para um ataque Certifried. Se tiver o SCEPman CA no NTAuthStore do seu AD, por exemplo porque emite certificados DC, não deve adicionar nomes DNS ao SAN ou deve garantir que ativa o modo Full Enforcement no seu domínio AD. ### Certificados Certificate Master Existem três formas de emitir certificados através do componente Certificate Master a partir da versão 2.1 do SCEPman. [**Certificados de Servidor TLS**](https://docs.scepman.com/pt/gerenciamento-de-certificados/certificate-master/tls-server-certificate-pkcs-12) não são afetados, pois não contêm nem Smart Card Logon nem Client Authentication como EKU. [**Certificados de Cliente Manuais**](https://docs.scepman.com/pt/gerenciamento-de-certificados/certificate-master/client-certificate-pkcs-12) também não são afetados. Contêm a EKU Client Authentication, mas nenhuma entrada DNS SAN. [**Pedidos CSR Personalizados**](https://docs.scepman.com/pt/gerenciamento-de-certificados/certificate-master/certificate-signing-request-csr) são livremente configuráveis e incluem certificados de autenticação. Como qualquer pessoa com acesso à aplicação Certificate Master pode emitir esse tipo de certificado, deve tomar pelo menos uma das seguintes precauções: * Certifique-se de que apenas contas privilegiadas podem aceder ao Certificate Master. Pode, por exemplo, [conceder acesso ao componente Certificate Master](https://docs.scepman.com/pt/implantacao-do-scepman/permissions/post-installation-config#granting-the-rights-to-request-certificates-via-the-certificate-master-website) apenas a um único grupo AAD que desenhe como [grupo de Acesso Privilegiado](https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-features). * Use instâncias SCEPman e certificados CA separados para Certificados DC (cujo certificado CA está no NTAuth Store) e para o Certificate Master. * Ative o modo Full Enforcement no seu domínio AD. ### Certificados de Domain Controller Se um atacante tiver os direitos de acesso necessários para emitir certificados de Controlador de Domínio, é provável que esse atacante já tenha controlo sobre um Controlador de Domínio e seja o proprietário do domínio. O atacante não precisa do ataque Certifried.