# Vulnerabilidad de suplantación de SID

Dirk-jan Mollema recientemente [descríbió cómo extender ataques similares a Certifried a Intune](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Aunque en el artículo usó AD CS y NDES, los problemas descritos no son específicos de ellos y generalmente se aplican a todas las PKI que usan Intune para el registro SCEP, incluido SCEPman.

Sin embargo, hay algunas restricciones adicionales para otras PKI. Lo más importante, dado que esto se basa en la [vulnerabilidad Certifried](https://docs.scepman.com/es/otro/troubleshooting/certifried), requiere que el certificado de la CA esté en el almacén NTAuth del dominio. Mientras que AD CS está por defecto en el almacén NTAuth, SCEPman no lo está, por lo que los usuarios de SCEPman solo pueden verse afectados si agregaron explícitamente el certificado de la CA al almacén NTAuth. Si no lo has hecho, estás seguro. Algunos casos de uso requieren agregar el certificado de la CA al almacén NTAuth, sin embargo, más notablemente [certificados de Controlador de Dominio](https://docs.scepman.com/es/administracion-de-certificados/domain-controller-certificates) y [autenticación RDP basada en certificados](https://docs.scepman.com/es/implementacion-de-scepman/deployment-guides/scenarios/certificate-based-authentication-for-rdp). Si tu certificado de CA está en el almacén NTAuth y habilitas el registro de Intune en SCEPman, esto normalmente permitirá que tus administradores de Intune exploten esto y registren certificados con los que pueden tomar control del dominio, es decir, tus administradores de Intune deberían ser tratados como administradores de Nivel 0.

Pero Dirk-jan describió otro problema, más grave. Intune aparentemente no verifica si un SID proporcionado por el usuario coincide con el atributo onPremisesSecurityIdentifier del usuario o del dispositivo, anulando las mitigaciones que Microsoft ha implementado con la aplicación de Strong Mapping. Un usuario sin privilegios elevados (bueno, puede que sean necesarios o no derechos de administrador local en su máquina) puede registrar un certificado con el SID de otro usuario. El usuario todavía necesita incluir el UPN del otro usuario en el certificado, para lo cual actualmente no conocemos un exploit existente, pero es una barrera de seguridad menos. Para certificados de dispositivo, es incluso peor y Dirk-jan detalló los requisitos específicos con los que un usuario normal puede registrar un certificado que le permite autenticarse como sistema de Controlador de Dominio y tomar el control de la máquina.

Si tienes el certificado de la CA de SCEPman en el almacén NTAuth y quieres prevenir el ataque, puedes establecer [AppConfig:IntuneValidation:AllowRequestedSidExtension](https://docs.scepman.com/es/configuracion-de-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-allowrequestedsidextension) a *false*. Esto filtrará las extensiones SID, incluidas las suplantadas. Este también es el valor predeterminado para esta configuración en SCEPman 2.11.1460 o superior. Las versiones anteriores de SCEPman también eliminan URIs SID de la extensión SAN que normalmente son legítimas si configuras esta opción, potencialmente impidiendo casos de uso válidos.
