Avaliação de segurança: Certificados

Este artigo descreve Microsoft Defender para o relatório de avaliação da postura de segurança certificados da Identidade.

Observação

Certifique-se de que testa as definições num ambiente controlado antes de as ativar na produção. Embora as avaliações sejam atualizadas quase em tempo real, as classificações e os estados são atualizados a cada 24 horas. Embora a lista de entidades afetadas seja atualizada poucos minutos após a implementação das recomendações, a status ainda poderá demorar algum tempo até ser marcada como Concluída.

Impor encriptação para a interface de inscrição de certificados RPC (ESC11)

Descrição

Os Serviços de Certificados do Active Directory (AD CS) suportam a inscrição de certificados através do protocolo RPC, especificamente com a interface MS-ICPR. Nestes casos, as definições de AC determinam as definições de segurança da interface RPC, incluindo o requisito para a privacidade dos pacotes.

Se o IF_ENFORCEENCRYPTICERTREQUEST sinalizador estiver ativado, a interface RPC só aceita ligações com o RPC_C_AUTHN_LEVEL_PKT_PRIVACY nível de autenticação. Este é o nível de autenticação mais elevado e requer que cada pacote seja assinado e encriptado de modo a impedir qualquer tipo de ataque de reencaminhamento. Isto é semelhante ao SMB Signing protocolo SMB.

Se a interface de inscrição RPC não exigir privacidade de pacotes, fica vulnerável a ataques de reencaminhamento (ESC11). O IF_ENFORCEENCRYPTICERTREQUEST sinalizador está ativado por predefinição, mas é muitas vezes desativado para permitir clientes que não suportam o nível de autenticação RPC necessário, como clientes com o Windows XP.

Observação

Esta avaliação só está disponível para clientes que tenham instalado um sensor num servidor do AD CS. Para obter mais informações, veja Novo tipo de sensor para os Serviços de Certificados do Active Directory (AD CS)

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para impor a encriptação para a inscrição de certificados RPC.

   

2. Pesquisar por que a IF_ENFORCEENCRYPTICERTREQUEST bandeira está desligada.

3. Certifique-se de que ativa o IF_ENFORCEENCRYPTICERTREQUEST sinalizador para remover a vulnerabilidade.

   Para ativar o sinalizador, execute:

   certutil -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
   

   Para reiniciar o serviço, execute:

   net stop certsvc & net start certsvc
   

Certifique-se de que testa as definições num ambiente controlado antes de as ativar na produção.

Editar pontos finais IIS de inscrição de certificados do ADCS inseguros (ESC8)

Descrição

Os Serviços de Certificados do Active Directory (AD CS) suportam a inscrição de certificados através de vários métodos e protocolos, incluindo a inscrição através de HTTP através do Serviço de Inscrição de Certificados (CES) ou da interface de Inscrição Web (Certsrv).

Se o ponto final do IIS permitir a autenticação NTLM sem impor a assinatura de protocolo (HTTPS) ou sem impor a Proteção Alargada para Autenticação (EPA), fica vulnerável a ataques de reencaminhamento NTLM (ESC8). Os ataques de reencaminhamento podem levar a uma obtenção completa do domínio se um atacante conseguir fazê-lo com êxito.

Observação

Esta avaliação só está disponível para clientes que tenham instalado um sensor num servidor do AD CS. Para obter mais informações, veja Configurar sensores para o AD FS, AD CS e Microsoft Entra Connect.

Implementação

Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para pontos finais IIS de inscrição de certificados do AD CS inseguros.

A avaliação lista os pontos finais HTTP problemáticos na sua organização e orientações para configurar os pontos finais de forma segura.

Uma vez processado, o risco de ataque ESC8 é mitigado, reduzindo significativamente a superfície de ataque.

Editar proprietário de modelos de certificado configurado incorretamente (ESC4)

Este artigo fornece uma descrição geral da Microsoft Defender para o relatório de avaliação da postura de segurança do proprietário de modelos de certificados configurados incorretamente (ESC4) da Identidade.

Descrição

Um modelo de certificado é um objeto do Active Directory com um proprietário, que controla o acesso ao objeto e a capacidade de editar o objeto.

