Vulnerabilidad de seguridad Certifried

Certifried es una vulnerabilidad de seguridad divulgada en mayo de 2022 como CVE-2022-26921 y CVE-2022-26923. Oliver Lyak describió una vulnerabilidad de escalada de privilegios que había descubierto usando autenticación por certificado. Describe que un atacante podría inscribir un certificado que le permita autenticarse como la cuenta de equipo del Controlador de Dominio y así hacerse con el control de un dominio AD (y de un inquilino AAD, si está conectado). Microsoft abordó las vulnerabilidades con un parche en KB5014754. Este artículo describe cómo esto afecta a las organizaciones que ejecutan SCEPman y cómo SCEPman puede ayudar a mitigar el problema de seguridad.

Resumen Ejecutivo

• Los certificados de SCEPman no pueden usarse para ataques Certifried en la mayoría de los casos

• Usar SCEPman ayuda a mitigar los ataques Certifried, porque a diferencia de los certificados de CA de Microsoft, los certificados CA de SCEPman normalmente no necesitan estar en el almacén NTAuth

• El parche de Microsoft no afectará a las instalaciones de SCEPman en la mayoría de los casos. En estos casos, activar el modo de Aplicación Completa es una buena idea.

Consecuencias del parche de Microsoft

El parche en KB5014754 solo añade algunos eventos de auditoría adicionales por defecto. El modo de Aplicación Completa comienza el 11 de febrero de 2025 —o antes si se habilita manualmente. Con el modo de Aplicación Completa, los certificados solo pueden usarse para la autenticación de usuarios y dispositivos si contienen el SID de una cuenta o, en el caso de certificados de usuario, si el objeto AD del usuario contiene una referencia al certificado específico. Lo primero requiere una nueva extensión propietaria X.509, lo segundo se llama Mapeo de Certificados y utiliza el atributo altSecurityIdentities.

En términos generales, esto tiene efecto solo en las autenticaciones AD. Requiere añadir el certificado CA al Almacén NTAuth del Bosque. Por defecto, SCEPman no se añade al Almacén NTAuth si no lo hace usted explícita y manualmente. Si no ha hecho esto aún y no planea hacerlo, el parche no tiene efecto en su instancia de SCEPman. Hay un caso de uso en el que la documentación de SCEPman recomienda añadir el certificado CA de SCEPman al Almacén NTAuth, que es cuando desea permitir que SCEPman emita certificados de Controlador de Dominio para la Autenticación Kerberos.

Certificados de Dispositivo de Intune

Los Certificados de Dispositivo podrían ser utilizables para Confianza de Certificado de Windows Hello for Business. Si añadió el nombre DNS de AD a los certificados de dispositivo para usarlos en la Confianza de Certificado, podría verse afectado. Esto requiere un objeto de dispositivo tanto en AAD como en AD. Para este caso de uso poco frecuente, recomendamos cambiar a Confianza en la Nube WHfB.

Certificados de Usuario de Intune

Los Certificados de Usuario pueden usarse para la Confianza de Certificado de Windows Hello for Business. También podrían usarse para otras formas de autenticación basada en certificados en AD como sesiones RDP a máquinas unidas al dominio o autenticación WiFi basada en NPS. Si desea hacer esto, puede utilizar la configuración AppConfig:AddSidExtension para permitir que SCEPman cree certificados de Mapeo de Certificado Fuerte. Los certificados de usuario para usuarios sincronizados entre AD y Entra ID reciben automáticamente la extensión con OID 1.3.6.1.4.1.311.25.2 para mapearlos fuertemente a usuarios de AD. Además, el equipo de Intune planea añadir un valor SAN para implementar el mapeo de certificado fuerte. También puede usar este método como alternativa a la extensión SID.

Certificados DC

Los certificados de Controlador de Dominio no se ven afectados por la vulnerabilidad y, por lo tanto, generalmente tampoco se ven afectados por el parche. Podría suceder que los certificados DC se usen para Autenticación de Cliente, para lo cual estaban permitidos previamente. Esto dejará de funcionar una vez que se active la Aplicación Completa. Busque eventos de auditoría después de parchear para averiguar si esto podría afectarle. En la mayoría de los casos, esto no debería ser un problema.

Ataques usando certificados de SCEPman

El ataque Certifried solo puede usarse con certificados CA en el almacén NTAuth. Por defecto, este no es el caso del certificado CA de SCEPman. Por lo tanto, si usa SCEPman para inscribir certificados vía Intune en lugar de Microsoft Active Directory Certificate Services, hay muchas probabilidades de que su entorno sea inmune al ataque. Sin embargo, si su SCEPman emite certificados de Controlador de Dominio, su certificado CA de SCEPman está en el almacén NTAuth y debería seguir leyendo.

