# Vulnerabilidad de suplantación de SID

Dirk-jan Mollema recientemente [describió cómo extender ataques tipo 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, en general, se aplican a todas las PKI que usan Intune para el registro SCEP, incluido SCEPman.

Sin embargo, existen algunas restricciones adicionales para otras PKI. Lo más importante es que, como 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á, así que los usuarios de SCEPman solo pueden verse afectados si añadieron explícitamente el certificado de la CA al almacén NTAuth. Si no lo has hecho, estás a salvo. No obstante, algunos casos de uso requieren añadir el certificado de la CA al almacén NTAuth, en particular [certificados de Domain Controller](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á a tus administradores de Intune aprovecharlo y registrar certificados con los que pueden tomar el control del dominio; es decir, tus administradores de Intune deben ser tratados como administradores de nivel 0.

Pero Dirk-jan describió otro problema, más grave. Intune aparentemente no comprueba si un SID proporcionado por el usuario coincide con el atributo onPremisesSecurityIdentifier del usuario o del dispositivo, anulando las mitigaciones que Microsoft ha emprendido con la aplicación de Strong Mapping. Un usuario sin privilegios elevados (bueno, los privilegios de administrador local en su máquina pueden o no ser necesarios) 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 un obstáculo de seguridad menos. Para los certificados de dispositivo, es incluso peor y Dirk-jan describió los requisitos específicos con los que un usuario normal puede registrar un certificado que le permite autenticarse como sistema de Domain Controller y tomar el control de la máquina.

Si tienes el certificado de la CA de SCEPman en el almacén NTAuth y quieres evitar 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 *falso*. Esto filtrará las extensiones SID, incluidas las falsificadas. Este también es el valor predeterminado de esta configuración en SCEPman 2.11.1460 o posterior. Las versiones anteriores de SCEPman también eliminan de la extensión SAN los URI SID que normalmente son legítimos si configuras esta opción, lo que potencialmente puede impedir casos de uso válidos.