Press "Enter" to skip to content

Active Directory: Explotando Certificate Templates

Hoy te traigo una vulnerabilidad que ha sido frecuente encontrar en los ejercicios de Red Team en los que he participado. Se trata de la explotación de los Certificate Templates de Active Directories mal configurados.

En primer lugar, vamos a poner un poco de contexto del escenario en el que nos encontramos. Partimos de que tenemos acceso a un Active Directory gracias a que hemos comprometido la cuenta del usuario iyates. Durante esta prueba de concepto, emplearé Cobalt Strike como C&C.

Contexto

Podemos comprobar que nuestro usuario pertenece al grupo «Domain Users»

Tras enumerar y analizar el sistema, también encontramos que hay un usuario que pertenece al grupo de los Domain Admins, el usuario nglover.

Nuestro objetivo es acceder al Domain Controller. Con nuestro usuario, podemos observar que no tenemos privilegios para listar el Domain Controller DC-1:

Certificate Template

Hasta  aquí el contexto. Vamos a ver como podemos abusar de los Certificate Templates para conseguir acceder al Domain Controller.

Certify es una herramienta que nos permite enumerar y explotar errores de configuración en los Certificate Services de un Active Directory. Mediante el parametro cas podemos enumerar la root Certificate Autority:

Así como las Enterprise Certificate Autorities (que están integradas con el AD) y los Certificate Templates que ofrece:

Es buen momento para hablar de los Certificate Templates.

En un AD, se utilizan Certificate Services para poder construir una infraestructura de clave pública. Un Certificate Template define las reglas y políticas que una Certificate Authority (CA) usa cuando recibe una petición para un certificado. Suele haber varias plantillas predefinidas que permiten facilitar la petición de certificados según para lo que se necesiten, y que contienen configuraciones como por cuánto tiempo es un certifiado válido, para qué se usa, quién puede solicitarlo, etc.

En esta imagen de https://posts.specterops.io/ se puede observar muy bien el proceso de cómo se pide un certificado:

 

Con Certify podemos encontrar los certificados que estan mal configurados y de los que podemos abusar, mediante el parametro find /vulnerable

Analicemos los datos de «VulnerableUserTemplate». Es una template que ofrece la Certificate Authority CA-1, y la flag «ENROLLEE_SUPPLIES_SUBJET» permite al usuario que solicite un certificado usando esta template que indique cualquier SAN (Subject Alternative Name). Es decir, que el usuario que utilice esta template para pedir un certificado puede pedirlo en nombre de otro usuario.

Además, este certificado también tiene la flag «Client Authentication», lo que permite utilizar el certificado para autenticarse.

Por último, podemos ver que los usuarios de «DEV\Domain Users» tienen derecho de inscripción, por lo que cualquier usuario de este grupo puede pedir un certificado usando esta template.

Certificate Template

Con esta información, la ruta  de ataque está clara: vamos a usar esta plantilla para solicitar un certificado en nombre del usuario nglover, que es Domain Admin. Con ese certificado nos autenticaremos como ese usuario y podremos acceder al Domain Controller DC-1.

Certify nos permite pedir el certificado usando la plantilla vulnerable:

Vamos a utilizar Rubeus para autenticarnos utilizando el certificado. Para ello, necesitamos modificarlo un poco. Primero tenemos que modificarlo para cambiarle la extensión y que pase de cert.pem a cert.pfx,  y después tenemos que codificarlo en Base64. Podemos hacer todo esto en Linux utilizando openssl:

Ahora tan solo tenemos que emplear la herramienta Rubeus para solicitar un Ticket Granting Ticket (TGT) com el usuario nglover utilizando este certificado (lo cual es posible gracias a que la plantilla tenía Client Authentication)

A continuación, utilizando también Rubeus crearemos una sesion de login de «sacrificio» con la que nos autenticamos como el usuario nglover en Kerberos utilizando el TGT que hemos obtenido. Nótese que da igual que contraseña pongamos porque lo que nos autentica es el TGT, mediante la técnica «Pass the ticket»:

Este comando funcionaría como un runas /netonly, y Rubeus nos muestra el Process ID del proceso que ha creado y en el cual ha inyectado el token de acceso, el cual podemos «robar» empleando el comando steal_token de Cobalt Strike (este comando está en la mayoría de C&C, por ejemplo en Mythic lo tiene el agente Apollo):

Al impersonar a iyates, ahora podemos solicitar acceso al Domain Controller DC-1, y como lo hacemos desde un proceso que tiene un token de acceso válido, podremos ver el contenido:

Hasta aquí el ataque. Es muy habitual encontrar esta vulnerabilidad en los Active Directories de muchos clientes. Siempre es muy importante configurar bien los certificados, porque una mala configuración puede poner en riesgo todo el directorio activo. 

Nota: Es posible abusar de los templates y realizar este ataque si el usuario que controlas tiene la propiedad «WriteOwner», «WriteDacl» o «WriteProperty».

Espero que te haya sido útil. Estoy intentando especializarme en Red Teaming, por lo que es muy probable que los proximos posts incluyan más contenido relacionado con Active Directory.

Lethani.

Be First to Comment

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Mission News Theme by Compete Themes.