Se as permissões de proprietário concederem a um grupo incorporado e sem privilégios permissões que permitem alterações na definição do modelo, um adversário pode introduzir uma configuração incorreta do modelo, escalar privilégios e comprometer todo o domínio.

Exemplos de grupos incorporados e sem privilégios são Utilizadores autenticados, Utilizadores de domínio ou Todos. Exemplos de permissões que permitem alterações de definição de modelo são Controlo total ou DACL de Escrita.

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para obter um proprietário de modelo de certificado configurado incorretamente.

   

2. Investigue o motivo pelo qual o proprietário do modelo pode estar configurado incorretamente.

3. Resolva o problema ao alterar o proprietário para um utilizador privilegiado e monitorizado.

Editar ACL de Autoridade de Certificação (ESC7) configurada incorretamente

Descrição

As Autoridades de Certificação (ACs) mantêm listas de controlo de acesso (ACLs) que descrevem funções e permissões para a AC. Se o controlo de acesso não estiver configurado corretamente, qualquer utilizador poderá ser autorizado a interferir com as definições da AC, contornar as medidas de segurança e potencialmente comprometer todo o domínio.

O efeito de uma ACL configurada incorretamente varia consoante o tipo de permissão aplicada. Por exemplo:

• Se um utilizador sem privilégios tiver o direito Gerir Certificados , pode aprovar pedidos de certificado pendentes, ignorando o requisito de aprovação do Gestor .
• Com o direito Gerir AC, o utilizador pode modificar as definições da AC, como adicionar o sinalizador SANEDITF_ATTRIBUTESUBJECTALTNAME2 (), criando uma configuração incorreta artificial que poderá levar posteriormente a um compromisso completo do domínio.

Pré-requisitos

Esta avaliação só está disponível para clientes que instalaram um sensor num servidor do AD CS. Para obter mais informações, veja Novo tipo de sensor para os Serviços de Certificados do Active Directory (AD CS).

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para OBTER ACLs de Autoridade de Certificação configuradas incorretamente. Por exemplo:

   

2. Investigue por que motivo a ACL de AC está mal configurada.

3. Resolva os problemas ao remover todas as permissões que concedem a grupos incorporados sem privilégios com as permissões Gerir AC e/ou Gerir certificados .

Editar modelos de certificado configurados incorretamente ACL (ESC4)

Descrição

Os modelos de certificado são objetos do Active Directory com uma ACL que controla o acesso ao objeto. Além de determinar as permissões de inscrição, a ACL também determina as permissões para editar o próprio objeto.

Se, por algum motivo, existir uma entrada na ACL que concede a um grupo incorporado e sem privilégios permissões que permitem alterações na definição do modelo, um adversário pode introduzir uma configuração incorreta do modelo, escalar privilégios e comprometer todo o domínio.

Exemplos de grupos incorporados e sem privilégios são Utilizadores autenticados, Utilizadores de domínio ou Todos. Exemplos de permissões que permitem alterações de definição de modelo são Controlo total ou DACL de Escrita.

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para obter uma ACL de modelo de certificado configurada incorretamente. Por exemplo:

   

2. Pesquisar o motivo pelo qual a ACL de modelo pode estar configurada incorretamente.

3. Resolva o problema ao remover qualquer entrada que conceda permissões de grupo sem privilégios que permitam adulterar o modelo.

4. Remova o modelo de certificado de ser publicado por qualquer AC, se não for necessário.

Editar modelo de certificado do agente de inscrição configurado incorretamente (ESC3)

Descrição

Normalmente, os utilizadores têm um Agente de Inscrição que inscreve os respetivos certificados para os mesmos. Em circunstâncias específicas, os certificados do Agente de Inscrição podem inscrever certificados para qualquer utilizador elegível, o que representa um risco para a sua organização.

Quando Microsoft Defender para relatórios de Identidade sobre modelos de certificados do Agente de Inscrição que colocam em perigo a sua organização, os modelos de Agente de Inscrição de risco são listados no painel Entidades expostas.

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para obter modelos de certificados do agente de inscrição configurados incorretamente. Por exemplo:

   

