AD CS Domain Escalation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Este é um resumo das seções de técnicas de escalonamento dos posts:
Os direitos de inscrição são concedidos a usuários com baixos privilégios pela CA Empresarial.
A aprovação do gerente não é necessária.
Nenhuma assinatura de pessoal autorizado é necessária.
Os descritores de segurança nos modelos de certificado são excessivamente permissivos, permitindo que usuários com baixos privilégios obtenham direitos de inscrição.
Os modelos de certificado são configurados para definir EKUs que facilitam a autenticação:
Identificadores de Uso de Chave Estendida (EKU) como Autenticação de Cliente (OID 1.3.6.1.5.5.7.3.2), Autenticação de Cliente PKINIT (1.3.6.1.5.2.3.4), Logon de Cartão Inteligente (OID 1.3.6.1.4.1.311.20.2.2), Qualquer Propósito (OID 2.5.29.37.0), ou sem EKU (SubCA) estão incluídos.
A capacidade de os solicitantes incluírem um subjectAltName na Solicitação de Assinatura de Certificado (CSR) é permitida pelo modelo:
O Active Directory (AD) prioriza o subjectAltName (SAN) em um certificado para verificação de identidade, se presente. Isso significa que, ao especificar o SAN em um CSR, um certificado pode ser solicitado para se passar por qualquer usuário (por exemplo, um administrador de domínio). Se um SAN pode ser especificado pelo solicitante é indicado no objeto AD do modelo de certificado através da propriedade mspki-certificate-name-flag. Esta propriedade é uma máscara de bits, e a presença da flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT permite a especificação do SAN pelo solicitante.
A configuração descrita permite que usuários com baixos privilégios solicitem certificados com qualquer SAN de sua escolha, possibilitando a autenticação como qualquer principal de domínio através do Kerberos ou SChannel.
Esse recurso às vezes é habilitado para suportar a geração sob demanda de certificados HTTPS ou de host por produtos ou serviços de implantação, ou devido à falta de entendimento.
Observa-se que criar um certificado com esta opção aciona um aviso, o que não acontece quando um modelo de certificado existente (como o modelo WebServer, que tem CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT habilitado) é duplicado e, em seguida, modificado para incluir um OID de autenticação.
Para encontrar modelos de certificado vulneráveis você pode executar:
Para abusar dessa vulnerabilidade para se passar por um administrador, pode-se executar:
Então você pode transformar o certificado gerado para o formato .pfx e usá-lo para autenticar usando Rubeus ou certipy novamente:
Os binários do Windows "Certreq.exe" e "Certutil.exe" podem ser usados para gerar o PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
A enumeração de modelos de certificado dentro do esquema de configuração da floresta AD, especificamente aqueles que não necessitam de aprovação ou assinaturas, que possuem um EKU de Autenticação de Cliente ou Logon de Cartão Inteligente, e com a flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT habilitada, pode ser realizada executando a seguinte consulta LDAP:
O segundo cenário de abuso é uma variação do primeiro:
Direitos de inscrição são concedidos a usuários com baixos privilégios pela CA Empresarial.
A exigência de aprovação do gerente é desativada.
A necessidade de assinaturas autorizadas é omitida.
Um descritor de segurança excessivamente permissivo no modelo de certificado concede direitos de inscrição de certificado a usuários com baixos privilégios.
O modelo de certificado é definido para incluir o EKU de Qualquer Propósito ou nenhum EKU.
O EKU de Qualquer Propósito permite que um certificado seja obtido por um atacante para qualquer propósito, incluindo autenticação de cliente, autenticação de servidor, assinatura de código, etc. A mesma técnica usada para ESC3 pode ser empregada para explorar este cenário.
Certificados com nenhum EKU, que atuam como certificados de CA subordinada, podem ser explorados para qualquer propósito e podem também ser usados para assinar novos certificados. Assim, um atacante poderia especificar EKUs ou campos arbitrários nos novos certificados utilizando um certificado de CA subordinada.
No entanto, novos certificados criados para autenticação de domínio não funcionarão se a CA subordinada não for confiável pelo objeto NTAuthCertificates, que é a configuração padrão. No entanto, um atacante ainda pode criar novos certificados com qualquer EKU e valores de certificado arbitrários. Estes poderiam ser potencialmente abusados para uma ampla gama de propósitos (por exemplo, assinatura de código, autenticação de servidor, etc.) e poderiam ter implicações significativas para outras aplicações na rede, como SAML, AD FS ou IPSec.
Para enumerar modelos que correspondem a este cenário dentro do esquema de configuração da Floresta AD, a seguinte consulta LDAP pode ser executada:
Este cenário é semelhante ao primeiro e ao segundo, mas abusando de uma EKU diferente (Agente de Solicitação de Certificado) e 2 modelos diferentes (portanto, possui 2 conjuntos de requisitos),
A EKU do Agente de Solicitação de Certificado (OID 1.3.6.1.4.1.311.20.2.1), conhecida como Agente de Inscrição na documentação da Microsoft, permite que um principal inscreva-se para um certificado em nome de outro usuário.
O “agente de inscrição” se inscreve em tal modelo e usa o certificado resultante para co-assinar um CSR em nome do outro usuário. Em seguida, envia o CSR co-assinado para a CA, inscrevendo-se em um modelo que permite “inscrever em nome de”, e a CA responde com um certificado pertencente ao “outro” usuário.
Requisitos 1:
Direitos de inscrição são concedidos a usuários de baixo privilégio pela CA Empresarial.
A exigência de aprovação do gerente é omitida.
Nenhuma exigência de assinaturas autorizadas.
O descritor de segurança do modelo de certificado é excessivamente permissivo, concedendo direitos de inscrição a usuários de baixo privilégio.
O modelo de certificado inclui a EKU do Agente de Solicitação de Certificado, permitindo a solicitação de outros modelos de certificado em nome de outros principais.
Requisitos 2:
A CA Empresarial concede direitos de inscrição a usuários de baixo privilégio.
A aprovação do gerente é contornada.
A versão do esquema do modelo é 1 ou superior a 2, e especifica um Requisito de Emissão de Política de Aplicação que necessita da EKU do Agente de Solicitação de Certificado.
Uma EKU definida no modelo de certificado permite autenticação de domínio.
Restrições para agentes de inscrição não são aplicadas na CA.
Você pode usar Certify ou Certipy para abusar deste cenário:
Os usuários que têm permissão para obter um certificado de agente de inscrição, os modelos nos quais os agentes de inscrição estão autorizados a se inscrever e as contas em nome das quais o agente de inscrição pode agir podem ser restringidos por CAs empresariais. Isso é alcançado abrindo o certsrc.msc snap-in, clicando com o botão direito na CA, clicando em Propriedades e, em seguida, navegando até a guia “Agentes de Inscrição”.
No entanto, observa-se que a configuração padrão para CAs é “Não restringir agentes de inscrição.” Quando a restrição sobre agentes de inscrição é ativada pelos administradores, configurá-la para “Restringir agentes de inscrição”, a configuração padrão permanece extremamente permissiva. Ela permite que Todos tenham acesso para se inscrever em todos os modelos como qualquer um.
O descritor de segurança nos modelos de certificado define as permissões específicas que os principais AD possuem em relação ao modelo.
Se um atacante possuir as permissões necessárias para alterar um modelo e instituir quaisquer configurações incorretas exploráveis descritas em seções anteriores, a escalada de privilégios pode ser facilitada.
As permissões notáveis aplicáveis aos modelos de certificado incluem:
Owner: Concede controle implícito sobre o objeto, permitindo a modificação de quaisquer atributos.
FullControl: Habilita autoridade completa sobre o objeto, incluindo a capacidade de alterar quaisquer atributos.
WriteOwner: Permite a alteração do proprietário do objeto para um principal sob o controle do atacante.
WriteDacl: Permite o ajuste dos controles de acesso, potencialmente concedendo ao atacante FullControl.
WriteProperty: Autoriza a edição de quaisquer propriedades do objeto.
Um exemplo de um privesc como o anterior:
ESC4 é quando um usuário tem privilégios de escrita sobre um modelo de certificado. Isso pode, por exemplo, ser abusado para sobrescrever a configuração do modelo de certificado para torná-lo vulnerável ao ESC1.
Como podemos ver no caminho acima, apenas JOHNPC possui esses privilégios, mas nosso usuário JOHN tem a nova borda AddKeyCredentialLink para JOHNPC. Como essa técnica está relacionada a certificados, implementei esse ataque também, que é conhecido como Shadow Credentials. Aqui está uma pequena prévia do comando shadow auto do Certipy para recuperar o hash NT da vítima.
Certipy pode sobrescrever a configuração de um modelo de certificado com um único comando. Por padrão, Certipy irá sobrescrever a configuração para torná-la vulnerável ao ESC1. Também podemos especificar o -save-old parâmetro para salvar a configuração antiga, o que será útil para restaurar a configuração após nosso ataque.
A extensa rede de relacionamentos interconectados baseados em ACL, que inclui vários objetos além dos modelos de certificado e da autoridade certificadora, pode impactar a segurança de todo o sistema AD CS. Esses objetos, que podem afetar significativamente a segurança, incluem:
O objeto de computador AD do servidor CA, que pode ser comprometido por meio de mecanismos como S4U2Self ou S4U2Proxy.
O servidor RPC/DCOM do servidor CA.
Qualquer objeto ou contêiner AD descendente dentro do caminho de contêiner específico CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Este caminho inclui, mas não se limita a, contêineres e objetos como o contêiner de Modelos de Certificado, contêiner de Autoridades Certificadoras, o objeto NTAuthCertificates e o Contêiner de Serviços de Inscrição.
A segurança do sistema PKI pode ser comprometida se um atacante com privilégios baixos conseguir controlar qualquer um desses componentes críticos.
O assunto discutido na postagem da CQure Academy também aborda as implicações do EDITF_ATTRIBUTESUBJECTALTNAME2 conforme descrito pela Microsoft. Esta configuração, quando ativada em uma Autoridade Certificadora (CA), permite a inclusão de valores definidos pelo usuário no nome alternativo do sujeito para qualquer solicitação, incluindo aquelas construídas a partir do Active Directory®. Consequentemente, essa disposição permite que um intruso se inscreva através de qualquer modelo configurado para autenticação de domínio—especificamente aqueles abertos à inscrição de usuários não privilegiados, como o modelo padrão de Usuário. Como resultado, um certificado pode ser obtido, permitindo que o intruso se autentique como um administrador de domínio ou qualquer outra entidade ativa dentro do domínio.
Nota: A abordagem para adicionar nomes alternativos em uma Solicitação de Assinatura de Certificado (CSR), através do argumento -attrib "SAN:" no certreq.exe (referido como “Pares de Nome e Valor”), apresenta um contraste em relação à estratégia de exploração de SANs no ESC1. Aqui, a distinção reside em como as informações da conta são encapsuladas—dentro de um atributo de certificado, em vez de uma extensão.
Para verificar se a configuração está ativada, as organizações podem utilizar o seguinte comando com certutil.exe:
Esta operação emprega essencialmente acesso remoto ao registro, portanto, uma abordagem alternativa pode ser:
Ferramentas como Certify e Certipy são capazes de detectar essa má configuração e explorá-la:
Para alterar essas configurações, assumindo que se possui direitos administrativos de domínio ou equivalentes, o seguinte comando pode ser executado de qualquer estação de trabalho:
Para desativar essa configuração em seu ambiente, a flag pode ser removida com:
Após as atualizações de segurança de maio de 2022, os certificados recém-emitidos conterão uma extensão de segurança que incorpora a propriedade objectSid do solicitante. Para o ESC1, esse SID é derivado do SAN especificado. No entanto, para o ESC6, o SID reflete o objectSid do solicitante, não o SAN.
Para explorar o ESC6, é essencial que o sistema seja suscetível ao ESC10 (Mapeamentos de Certificado Fracos), que prioriza o SAN sobre a nova extensão de segurança.
O controle de acesso para uma autoridade certificadora é mantido através de um conjunto de permissões que governam as ações da CA. Essas permissões podem ser visualizadas acessando certsrv.msc, clicando com o botão direito em uma CA, selecionando propriedades e, em seguida, navegando até a aba Segurança. Além disso, as permissões podem ser enumeradas usando o módulo PSPKI com comandos como:
Isso fornece insights sobre os direitos primários, nomeadamente ManageCA e ManageCertificates, correlacionando-se com os papéis de “administrador de CA” e “Gerente de Certificados”, respectivamente.
Ter direitos de ManageCA em uma autoridade de certificação permite que o principal manipule configurações remotamente usando PSPKI. Isso inclui alternar o sinalizador EDITF_ATTRIBUTESUBJECTALTNAME2 para permitir a especificação de SAN em qualquer modelo, um aspecto crítico da escalada de domínio.
A simplificação desse processo é alcançável através do uso do cmdlet Enable-PolicyModuleFlag do PSPKI, permitindo modificações sem interação direta com a GUI.
A posse de direitos de ManageCertificates facilita a aprovação de solicitações pendentes, contornando efetivamente a salvaguarda de "aprovação do gerente de certificados da CA".
Uma combinação dos módulos Certify e PSPKI pode ser utilizada para solicitar, aprovar e baixar um certificado:
No ataque anterior, as permissões Manage CA foram usadas para ativar a flag EDITF_ATTRIBUTESUBJECTALTNAME2 para realizar o ataque ESC6, mas isso não terá efeito até que o serviço CA (CertSvc) seja reiniciado. Quando um usuário tem o direito de acesso Manage CA, o usuário também pode reiniciar o serviço. No entanto, isso não significa que o usuário pode reiniciar o serviço remotamente. Além disso, o ESC6 pode não funcionar imediatamente na maioria dos ambientes corrigidos devido às atualizações de segurança de maio de 2022.
Portanto, outro ataque é apresentado aqui.
Pré-requisitos:
Apenas permissão ManageCA
Permissão Manage Certificates (pode ser concedida a partir de ManageCA)
O modelo de certificado SubCA deve estar ativado (pode ser ativado a partir de ManageCA)
A técnica se baseia no fato de que usuários com o direito de acesso Manage CA e Manage Certificates podem emitir solicitações de certificado falhadas. O modelo de certificado SubCA é vulnerável ao ESC1, mas apenas administradores podem se inscrever no modelo. Assim, um usuário pode solicitar a inscrição no SubCA - que será negada - mas depois emitida pelo gerente.
Você pode conceder a si mesmo o direito de acesso Manage Certificates adicionando seu usuário como um novo oficial.
