# Vulnérabilité de spoofing du SID

Dirk-jan Mollema a récemment [décrit comment étendre à Intune des attaques de type Certifried](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Bien qu’il ait utilisé AD CS et NDES dans l’article, les problèmes décrits ne leur sont pas spécifiques et s’appliquent généralement à tous les PKI utilisant Intune pour l’inscription SCEP, y compris SCEPman.

Cependant, il existe certaines contraintes supplémentaires pour d’autres PKI. Plus important encore, comme cela repose sur la [vulnérabilité Certifried](https://docs.scepman.com/fr/autre/troubleshooting/certifried)générale, cela exige que le certificat de l’AC soit présent dans le magasin NTAuth du domaine. Alors qu’AD CS se trouve par défaut dans le magasin NTAuth, ce n’est pas le cas de SCEPman ; les utilisateurs de SCEPman ne peuvent donc être concernés que s’ils ont explicitement ajouté le certificat de l’AC au magasin NTAuth. Si vous ne l’avez pas fait, vous êtes en sécurité. Certains cas d’usage nécessitent toutefois d’ajouter le certificat de l’AC au magasin NTAuth, notamment [certificats de contrôleur de domaine](https://docs.scepman.com/fr/gestion-des-certificats/domain-controller-certificates) et [authentification RDP basée sur un certificat](https://docs.scepman.com/fr/deploiement-scepman/deployment-guides/scenarios/certificate-based-authentication-for-rdp). Si votre certificat d’AC se trouve dans le magasin NTAuth et que vous activez l’inscription Intune sur SCEPman, cela permettra généralement à vos administrateurs Intune d’exploiter cela et d’inscrire des certificats avec lesquels ils peuvent prendre le contrôle du domaine ; autrement dit, vos administrateurs Intune doivent être considérés comme des administrateurs de niveau 0.

Mais Dirk-jan a décrit un autre problème, plus grave. Intune ne semble pas vérifier si un SID fourni par l’utilisateur correspond à l’attribut onPremisesSecurityIdentifier de l’utilisateur ou de l’appareil, annulant ainsi les mesures d’atténuation prises par Microsoft avec l’application obligatoire du Strong Mapping. Un utilisateur sans droits élevés (enfin, des droits d’administrateur local sur sa machine peuvent ou non être nécessaires) peut inscrire un certificat avec le SID d’un autre utilisateur. L’utilisateur doit toujours faire figurer le UPN de l’autre utilisateur dans le certificat, pour lequel nous ne connaissons actuellement aucune exploitation existante, mais c’est un obstacle de sécurité en moins. Pour les certificats d’appareil, c’est encore pire, et Dirk-jan a décrit les conditions spécifiques grâce auxquelles un utilisateur normal peut inscrire un certificat qui lui permet de s’authentifier en tant que système de contrôleur de domaine et de prendre le contrôle de la machine.

Si vous avez le certificat d’AC SCEPman dans le magasin NTAuth et que vous souhaitez empêcher l’attaque, vous pouvez définir [AppConfig:IntuneValidation:AllowRequestedSidExtension](https://docs.scepman.com/fr/configuration-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-allowrequestedsidextension) vers *false*. Cela filtrera les extensions SID, y compris les extensions usurpées. C’est également la valeur par défaut de ce paramètre dans SCEPman 2.11.1460 ou version ultérieure. Les versions précédentes de SCEPman suppriment également les URI SID de l’extension SAN, qui sont généralement légitimes si vous configurez ce paramètre, ce qui peut empêcher des cas d’usage valides.