Saltar al contenido

Proteger la inscripción web de AD CS frente a ESC8 y ESC11

Cierre el NTLM relay hacia AD CS: localice los puntos de inscripción HTTP, exija HTTPS y EPA, deshabilite NTLM, retire Web Enrollment y exija el cifrado RPC.

Florian Amette8 min de lectura

ESC8 es la razón por la que PetitPotam se convirtió en una técnica de toma de control del dominio en lugar de una curiosidad. Un atacante fuerza a un controlador de dominio a autenticarse mediante NTLM, reenvía esa autenticación a la página de inscripción HTTP de la CA y recibe un certificado emitido a la propia cuenta de equipo del controlador de dominio. Ese certificado se autentica mediante PKINIT como el DC, lo que basta para solicitar datos de replicación. No hay ninguna plantilla mal configurada ni se adivina ninguna contraseña; el fallo es que la CA acepta NTLM sobre un canal que no vincula la autenticación a la sesión (consulte la entrada del glosario ESC8). ESC11 es la misma idea contra la interfaz de inscripción RPC de la CA cuando no se exige el cifrado de las solicitudes.

Esta guía cubre en profundidad la superficie de inscripción: localizar todos los puntos de conexión HTTP y RPC que emiten certificados, decidir cuáles deberían existir y reforzar el resto con HTTPS, Extended Protection for Authentication (EPA), la eliminación de NTLM e IF_ENFORCEENCRYPTICERTREQUEST. Complementa la visión general de las clases ESC del pilar de hardening de AD CS y los controles de relay más amplios de Frenar el NTLM relay.

Medir: localizar todos los puntos de inscripción

AD CS puede exponer cuatro rutas de inscripción. Solo la primera está siempre presente:

Punto de conexiónServicio de rolTransporteClase de relay
MS-ICPR / DCOM (ICertPassage, ICertRequest)Certification AuthorityRPCESC11 si no se exige el cifrado
/certsrvCertification Authority Web Enrollment (ADCS-Web-Enrollment)HTTP/HTTPSESC8
Certificate Enrollment Web Service (CES)ADCS-Enroll-Web-SvcHTTPSESC8 con autenticación integrada de Windows
Network Device Enrollment Service (/certsrv/mscep)ADCS-Device-EnrollmentHTTP/HTTPSRiesgo distinto, mismo hardening

Empiece por lo que está instalado en cada CA y servidor de inscripción:

PowerShell
# Ejecutar en cada CA / servidor web de inscripción
Get-WindowsFeature ADCS-* | Where-Object Installed | Select-Object Name, DisplayName

# CA empresariales y URI de CES publicados en AD
$pks = "CN=Public Key Services,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Get-ADObject -SearchBase "CN=Enrollment Services,$pks" -LDAPFilter '(objectClass=pKIEnrollmentService)' `
    -Properties dNSHostName, msPKI-Enrollment-Servers |
    Select-Object Name, dNSHostName, @{n='CES';e={$_.'msPKI-Enrollment-Servers' -join '; '}}

Después compruebe qué ofrece realmente cada punto de conexión web. Desde una estación de trabajo de administración unida al dominio, en Windows PowerShell 5.1, una solicitud sin autenticar devuelve los esquemas de autenticación en el encabezado WWW-Authenticate. NTLM o Negotiate sobre HTTP sin cifrar es el peor caso.

PowerShell
foreach ($url in 'http://ca01.corp.example/certsrv/','https://ca01.corp.example/certsrv/') {
    try   { Invoke-WebRequest -Uri $url -UseBasicParsing -ErrorAction Stop | Out-Null; "$url -> anonymous 200" }
    catch { "$url -> $($_.Exception.Response.StatusCode) $($_.Exception.Response.Headers['WWW-Authenticate'])" }
}

Por último, mida el uso. Si los registros de IIS no muestran ningún acceso legítimo a /certsrv en 90 días, no está reforzando el punto de conexión: lo está eliminando.

PowerShell
Get-ChildItem 'C:\inetpub\logs\LogFiles\W3SVC1\*.log' |
    Where-Object LastWriteTime -gt (Get-Date).AddDays(-90) |
    Select-String -Pattern ' /certsrv' |
    ForEach-Object { ($_.Line -split ' ')[8] } |   # columna c-ip en el orden de campos W3C predeterminado
    Group-Object | Sort-Object Count -Descending | Select-Object -First 20 Count, Name

Confirme el índice de columna con el encabezado #Fields: de sus archivos de registro antes de fiarse de la columna de IP del cliente.

Decidir por punto de conexión

