# Vulnerabilidad de seguridad Certifried Certifried es una vulnerabilidad de seguridad divulgada en mayo de 2022 como [CVE-2022-26921](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26921) y [CVE-2022-26923](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-26923). [Oliver Lyak describió una vulnerabilidad de escalada de privilegios](https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4) que había descubierto utilizando autenticación mediante certificado. Describe que un atacante podría inscribir un certificado que le permita autenticarse como cuenta de equipo de Controlador de Dominio y, de ese modo, tomar el control de un dominio AD (y de un inquilino AAD, si está conectado). Microsoft abordó las vulnerabilidades con [un parche en KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap). 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 Microsoft CA, 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 esos casos, habilitar el modo de Aplicación completa es una buena idea. ## Consecuencias del parche de Microsoft El parche en [KB5014754](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_certmap) solo agrega algunos eventos de auditoría adicionales de forma predeterminada. 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 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 X.509 propietaria; lo segundo se denomina asignación de certificados y usa el atributo altSecurityIdentities. En términos generales, esto solo afecta a las autenticaciones AD. Requiere agregar el certificado de la CA al almacén NTAuth del bosque. De forma predeterminada, SCEPman no se agrega al almacén NTAuth si no lo hace explícita y manualmente. Si aún no lo ha hecho 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 agregar 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](https://docs.scepman.com/es/administracion-de-certificados/domain-controller-certificates#trust-the-ca-certificate-in-the-domain-for-kerberos-authentication). ### Certificados de dispositivo de Intune Los certificados de dispositivo podrían ser utilizables para [Confianza en certificados de Windows Hello for Business](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust). Si agregó el nombre DNS de AD a los certificados de dispositivo para usarlos con Confianza en certificados, 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 de WHfB](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-trust). ### Certificados de usuario de Intune Los certificados de usuario pueden usarse para Confianza en certificados de Windows Hello for Business. También podrían utilizarse para otras formas de autenticación AD basada en certificados, como sesiones RDP en equipos unidos al dominio o autenticación WiFi basada en NPS. Si desea hacerlo, puede usar la configuración [AppConfig:AddSidExtension](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/certificates#appconfig-addsidextension) para permitir que SCEPman cree certificados de asignación fuerte de certificados. Los certificados de usuario para usuarios sincronizados entre AD y Entra ID reciben automáticamente la extensión con el OID 1.3.6.1.4.1.311.25.2 para asignarlos de forma fuerte a usuarios de AD.\ El equipo de Intune además [planea agregar un valor SAN](https://docs.scepman.com/es/configuracion-de-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates) para implementar la asignación fuerte de certificados. También puede usar este método como alternativa a la extensión SID. ### Certificados de Controlador de Dominio Los certificados de Controlador de Dominio no se ven afectados por la vulnerabilidad y, por lo tanto, en general tampoco se ven afectados por el parche. Puede ocurrir que los certificados de DC se utilicen para autenticación de cliente, para lo cual estaban permitidos anteriormente. Esto ya no funcionará una vez que se active la Aplicación completa. Busque [eventos de auditoría](https://support.microsoft.com/en-us/topic/kb5014754-certificate-based-authentication-changes-on-windows-domain-controllers-ad2c23b0-15d8-4340-a468-4d4f3b188f16#bkmk_auditevents) después de aplicar el parche para averiguar si esto podría afectarle. En la mayoría de los casos, esto no debería ser un problema. ## Ataques usando certificados SCEPman El ataque Certifried solo puede usarse con certificados CA en el almacén NTAuth. De forma predeterminada, este no es el caso del certificado CA de SCEPman. Por lo tanto, si usa SCEPman para inscribir certificados mediante Intune en lugar de Microsoft Active Directory Certificate Services, es probable 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 mejorado de clave (EKU) Smart Card Logon, o un nombre DNS falsificado en el SAN y el EKU Client Authentication. ### Certificados de usuario de Intune Suponga que un atacante toma el control de una cuenta de usuario AAD para permitir que SCEPman inscriba un certificado de usuario. ¿Cómo podría el atacante hacer que SCEPman emita un certificado utilizable para el ataque? Los certificados de usuario normalmente contienen el EKU Client Authentication. Pero si sigue las recomendaciones, no contienen un nombre DNS en el SAN. Por lo tanto, estos certificados no pueden usarse. Si configuró el EKU Smart Card Logon, el certificado puede usarse para autenticación, pero solo para la cuenta del UPN. El UPN proviene de AAD y se verifica, por lo que el atacante no puede introducir en el certificado un UPN de una cuenta de la que no se haya apoderado. Si además usa [Asignación de certificado fuerte](https://docs.scepman.com/es/configuracion-de-scepman/intune-implementing-strong-mapping-for-scep-and-pkcs-certificates), 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 el SAN, que no puede usarse para el exploit. Sin embargo, puede agregar además un nombre DNS al SAN, por ejemplo DeviceName.contoso.com. Si también 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. Como los usuarios pueden definir los nombres de sus dispositivos como quieran, podrían llamar a su dispositivo "PrimaryDomainController" y autenticarse localmente como PrimaryDomainController.contoso.com, incluso si ya existe un equipo así en AD. Por cierto, esto no es específico de SCEPman y también afectaría a otras implementaciones SCEP como NDES. Por lo tanto, no debe agregar entradas de nombre 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 de DC. Si aun así lo necesita, debe habilitar el modo de Aplicación completa para evitar el ataque de elevación. También podría ejecutar dos instancias separadas de SCEPman, una para certificados de DC y otra para inscripción de Intune. ### Certificados de usuario y dispositivo de Jamf Pro Los certificados emitidos a través de Jamf Pro tendrán el EKU Client Authentication. Si sigue nuestra documentación, ningún tipo de certificado tendrá un nombre DNS en el 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 de DC, no debe agregar nombres DNS al SAN ni asegurarse de habilitar el modo de Aplicación completa en su dominio AD. ### Certificados de Certificate Master Hay tres maneras de emitir certificados a través del componente Certificate Master a partir de la versión 2.1 de SCEPman. [**Certificados de servidor TLS**](https://docs.scepman.com/es/administracion-de-certificados/certificate-master/tls-server-certificate-pkcs-12) no se ven afectados, ya que no contienen ni Smart Card Logon ni Client Authentication como EKU. [**Certificados de cliente manuales**](https://docs.scepman.com/es/administracion-de-certificados/certificate-master/client-certificate-pkcs-12) tampoco se ven afectados. Contienen el EKU Client Authentication, pero ninguna entrada DNS SAN. [**Solicitudes CSR personalizadas**](https://docs.scepman.com/es/administracion-de-certificados/certificate-master/certificate-signing-request-csr) son totalmente configurables e incluyen certificados de autenticación. Como cualquier persona que tenga acceso a la aplicación Certificate Master puede emitir un certificado de este tipo, debería tomar al menos una de las siguientes precauciones: * Asegúrese de que solo las cuentas privilegiadas puedan acceder a Certificate Master. Por ejemplo, podría [conceder acceso al componente Certificate Master](https://docs.scepman.com/es/implementacion-de-scepman/permissions/post-installation-config#granting-the-rights-to-request-certificates-via-the-certificate-master-website) solo a un único grupo AAD que diseñe como [grupo de acceso privilegiado](https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/groups-features). * Use instancias de SCEPman y certificados CA separados para certificados de DC (cuyo certificado CA está en el almacén NTAuth) y para Certificate Master. * Habilite el modo de Aplicación completa en su dominio AD. ### certificados de Domain Controller Si un atacante tiene los permisos de acceso necesarios para emitir certificados de Controlador de Dominio, probablemente ya tenga control sobre un Controlador de Dominio y sea propietario del dominio. El atacante no necesita el ataque Certifried.