2. Resolva os problemas ao executar, pelo menos, um dos seguintes passos:

   • Remova o EKU do agente de pedido de certificado .
   • Remova permissões de inscrição excessivamente permissivas, que permitem a qualquer utilizador inscrever certificados com base nesse modelo de certificado. Os modelos marcados como vulneráveis pelo Defender para Identidade têm, pelo menos, uma entrada de lista de acesso que permite a inscrição para um grupo sem privilégios incorporado, tornando-o explorável por qualquer utilizador. Exemplos de grupos incorporados e sem privilégios são Utilizadores Autenticados ou Todos.
   • Ative o requisito de aprovação do Gestor de Certificados de AC.
   • Remova o modelo de certificado de ser publicado por qualquer AC. Os modelos que não são publicados não podem ser pedidos e, portanto, não podem ser explorados.
   • Utilize restrições do Agente de Inscrição ao nível da Autoridade de Certificação. Por exemplo, poderá querer restringir os utilizadores que têm permissão para atuar como Agente de Inscrição e quais os modelos que podem ser pedidos.

Editar modelo de certificado excessivamente permissivo com EKU privilegiado (EKU para qualquer finalidade ou Sem EKU) (ESC2)

Descrição

Os certificados digitais desempenham um papel fundamental no estabelecimento da confiança e preservação da integridade em toda a organização. Isto acontece não só na autenticação de domínio Kerberos, mas também noutras áreas, como integridade do código, integridade do servidor e tecnologias que dependem de certificados como Serviços de Federação do Active Directory (AD FS) (AD FS) e IPSec.

Quando um modelo de certificado não tem EKUs ou tem um EKU para Qualquer Finalidade e está inscrito para qualquer utilizador sem privilégios, os certificados emitidos com base nesse modelo podem ser utilizados maliciosamente por um adversário, comprometendo a confiança.

Apesar de o certificado não poder ser utilizado para representar a autenticação do utilizador, compromete outros componentes que aliviam os certificados digitais para o modelo de confiança. Os adversários podem criar certificados TLS e representar qualquer site.

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para modelos de certificados excessivamente permissivos com um EKU privilegiado. Por exemplo:

   

2. Pesquisar por que motivo os modelos têm um EKU privilegiado.

3. Resolva o problema ao fazer o seguinte:

   • Restringir as permissões excessivamente permissivas do modelo.
   • Imponha mitigações adicionais, como adicionar requisitos de aprovação e assinatura do Gestor , se possível.

Impedir a Inscrição de Certificados com Políticas de Aplicação arbitrárias (ESC15)

Descrição

Esta recomendação aborda diretamente o CVE-2024-49019 recentemente publicado, que destaca os riscos de segurança associados a configurações vulneráveis do AD CS. Esta avaliação da postura de segurança lista todos os modelos de certificado vulneráveis encontrados em ambientes de cliente devido a servidores do AD CS não recortados.

Os modelos de certificados vulneráveis ao CVE-2024-49019 permitem que um atacante emita um certificado com Políticas de Aplicação arbitrárias e Nome Alternativo do Requerente. O certificado pode ser utilizado para escalar privilégios, o que pode resultar num compromisso de domínio completo. 

Estes modelos de certificado expõem as organizações a riscos significativos, uma vez que permitem aos atacantes emitir certificados com Políticas de Aplicação arbitrárias e Nomes Alternativos do Requerente (SANs). Estes certificados podem ser explorados para escalar privilégios e potencialmente comprometer todo o domínio. Em particular, estas vulnerabilidades permitem que utilizadores sem privilégios emitam certificados que podem autenticar-se como contas com privilégios elevados, o que representa uma ameaça de segurança grave.

Observação

Esta avaliação só está disponível para clientes que instalaram um sensor num servidor do AD CS. Para obter mais informações, veja Novo tipo de sensor para os Serviços de Certificados do Active Directory (AD CS).

Implementação

1. Reveja a ação recomendada em Impedir a Inscrição de Certificados com Políticas de Aplicação arbitrárias (ESC15).

2. Identifique os modelos de certificado vulneráveis:

   • Remover a permissão de inscrição para utilizadores sem privilégios.
   • Desative a opção "Fornecer no pedido ".

3. Identifique os servidores do AD CS vulneráveis ao CVE-2024-49019 e aplique o patch relevante.

   

Impedir que os utilizadores peçam um certificado válido para utilizadores arbitrários com base no modelo de certificado (ESC1) (Pré-visualização)

Descrição