Clasifique cada punto de conexión antes de cambiar nada. Un punto de conexión sin tráfico legítimo se elimina. Un punto de conexión que solo usan clientes Windows unidos al dominio normalmente puede pasar a la inscripción automática basada en RPC y después eliminarse. Un punto de conexión que da servicio a dispositivos fuera del dominio, bosques de socios o appliances se mantiene y recibe el tratamiento completo de HTTPS, EPA y solo Kerberos que se describe más abajo. CES merece una nota aparte: puede configurarse con autenticación integrada de Windows, con nombre de usuario y contraseña o con certificado de cliente. Solo la variante con autenticación integrada de Windows es susceptible de relay en el sentido de ESC8, pero la autenticación con nombre de usuario y contraseña expone una solicitud de contraseña a cualquiera que pueda alcanzar el servicio, así que es preferible la autenticación con certificado para los escenarios de renovación. NDES no es un objetivo ESC8 de la misma forma, ya que emite certificados basándose en una contraseña de desafío y no en la identidad Windows de quien llama, pero se ejecuta sobre la misma pila de IIS y merece la misma revisión de HTTPS y exposición.

Opción de aplicación 1: retirar Web Enrollment

Las páginas heredadas certsrv existen sobre todo para solicitudes manuales desde el navegador. La inscripción automática por directiva de grupo usa RPC/DCOM, no certsrv, así que retirarlas no afecta a la mayoría de los flujos de trabajo unidos al dominio. Si los datos de uso lo permiten, desinstálelas:

PowerShell
# En el servidor que aloja Web Enrollment
Uninstall-AdcsWebEnrollment -Force
Uninstall-WindowsFeature ADCS-Web-Enrollment

Si el servidor de la CA solo tiene IIS por este motivo, elimine también el rol Servidor web, lo que reduce la superficie de ataque de un equipo de Tier 0. Haga la misma revisión para CES y NDES: si nada los consume, elimínelos.

Opción de aplicación 2: HTTPS, EPA y sin NTLM

Cuando un punto de conexión deba mantenerse, refuércelo en tres capas. Las secciones de autenticación de IIS están bloqueadas a nivel de servidor de forma predeterminada, así que escriba la configuración en applicationHost.config con una ruta de ubicación en lugar de en el web.config del sitio.

PowerShell
Import-Module WebAdministration
$loc = 'Default Web Site/CertSrv'

# 1. Exigir TLS
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags -Value 'Ssl'

# 2. Exigir Extended Protection for Authentication (enlace de canal)
Set-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' `
    -Name 'extendedProtection.tokenChecking' -Value 'Require'

# 3. Ofrecer solo Kerberos: quitar el proveedor NTLM y mantener Negotiate
Remove-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication/providers' `
    -Name '.' -AtElement @{ value = 'NTLM' }

Elimine también el enlace HTTP sin cifrar del sitio (o al menos de los directorios virtuales de inscripción) para que nada recurra al puerto 80. Quitar solo la cadena de proveedor NTLM no detiene NTLM dentro de Negotiate; Negotiate todavía puede recurrir a NTLM. Para eliminar NTLM por completo, bloquéelo a nivel del sistema operativo en el servidor de inscripción, después de auditar:

  • Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Audit Incoming NTLM Traffic = Enable auditing for all accounts
  • Tras un periodo de auditoría limpio: Network security: Restrict NTLM: Incoming NTLM traffic = Deny all accounts

Los eventos de auditoría se registran en Applications and Services Logs > Microsoft > Windows > NTLM > Operational (evento 8002 para el NTLM entrante). El método paso a paso está en auditar y restringir NTLM.

Para CES, el aviso de Microsoft sobre ESC8 (KB5005413) pide además habilitar EPA en el propio web.config del servicio, normalmente en C:\Windows\SystemData\CES\<CA name>_CES_Kerberos\, estableciendo extendedProtectionPolicy policyEnforcement="Always" en el elemento de seguridad de transporte, junto con la configuración de IIS. Cuando un balanceador de carga termina TLS delante de CES o de certsrv, EPA no puede funcionar porque el token de enlace de canal del cliente hace referencia al certificado del balanceador; o bien deje pasar TLS hasta IIS, o bien no publique el punto de conexión a través de ese balanceador.

Aplicar: cifrado de las solicitudes RPC (ESC11)

La interfaz MS-ICPR que usan certreq y algunos clientes acepta solicitudes sin privacidad de paquetes salvo que esté activada la marca de interfaz IF_ENFORCEENCRYPTICERTREQUEST de la CA. Compruebe todas las CA:

PowerShell
certutil -config "ca01.corp.example\CORP-Issuing-CA" -getreg CA\InterfaceFlags

Si IF_ENFORCEENCRYPTICERTREQUEST no aparece en la salida, actívela y reinicie el servicio:

PowerShell
certutil -config "ca01.corp.example\CORP-Issuing-CA" -setreg CA\InterfaceFlags +IF_ENFORCEENCRYPTICERTREQUEST
Restart-Service certsvc   # ejecutar en la CA

La marca está habilitada de forma predeterminada en las instalaciones de CA actuales. Cuando falta, el motivo habitual es un cambio hecho en el pasado para resolver un problema con un cliente heredado, así que averigüe de qué cliente se trata antes de dar por hecho que es seguro activarla.

Reducir el lado de la coerción

EPA y la eliminación de NTLM rompen el destino del relay; reduzca también el suministro de autenticaciones forzadas. Deshabilite la cola de impresión en los controladores de dominio, aplique las mitigaciones de EFSRPC y filtros RPC frente a la coerción al estilo PetitPotam, y bloquee el SMB y el HTTP salientes desde los controladores de dominio hacia cualquier cosa que no sea otro sistema de Tier 0. Estos controles se tratan en bloquear la coerción de autenticación y firewall de los controladores de dominio.

