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 escalonamento de privilégios que ele havia descoberto usando autenticação por certificado. Ele descreve que um atacante pode inscrever um certificado que lhe permite autenticar-se como uma conta de computador Domain Controller e, assim, assumir um domínio do AD (e um tenant do AAD, se conectado). A Microsoft tratou as vulnerabilidades com uma correção em KB5014754. Este artigo descreve como isso afeta as 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 SCEPman ajuda a mitigar ataques Certifried, porque, ao contrário dos certificados de CA da Microsoft, os certificados de CA do SCEPman normalmente não precisam estar no NTAuth Store
• A correção da Microsoft não afetará as instalações do SCEPman na maioria dos casos. Nesses casos, ativar o modo Full Enforcement é uma boa ideia.

Consequências da correção da Microsoft

A correção em KB5014754 apenas adiciona alguns eventos de auditoria adicionais por padrão. O modo Full Enforcement começa em 11 de fevereiro de 2025 — ou antes, quando ativado manualmente. Com o modo Full Enforcement, os certificados podem ser usados para autenticação de usuário e dispositivo somente se 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 X.509 proprietária; o segundo é chamado de mapeamento de certificados e usa o atributo altSecurityIdentities.

Em termos gerais, isso afeta apenas autenticações no AD. Isso exige adicionar o certificado da CA ao NTAuth Store da floresta. Por padrão, o SCEPman não é adicionado ao NTAuth Store se você não fizer isso explicitamente e manualmente. Se você ainda não fez isso e não pretende fazê-lo, a correção não tem efeito na sua instância do SCEPman. Há um caso de uso em que a documentação do SCEPman recomenda adicionar o certificado da CA do SCEPman ao NTAuth Store, que é quando você quer permitir que o SCEPman emita certificados de Domain Controller para autenticação Kerberos.

Certificados de dispositivo do Intune

Os certificados de dispositivo podem ser usados 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 no AAD quanto no AD. Para esse caso de uso pouco comum, recomendamos mudar para Confiança na nuvem WHfB.

Certificados de usuário do Intune

Os certificados de usuário podem ser usados para a Confiança de certificado do Windows Hello for Business. Também poderiam ser usados para outras formas de autenticação no AD baseada em certificado, como sessões RDP em máquinas ingressadas no domínio ou autenticação Wi‑Fi baseada em NPS. Se você quiser fazer isso, você pode usar a configuração AppConfig:AddSidExtension para permitir que o SCEPman crie certificados de Strong Certificate Mapping. Os 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 certificados. Você também pode usar esse método como alternativa à extensão SID.

Certificados de DC

Os certificados de Domain Controller não são afetados pela vulnerabilidade e, portanto, geralmente também não são afetados pela correção. Pode acontecer de os certificados de DC serem usados para autenticação de cliente, para a qual eles eram permitidos anteriormente. Isso não funcionará mais quando o Full Enforcement for ativado. Procure por Eventos de auditoria após a correção para descobrir se isso pode afetá-lo. Na maioria dos casos, isso não deve ser um problema.

Ataques usando certificados SCEPman

O ataque Certifried só pode ser usado com certificados de CA no NTAuth Store. Por padrão, esse não é o caso do certificado de 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 o seu SCEPman emite certificados de Domain Controller, o seu certificado de CA do SCEPman está no NTAuth Store e você deve continuar lendo.

Um atacante precisa de um certificado com um UPN falsificado na extensão Subject Alternative Name (SAN) e o Extended Key Usage (EKU) Smart Card Logon, ou com um nome DNS falsificado 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 do AAD para fazer o SCEPman inscrever um certificado de usuário. Como o atacante poderia fazer com que o SCEPman emitisse um certificado utilizável para o ataque?

Os 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 proveniente do AAD é verificado, então o atacante não consegue inserir no certificado o UPN de uma conta que ele ainda não tenha obtido de qualquer forma. Se você também usar Mapeamento Forte de Certificados, você pode garantir que os certificados não funcionem para uma conta diferente se o UPN mudar.

Certificados de dispositivo do Intune

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

Portanto, você não deve adicionar entradas de nome DNS com base 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 locais, se você usar a mesma instância do SCEPman também para certificados de DC! Se ainda precisar disso, você deve ativar o modo Full Enforcement para impedir 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 no Intune.

Certificados de usuário e dispositivo do Jamf Pro

Os 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 emite certificados de DC, não deve adicionar nomes DNS ao SAN ou garantir que ative o modo Full Enforcement no seu domínio do AD.

Certificados do Certificate Master

Há três maneiras de emitir certificados por meio do componente Certificate Master a partir da versão 2.1 do SCEPman.

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

Certificados manuais de cliente também não são afetados. Eles contêm o EKU Client Authentication, mas nenhuma entrada DNS SAN.

Solicitaçõ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 esse tipo de certificado, você deve tomar pelo 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 somente a um único grupo do AAD que você configure como grupo de Acesso Privilegiado.
• Use instâncias e certificados de CA separados do SCEPman para certificados de DC (cujo certificado de CA está no NTAuth Store) e para o Certificate Master.
• Ative o modo Full Enforcement no seu domínio do AD.

Certificados de Domain Controller

Se um atacante tiver os direitos de acesso necessários para emitir certificados de Domain Controller, provavelmente esse atacante já tem controle sobre um Domain Controller e já é dono do domínio. O atacante não precisa do ataque Certifried.