Un atacante necesita un certificado con un UPN falsificado en la extensión Subject Alternative Name (SAN) y el Uso Extendido de Clave (EKU) Smart Card Logon, o un nombre DNS falsificado en la SAN y el EKU Client Authentication.

Certificados de Usuario de Intune

Suponga que un atacante toma control de una cuenta de usuario AAD para que SCEPman inscriba un certificado de usuario. ¿Cómo podría el atacante lograr que SCEPman emita un certificado usable para el ataque?

Los Certificados de Usuario suelen contener el EKU Client Authentication. Pero si sigue las recomendaciones, no contienen un nombre DNS en la SAN. Por lo tanto, estos certificados no pueden ser usados.

Si configuró el EKU Smart Card Logon, el certificado puede usarse para autenticación, pero solo para la cuenta en el UPN. El UPN proviene de AAD y se verifica, por lo que el atacante no puede poner en el certificado un UPN de una cuenta que el atacante no controla de todos modos. Si también utiliza Asignación fuerte de certificados, puede asegurarse de que los certificados no funcionen para una cuenta diferente si el UPN cambia.

Certificados de Dispositivo de Intune

Siguiendo nuestras recomendaciones básicas, los certificados de dispositivo tienen el EKU Client Authentication. Su SAN contiene una entrada URI en la SAN, que no puede usarse para la explotación. Sin embargo, puede añadir un nombre DNS a la SAN además, por ejemplo DeviceName.contoso.com. Si además importó el certificado CA de SCEPman en el Almacén NTAuth, estos certificados pueden usarse para autenticarse localmente como un dispositivo con el mismo nombre DNS. Debido a que los usuarios pueden definir sus nombres de dispositivo como quieran, podrían nombrar su dispositivo "PrimaryDomainController" y autenticarse localmente como PrimaryDomainController.contoso.com, incluso si tal equipo ya existe en el AD. Esto no es específico de SCEPman, por cierto, y afectaría también a otras implementaciones SCEP como NDES.

Por lo tanto, no debe añadir entradas de nombres DNS basadas en datos controlados por el usuario como el nombre del dispositivo con nombres de dominio que también se usan para dominios locales si usa la misma instancia de SCEPman también para certificados DC. Si aún necesita esto, debe habilitar el modo de Aplicación Completa para prevenir el ataque de elevación. También podría ejecutar dos instancias separadas de SCEPman, una para certificados DC y otra para inscripciones de Intune.

Certificados de Usuario y Dispositivo de Jamf Pro

Los certificados emitidos vía Jamf Pro tendrán el EKU Client Authentication. Si sigue nuestra documentación, ningún tipo de certificado tendrá un nombre DNS en la SAN. Por lo tanto, estos certificados no son utilizables para un ataque Certifried. Si tiene el CA de SCEPman en el NTAuthStore de su AD, por ejemplo porque emite certificados DC, no debe añadir nombres DNS a la SAN o debe asegurarse de habilitar el modo de Aplicación Completa en su dominio AD.

Certificados del Maestro de Certificados

Hay tres formas de emitir certificados a través del componente Certificate Master desde la versión 2.1 de SCEPman.

Certificados TLS de Servidor no se ven afectados, ya que no contienen ni Smart Card Logon ni Client Authentication como EKU.

Certificados Manuales de Cliente tampoco se ven afectados. Contienen el EKU Client Authentication, pero ninguna entrada DNS en la SAN.

Solicitudes CSR Personalizadas son libremente configurables e incluyen certificados de autenticación. Dado que cualquiera con acceso a la aplicación Certificate Master puede emitir dicho certificado, debería tomar al menos una de las siguientes precauciones:

• Asegúrese de que solo cuentas con privilegios puedan acceder a Certificate Master. Podría, por ejemplo, conceder acceso al componente Certificate Master solo a un único Grupo AAD que usted designe como grupo de Acceso Privilegiado.

• Use instancias y certificados CA de SCEPman separados para Certificados DC (cuyo certificado CA está en el Almacén NTAuth) y Certificate Master.

• Habilite el modo de Aplicación Completa en su dominio AD.

Certificados de Controlador de Dominio

Si un atacante tiene los derechos de acceso necesarios para emitir certificados de Controlador de Dominio, es probable que ese atacante ya tenga control sobre un Controlador de Dominio y posea el dominio. El atacante no necesita el ataque Certifried.