AD Certificate Services: Configuraciones de riesgo y su remediación

Active Directory Certificate Services lleva mucho tiempo en uso, pero los recursos para aprenderlo no son excelentes. Como resultado, a menudo presenta configuraciones erróneas que son un vector creciente para ataques. De hecho, SpecterOps publicó un whitepaper detallando una serie de configuraciones erróneas y posibles ataques, además de ofrecer consejos para el endurecimiento de la seguridad. En este blog, cubro varios de los ajustes que pueden estar mal configurados y cómo detectarlos, ofrezco varias opciones para fortalecer aún más la seguridad y explico cómo usar una herramienta gratuita para verificar su entorno.

Antecedentes

Cuando se emite un certificado basado en autenticación a una identidad, el certificado puede utilizarse para autenticarse como la identidad establecida en el Nombre Alternativo del Sujeto (SAN); esto suele ser un UPN o nombre DNS. Luego, el certificado se utiliza en lugar de una contraseña para la autenticación inicial. La referencia técnica para esta autenticación inicial es RFC4556 si desea obtener más detalles.

Una vez que se ha emitido un certificado basado en autenticación, se puede utilizar para autenticarse como el sujeto hasta que sea revocado o caduque. Esto eludirá los planes de respuesta a incidentes que dependen de estrategias como restablecer la contraseña del usuario para expulsar a un atacante; el atacante puede tener acceso persistente a la cuenta a menos que los certificados también sean revocados.

Configuraciones de plantilla riesgosas

Aquí hay algunas configuraciones de plantillas de certificados que pueden llevar a malas configuraciones.

Autenticación basada en EKUs

Primero, busque Usos Clave Mejorados (EKUs) que permitan cualquier tipo de autenticación a nivel de dominio. Aquí hay una breve lista:

• Cualquier Propósito (2.5.29.37.0)
• SubCA (Ninguno)
• Autenticación de Cliente (1.3.6.1.5.5.7.3.2)
• Autenticación de cliente PKINIT (1.3.6.1.5.2.3.4)
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

La manera más fácil de encontrar manualmente todas sus plantillas de certificado que permiten esto es abrir el complemento MMC de Autoridad de Certificación, conectarse a su Autoridad de Certificación, mirar la sección de Plantillas de Certificado y examinar la Columna de Propósito Intencionado en busca de cualquiera de estos EKUs de autenticación. Por ejemplo, la figura a continuación muestra que las plantillas de Computadora, Copia de Inicio de Sesión con Tarjeta Inteligente y ambas de Controlador de Dominio contienen al menos uno de los PKUs.

Después de abordar las plantillas que encuentre, asegúrese de tener en cuenta que también existen formas de abusar de los certificados normales. Por ejemplo, la función Get-SmartCardCertificate de PoshADCS puede modificar una plantilla, solicitar certificados para ella y luego revertir los cambios en la plantilla.

“Banderín de Asunto de Suministros del Inscrito”

Cuando la bandera CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT está presente en la propiedad mspki-certificate-name-flag, el inscrito del certificado puede proporcionar su propio Nombre de Sujeto alternativo en la solicitud de firma de certificado. Esto significa que cualquier usuario que tenga permiso para inscribirse en un certificado con esta configuración puede solicitar un certificado como cualquier usuario en la red, incluyendo un usuario privilegiado.

Puede verificar esta marca en la consola de Certificate Template; está bajo la pestaña de Subject Name como la opción de radio “Supply in the request”:

Alternativamente, puede usar un comando de PowerShell como el siguiente para obtener las plantillas de AD y verificar si la bandera está establecida en el certificado:

      Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
      

Reduciendo aún más el riesgo

Además de corregir las configuraciones erróneas de certificados, considere utilizar las siguientes opciones para controlar la emisión de certificados.

Aprobación del Administrador de Certificados CA o Firmas Autorizadas

En primer lugar y probablemente lo más importante, revise la pestaña de Requisitos de Emisión en cada certificado para ver si requiere la aprobación del administrador de la Autoridad de Certificación (CA) o de uno o más autorizados.

Habilitar una o ambas de estas configuraciones puede reducir significativamente el riesgo al requerir verificaciones antes de que se emitan los certificados. Si no está seguro acerca de requerir firmas autorizadas, al menos exija la aprobación del administrador de certificados de CA; entonces cada vez que se solicite un certificado, irá a la Autoridad Certificadora para una revisión manual antes de ser emitido.

Permisos de inscripción

En segundo lugar, revise los permisos de inscripción en cada plantilla, que se pueden encontrar en la pestaña de Seguridad. Muchas configuraciones incorrectas son críticas solo cuando los principios genéricos o grupos grandes tienen estos permisos. En particular, verifique si hay Usuarios Autenticados, Usuarios del Dominio y cualquier grupo grande de usuarios que no deberían poder solicitar certificados; si los encuentra, considere revocar sus permisos de Inscripción o Autoinscripción.

Clave de registro EDITF_ATTRIBUTESUBJECTALTNAME2

Por último, revise la configuración del registro EDITF_ATTRIBUTESUBJECALTNAME2. Este ajuste es uno de los más interesantes: si está habilitado en la CA, entonces any certificado basado en autenticación que se emita (incluyendo certificados donde el sujeto se construye automáticamente a partir de Active Directory) puede tener valores definidos por el usuario en el SAN.

Para verificar esta configuración, puede ejecutar este comando:

      certutil –getreg policyEditFlags
      

Si EDITF_ATTRIBUTESUBJECALTNAME2 está en la lista de salida, debería eliminarlo usando este comando:

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

Puede encontrar más orientación sobre esta configuración aquí.

Comprobación de configuraciones de riesgo utilizando PSPKIAudit

The PSPKIAudit tool can help you audit your PKI infrastructure. To use PSPKIAudit, simply download the tool from GitHub, import the module and run the Invoke-PKIAudit command. This will enumerate the Certificate Authority from Active Directory and then query it for some of the default options.

A continuación se muestran un par de capturas de pantalla que muestran el resultado de esta herramienta, que revela un certificado mal configurado y configuraciones erróneas en la CA. Si PSPKIAudit detecta alguna configuración errónea no cubierta en esta publicación, consulte el SpecterOps paper para obtener consejos de remediación.

Conclusión

Espero un número creciente de ataques en Active Directory Certificate Services. De hecho, ya ha surgido un ataque de PetitPotam con ADCS NTLM Relaying desde que se publicó el documento de SpecterOps, y SpecterOps está lanzando ForgeCert, el Golden Ticket de Certificados, en BlackHat 2021. Por lo tanto, es urgente revisar las configuraciones erróneas en su entorno y remediarlas de inmediato, y luego repetir el proceso de manera regular.

Para una protección de extremo a extremo, considere la solución de seguridad de Netwrix Active Directory. Le ayudará a:

• Identifique proactivamente las brechas de seguridad mediante una evaluación de riesgos en profundidad.
• Minimice el costoso tiempo de inactividad y las interrupciones del negocio.
• Detecte rápidamente incluso las amenazas avanzadas a tiempo y responda con rapidez.