Cada certificado é associado a uma entidade através do respetivo campo de assunto. No entanto, os certificados também incluem um campo Nome Alternativo do Requerente (SAN), que permite que o certificado seja válido para várias entidades.

O campo SAN é normalmente utilizado para serviços Web alojados no mesmo servidor, suportando a utilização de um único certificado HTTPS em vez de certificados separados para cada serviço. Quando o certificado específico também é válido para autenticação, ao conter um EKU adequado, como a Autenticação de Cliente, pode ser utilizado para autenticar várias contas diferentes.

Se um modelo de certificado tiver a opção Fornecer no pedido ativada, o modelo é vulnerável e os atacantes poderão conseguir inscrever um certificado válido para utilizadores arbitrários.

Importante

Se o certificado também for permitido para autenticação e não existirem medidas de mitigação impostas, como a aprovação do Gestor ou assinaturas autorizadas necessárias, o modelo de certificado é perigoso, pois permite que qualquer utilizador sem privilégios assuma qualquer utilizador arbitrário, incluindo um utilizador administrador de domínio.

Esta definição específica é uma das configurações incorretas mais comuns.

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para pedidos de certificado para utilizadores arbitrários. Por exemplo:

   

2. Para remediar pedidos de certificado para utilizadores arbitrários, execute pelo menos um dos seguintes passos:

   • Desative a opção Fornecer na configuração do pedido .

   • Remova quaisquer EKUs que ativem a autenticação de utilizador, como Autenticação de Cliente, início de sessão smartcard, autenticação de cliente PKINIT ou Qualquer finalidade.

   • Remova permissões de inscrição excessivamente permissivas, que permitem a qualquer utilizador inscrever o certificado com base nesse modelo de certificado.

     Os modelos de certificado marcados como vulneráveis pelo Defender para Identidade têm, pelo menos, uma entrada de lista de acesso que suporta a inscrição de um grupo incorporado e sem privilégios, tornando-o explorável por qualquer utilizador. Exemplos de grupos incorporados e sem privilégios incluem Utilizadores Autenticados ou Todos.

   • Ative o requisito de aprovação do Gestor de Certificados de AC.

   • Remova o modelo de certificado de ser publicado por qualquer AC. Os modelos que não são publicados não podem ser pedidos e, portanto, não podem ser explorados.

Editar definição de Autoridade de Certificação vulnerável (ESC6) (Pré-visualização)

Descrição

Cada certificado é associado a uma entidade através do respetivo campo de assunto. No entanto, um certificado também inclui um campo Nome Alternativo do Requerente (SAN), que permite que o certificado seja válido para várias entidades.

O campo SAN é normalmente utilizado para serviços Web alojados no mesmo servidor, suportando a utilização de um único certificado HTTPS em vez de certificados separados para cada serviço. Quando o certificado específico também é válido para autenticação, ao conter um EKU adequado, como a Autenticação de Cliente, pode ser utilizado para autenticar várias contas diferentes.

Os utilizadores sem privilégios que podem especificar os utilizadores nas definições san podem levar a um compromisso imediato e publicar um grande risco para a sua organização.

Se o sinalizador do AD CS editflags>EDITF_ATTRIBUTESUBJECTALTNAME2 estiver ativado, cada utilizador pode especificar as definições SAN para o respetivo pedido de certificado. Isto, por sua vez, afeta todos os modelos de certificado, quer tenham a opção Supply in the request ativada ou não.

Se existir um modelo em que a EDITF_ATTRIBUTESUBJECTALTNAME2 definição está ativada e o modelo for válido para autenticação, um atacante pode inscrever um certificado que possa representar qualquer conta arbitrária.

Observação

Esta avaliação só está disponível para clientes que instalaram um sensor num servidor do AD CS. Para obter mais informações, veja: Novidades no Microsoft Defender de Identidade

Implementação

1. Reveja a ação recomendada em https://security.microsoft.com/securescore?viewid=actions para editar as definições vulneráveis da Autoridade de Certificação. Por exemplo:

   

2. Pesquisar por que motivo a EDITF_ATTRIBUTESUBJECTALTNAME2 definição está ativada.

3. Desative a definição ao executar:

   certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
   

4. Reinicie o serviço ao executar:

   net stop certsvc & net start certsvc
   

Próximas etapas

• Saiba mais sobre a Classificação de Segurança da Microsoft