Verificar

Lea la configuración de IIS de cada directorio virtual que haya reforzado:

PowerShell
$loc = 'Default Web Site/CertSrv'
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/access' -Name sslFlags
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication' -Name 'extendedProtection.tokenChecking'
Get-WebConfigurationProperty -PSPath 'MACHINE/WEBROOT/APPHOST' -Location $loc `
    -Filter 'system.webServer/security/authentication/windowsAuthentication/providers' -Name '.' |
    Select-Object -ExpandProperty Collection | Select-Object value

Resultado esperado: Ssl, Require y solo Negotiate (o Negotiate:Kerberos) en la lista de proveedores. Vuelva a ejecutar la prueba de WWW-Authenticate del paso Medir: la URL HTTP ya no debe responder y la URL HTTPS no debe anunciar NTLM. Vuelva a ejecutar certutil -getreg CA\InterfaceFlags en todas las CA y confirme que Locksmith o sus propias comprobaciones ya no señalan ESC8 ni ESC11.

En la CA, mantenga la auditoría de emisiones (eventos 4886 y 4887) y genere una alerta cuando se emita un certificado a la cuenta de equipo de un controlador de dominio a partir de cualquier plantilla que no sea su plantilla de autenticación de controladores de dominio, o desde un solicitante que no sea el propio DC. Esa alerta detecta un relay que se cuele por un punto de conexión olvidado.

Qué se rompe

  • Retirar Web Enrollment: dejan de funcionar las solicitudes manuales desde el navegador, algunos scripts de inscripción de Linux y macOS, y los appliances que extraen datos de las páginas certsrv. Ofrezca a esos usuarios certreq en un equipo unido al dominio, una plantilla dedicada solicitada a través de un servicio controlado o un front-end ACME/SCEP adecuado.
  • Exigir EPA: los clientes y proxies que no admiten el enlace de canal fallan con HTTP 401. Los balanceadores de carga que terminan TLS y algunos proxies inversos son el caso habitual; los clientes HTTP de terceros antiguos son el otro.
  • Eliminar NTLM: fallan las solicitudes desde equipos no unidos al dominio, desde clientes que acceden a la CA por dirección IP o por un nombre sin SPN correspondiente, y desde clientes de otros bosques sin ruta Kerberos. Registre el SPN de cualquier alias que use (HTTP/pki.corp.example en la identidad del grupo de aplicaciones).
  • IF_ENFORCEENCRYPTICERTREQUEST: los clientes muy antiguos (de la época de Windows XP y Server 2003) y algunas herramientas de terceros que llaman a MS-ICPR sin privacidad de paquetes no pueden inscribirse por RPC.
  • Deshabilitar la cola de impresión en los controladores de dominio: se detiene la depuración de impresoras publicadas; nada más en un controlador de dominio debería depender de ella.

Lecturas relacionadas: el tema Servicios de certificados de AD, la entrada del glosario NTLM relay y firma LDAP y enlace de canal para la protección equivalente frente al relay en los controladores de dominio.

Preguntas frecuentes

¿La asignación fuerte de certificados detiene ESC8?

No. En un relay ESC8, el atacante obtiene un certificado para la cuenta cuya autenticación se reenvió, por ejemplo la cuenta de equipo de un controlador de dominio. La CA incluye en el certificado el SID auténtico de esa cuenta, así que el certificado tiene una asignación fuerte y supera la aplicación de KB5014754. Solo eliminar el punto de conexión susceptible de relay, o vincular la autenticación al canal TLS con EPA y eliminar NTLM, cierra la ruta.

¿Basta HTTPS por sí solo para proteger certsrv?

No. HTTPS protege el tráfico en tránsito, pero no detiene un relay: el atacante simplemente abre su propia sesión TLS con la CA y reenvía el intercambio NTLM a través de ella. Extended Protection for Authentication es lo que vincula el intercambio NTLM o Kerberos al canal TLS concreto, lo que hace fallar una autenticación reenviada. Necesita HTTPS y EPA juntos, o nada de NTLM.

¿Qué protege IF_ENFORCEENCRYPTICERTREQUEST?

Hace que la CA rechace las solicitudes de certificado enviadas mediante la interfaz RPC MS-ICPR salvo que la llamada RPC use privacidad de paquetes (cifrado). Sin ella, la autenticación NTLM hacia la interfaz de inscripción RPC puede reenviarse, que es la clase ESC11. La marca está activada de forma predeterminada en las CA de Windows Server actuales, pero los administradores a veces la quitan para dar soporte a clientes antiguos, así que verifíquela en todas las CA.

Proteger la inscripción web de AD CS frente a ESC8 y ESC11

Guías relacionadas

NTLM y protocolos heredados

Exigir firma LDAP y enlace de canal en los DC

Despliegue la firma LDAP y el enlace de canal con evidencias: recopile los eventos 2887, 2889 y 3039, corrija los clientes y aplique LdapEnforceChannelBinding.

Intermedio