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 es un resumen de las secciones de técnicas de escalación de las publicaciones:
Los derechos de inscripción son otorgados a usuarios de bajo privilegio por la CA Empresarial.
No se requiere aprobación del gerente.
No se necesitan firmas de personal autorizado.
Los descriptores de seguridad en las plantillas de certificado son excesivamente permisivos, permitiendo a los usuarios de bajo privilegio obtener derechos de inscripción.
Las plantillas de certificado están configuradas para definir EKUs que facilitan la autenticación:
Se incluyen identificadores de Uso Extendido de Clave (EKU) como Autenticación de Cliente (OID 1.3.6.1.5.5.7.3.2), Autenticación de Cliente PKINIT (1.3.6.1.5.2.3.4), Inicio de Sesión con Tarjeta Inteligente (OID 1.3.6.1.4.1.311.20.2.2), Cualquier Propósito (OID 2.5.29.37.0), o sin EKU (SubCA).
La capacidad para que los solicitantes incluyan un subjectAltName en la Solicitud de Firma de Certificado (CSR) es permitida por la plantilla:
Active Directory (AD) prioriza el subjectAltName (SAN) en un certificado para la verificación de identidad si está presente. Esto significa que al especificar el SAN en un CSR, se puede solicitar un certificado para suplantar a cualquier usuario (por ejemplo, un administrador de dominio). Si un SAN puede ser especificado por el solicitante se indica en el objeto AD de la plantilla de certificado a través de la propiedad mspki-certificate-name-flag. Esta propiedad es una máscara de bits, y la presencia de la bandera CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT permite la especificación del SAN por el solicitante.
La configuración descrita permite a los usuarios de bajo privilegio solicitar certificados con cualquier SAN de su elección, habilitando la autenticación como cualquier principal de dominio a través de Kerberos o SChannel.
Esta función a veces se habilita para soportar la generación en tiempo real de certificados HTTPS o de host por productos o servicios de implementación, o debido a una falta de comprensión.
Se observa que crear un certificado con esta opción genera una advertencia, lo cual no ocurre cuando se duplica una plantilla de certificado existente (como la plantilla WebServer, que tiene habilitado CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT) y luego se modifica para incluir un OID de autenticación.
Para encontrar plantillas de certificado vulnerables puedes ejecutar:
Para abusar de esta vulnerabilidad para hacerse pasar por un administrador se podría ejecutar:
Luego puedes transformar el certificado generado a formato .pfx y usarlo para autenticarte usando Rubeus o certipy nuevamente:
Los binarios de Windows "Certreq.exe" y "Certutil.exe" se pueden utilizar para generar el PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
La enumeración de plantillas de certificados dentro del esquema de configuración del bosque de AD, específicamente aquellas que no requieren aprobación o firmas, que poseen un EKU de Autenticación de Cliente o Inicio de Sesión con Tarjeta Inteligente, y con la bandera CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT habilitada, se puede realizar ejecutando la siguiente consulta LDAP:
El segundo escenario de abuso es una variación del primero:
Se otorgan derechos de inscripción a usuarios de bajo privilegio por la CA Empresarial.
Se desactiva el requisito de aprobación del gerente.
Se omite la necesidad de firmas autorizadas.
Un descriptor de seguridad excesivamente permisivo en la plantilla de certificado otorga derechos de inscripción de certificados a usuarios de bajo privilegio.
La plantilla de certificado está definida para incluir el EKU de Cualquier Propósito o ningún EKU.
El EKU de Cualquier Propósito permite que un atacante obtenga un certificado para cualquier propósito, incluyendo autenticación de cliente, autenticación de servidor, firma de código, etc. La misma técnica utilizada para ESC3 se puede emplear para explotar este escenario.
Los certificados con sin EKUs, que actúan como certificados de CA subordinada, pueden ser explotados para cualquier propósito y también pueden ser utilizados para firmar nuevos certificados. Por lo tanto, un atacante podría especificar EKUs o campos arbitrarios en los nuevos certificados utilizando un certificado de CA subordinada.
Sin embargo, los nuevos certificados creados para autenticación de dominio no funcionarán si la CA subordinada no es confiable por el objeto NTAuthCertificates, que es la configuración predeterminada. No obstante, un atacante aún puede crear nuevos certificados con cualquier EKU y valores de certificado arbitrarios. Estos podrían ser potencialmente abusados para una amplia gama de propósitos (por ejemplo, firma de código, autenticación de servidor, etc.) y podrían tener implicaciones significativas para otras aplicaciones en la red como SAML, AD FS o IPSec.
Para enumerar las plantillas que coinciden con este escenario dentro del esquema de configuración del Bosque AD, se puede ejecutar la siguiente consulta LDAP:
Este escenario es como el primero y el segundo, pero abusando de un EKU diferente (Agente de Solicitud de Certificado) y 2 plantillas diferentes (por lo tanto, tiene 2 conjuntos de requisitos),
El EKU de Agente de Solicitud de Certificado (OID 1.3.6.1.4.1.311.20.2.1), conocido como Agente de Inscripción en la documentación de Microsoft, permite a un principal inscribirse para un certificado en nombre de otro usuario.
El “agente de inscripción” se inscribe en tal plantilla y utiliza el certificado resultante para co-firmar un CSR en nombre del otro usuario. Luego envía el CSR co-firmado a la CA, inscribiéndose en una plantilla que permite “inscribirse en nombre de”, y la CA responde con un certificado que pertenece al “otro” usuario.
Requisitos 1:
Se otorgan derechos de inscripción a usuarios de bajo privilegio por la CA Empresarial.
Se omite el requisito de aprobación del gerente.
No hay requisito de firmas autorizadas.
El descriptor de seguridad de la plantilla de certificado es excesivamente permisivo, otorgando derechos de inscripción a usuarios de bajo privilegio.
La plantilla de certificado incluye el EKU de Agente de Solicitud de Certificado, permitiendo la solicitud de otras plantillas de certificado en nombre de otros principales.
Requisitos 2:
La CA Empresarial otorga derechos de inscripción a usuarios de bajo privilegio.
Se omite la aprobación del gerente.
La versión del esquema de la plantilla es 1 o excede 2, y especifica un Requisito de Emisión de Política de Aplicación que requiere el EKU de Agente de Solicitud de Certificado.
Un EKU definido en la plantilla de certificado permite la autenticación de dominio.
No se aplican restricciones para agentes de inscripción en la CA.
Puedes usar Certify o Certipy para abusar de este escenario:
Los usuarios que están autorizados a obtener un certificado de agente de inscripción, las plantillas en las que se permite a los agentes de inscripción inscribirse, y las cuentas en nombre de las cuales el agente de inscripción puede actuar pueden ser restringidos por las CA empresariales. Esto se logra abriendo el certsrc.msc complemento, haciendo clic derecho en la CA, haciendo clic en Propiedades, y luego navegando a la pestaña “Agentes de Inscripción”.
Sin embargo, se observa que la configuración predeterminada para las CA es “No restringir agentes de inscripción.” Cuando la restricción sobre los agentes de inscripción es habilitada por los administradores, configurarla en “Restringir agentes de inscripción,” la configuración predeterminada sigue siendo extremadamente permisiva. Permite el acceso a Todos para inscribirse en todas las plantillas como cualquier persona.
El descriptor de seguridad en las plantillas de certificado define los permisos específicos que los principales de AD poseen con respecto a la plantilla.
Si un atacante posee los permisos requeridos para alterar una plantilla e instituir cualquier mala configuración explotable descrita en secciones anteriores, se podría facilitar la escalada de privilegios.
Los permisos notables aplicables a las plantillas de certificado incluyen:
Propietario: Otorga control implícito sobre el objeto, permitiendo la modificación de cualquier atributo.
ControlTotal: Habilita autoridad completa sobre el objeto, incluida la capacidad de alterar cualquier atributo.
EscribirPropietario: Permite la alteración del propietario del objeto a un principal bajo el control del atacante.
EscribirDacl: Permite el ajuste de controles de acceso, potencialmente otorgando a un atacante ControlTotal.
EscribirPropiedad: Autoriza la edición de cualquier propiedad del objeto.
Un ejemplo de un privesc como el anterior:
ESC4 es cuando un usuario tiene privilegios de escritura sobre una plantilla de certificado. Esto puede, por ejemplo, ser abusado para sobrescribir la configuración de la plantilla de certificado para hacer que la plantilla sea vulnerable a ESC1.
Como podemos ver en la ruta anterior, solo JOHNPC tiene estos privilegios, pero nuestro usuario JOHN tiene el nuevo borde AddKeyCredentialLink hacia JOHNPC. Dado que esta técnica está relacionada con certificados, también he implementado este ataque, que se conoce como Credenciales Sombra. Aquí hay un pequeño adelanto del comando shadow auto de Certipy para recuperar el hash NT de la víctima.
Certipy puede sobrescribir la configuración de una plantilla de certificado con un solo comando. Por defecto, Certipy sobrescribirá la configuración para hacerla vulnerable a ESC1. También podemos especificar el -save-old parámetro para guardar la configuración antigua, lo que será útil para restaurar la configuración después de nuestro ataque.
La extensa red de relaciones interconectadas basadas en ACL, que incluye varios objetos más allá de las plantillas de certificados y la autoridad de certificación, puede afectar la seguridad de todo el sistema AD CS. Estos objetos, que pueden afectar significativamente la seguridad, abarcan:
El objeto de computadora AD del servidor CA, que puede ser comprometido a través de mecanismos como S4U2Self o S4U2Proxy.
El servidor RPC/DCOM del servidor CA.
Cualquier objeto o contenedor AD descendiente dentro de la ruta de contenedor específica CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Esta ruta incluye, pero no se limita a, contenedores y objetos como el contenedor de Plantillas de Certificados, el contenedor de Autoridades de Certificación, el objeto NTAuthCertificates y el Contenedor de Servicios de Inscripción.
La seguridad del sistema PKI puede verse comprometida si un atacante de bajo privilegio logra tomar el control de cualquiera de estos componentes críticos.
El tema discutido en el post de CQure Academy también toca las implicaciones de la bandera EDITF_ATTRIBUTESUBJECTALTNAME2, como lo describe Microsoft. Esta configuración, cuando se activa en una Autoridad de Certificación (CA), permite la inclusión de valores definidos por el usuario en el nombre alternativo del sujeto para cualquier solicitud, incluidas las construidas a partir de Active Directory®. En consecuencia, esta disposición permite a un intruso inscribirse a través de cualquier plantilla configurada para la autenticación de dominio—específicamente aquellas abiertas a la inscripción de usuarios no privilegiados, como la plantilla de Usuario estándar. Como resultado, se puede asegurar un certificado, lo que permite al intruso autenticarse como un administrador de dominio o cualquier otra entidad activa dentro del dominio.
Note: El enfoque para agregar nombres alternativos en una Solicitud de Firma de Certificado (CSR), a través del argumento -attrib "SAN:" en certreq.exe (denominado “Pares de Nombre y Valor”), presenta un contraste con la estrategia de explotación de SANs en ESC1. Aquí, la distinción radica en cómo se encapsula la información de la cuenta—dentro de un atributo de certificado, en lugar de una extensión.
Para verificar si la configuración está activada, las organizaciones pueden utilizar el siguiente comando con certutil.exe:
Esta operación emplea esencialmente acceso remoto al registro, por lo tanto, un enfoque alternativo podría ser:
Herramientas como Certify y Certipy son capaces de detectar esta mala configuración y explotarla:
Para alterar estas configuraciones, asumiendo que se posee derechos administrativos de dominio o equivalentes, se puede ejecutar el siguiente comando desde cualquier estación de trabajo:
Para deshabilitar esta configuración en su entorno, se puede eliminar la bandera con:
Después de las actualizaciones de seguridad de mayo de 2022, los certificados emitidos recientemente contendrán una extensión de seguridad que incorpora la propiedad objectSid del solicitante. Para ESC1, este SID se deriva del SAN especificado. Sin embargo, para ESC6, el SID refleja el objectSid del solicitante, no el SAN.
Para explotar ESC6, es esencial que el sistema sea susceptible a ESC10 (Mapeos de Certificados Débiles), que prioriza el SAN sobre la nueva extensión de seguridad.
El control de acceso para una autoridad de certificación se mantiene a través de un conjunto de permisos que rigen las acciones de la CA. Estos permisos se pueden ver accediendo a certsrv.msc, haciendo clic derecho en una CA, seleccionando propiedades y luego navegando a la pestaña de Seguridad. Además, los permisos se pueden enumerar utilizando el módulo PSPKI con comandos como:
Esto proporciona información sobre los derechos principales, a saber, ManageCA y ManageCertificates, que se correlacionan con los roles de “administrador de CA” y “gerente de certificados” respectivamente.
Tener derechos de ManageCA en una autoridad de certificación permite al principal manipular configuraciones de forma remota utilizando PSPKI. Esto incluye activar el flag EDITF_ATTRIBUTESUBJECTALTNAME2 para permitir la especificación de SAN en cualquier plantilla, un aspecto crítico de la escalación de dominio.
La simplificación de este proceso se puede lograr mediante el uso del cmdlet Enable-PolicyModuleFlag de PSPKI, que permite modificaciones sin interacción directa con la GUI.
La posesión de derechos de ManageCertificates facilita la aprobación de solicitudes pendientes, eludiendo efectivamente la salvaguarda de "aprobación del gerente de certificados de CA".
Se puede utilizar una combinación de los módulos Certify y PSPKI para solicitar, aprobar y descargar un certificado:
En el ataque anterior, se utilizaron los permisos Manage CA para habilitar el flag EDITF_ATTRIBUTESUBJECTALTNAME2 para realizar el ataque ESC6, pero esto no tendrá ningún efecto hasta que el servicio CA (CertSvc) sea reiniciado. Cuando un usuario tiene el derecho de acceso Manage CA, también se le permite reiniciar el servicio. Sin embargo, no significa que el usuario pueda reiniciar el servicio de forma remota. Además, ESC6 puede no funcionar de inmediato en la mayoría de los entornos parcheados debido a las actualizaciones de seguridad de mayo de 2022.
Por lo tanto, aquí se presenta otro ataque.
Requisitos previos:
Solo permiso ManageCA
Permiso Manage Certificates (puede ser otorgado desde ManageCA)
La plantilla de certificado SubCA debe estar habilitada (puede ser habilitada desde ManageCA)
La técnica se basa en el hecho de que los usuarios con el derecho de acceso Manage CA y Manage Certificates pueden emitir solicitudes de certificado fallidas. La plantilla de certificado SubCA es vulnerable a ESC1, pero solo los administradores pueden inscribirse en la plantilla. Así, un usuario puede solicitar inscribirse en la SubCA - lo cual será denegado - pero luego emitido por el gerente posteriormente.
Puedes otorgarte a ti mismo el derecho de acceso Manage Certificates agregando tu usuario como un nuevo oficial.
El SubCA template se puede habilitar en la CA con el parámetro -enable-template. Por defecto, el template SubCA está habilitado.