# Vulnerabilidade de SID-Spoofing

Dirk-jan Mollema descreveu recentemente [como estender ataques do tipo Certifried ao Intune](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Embora ele tenha usado AD CS e NDES no artigo, os problemas descritos não são específicos deles e, em geral, se aplicam a todas as PKIs que usam o Intune para o registro via SCEP, incluindo o SCEPman.

No entanto, existem algumas restrições adicionais para outras PKIs. O mais importante é que, como isso se baseia na vulnerabilidade geral [Certifried vulnerability](https://docs.scepman.com/pt/outros/troubleshooting/certifried), é necessário que o certificado da CA esteja no armazenamento NTAuth do domínio. Embora o AD CS esteja, por padrão, no armazenamento NTAuth, o SCEPman não está, portanto os utilizadores do SCEPman só podem ser afetados se tiverem adicionado explicitamente o certificado da CA ao armazenamento NTAuth. Se você não o fez, está seguro. Alguns casos de uso exigem, porém, a adição do certificado da CA ao armazenamento NTAuth, nomeadamente [certificados de Domain Controller](https://docs.scepman.com/pt/gerenciamento-de-certificados/domain-controller-certificates) e [autenticação RDP baseada em certificados](https://docs.scepman.com/pt/implantacao-do-scepman/deployment-guides/scenarios/certificate-based-authentication-for-rdp). Se o certificado da sua CA estiver no armazenamento NTAuth e você ativar o registro do Intune no SCEPman, isso normalmente permitirá que os seus administradores do Intune explorem isto e registem certificados com os quais podem tomar controlo do domínio, ou seja, os seus administradores do Intune devem ser tratados como administradores Tier-0.

Mas Dirk-jan descreveu outro problema, mais grave. O Intune aparentemente não verifica se um SID fornecido pelo utilizador corresponde ao atributo onPremisesSecurityIdentifier do utilizador ou do dispositivo, anulando as mitigações que a Microsoft implementou com a sua aplicação da Strong Mapping. Um utilizador sem privilégios elevados (bem, direitos de administrador local na sua máquina podem ou não ser necessários) pode registar um certificado com o SID de outro utilizador. O utilizador ainda precisa de colocar o UPN do outro utilizador no certificado, para o que atualmente não conhecemos uma exploração existente, mas é um obstáculo de segurança a menos. Para certificados de dispositivo, é ainda pior e Dirk-jan delineou os requisitos específicos com os quais um utilizador normal pode registar um certificado que lhe permite autenticar-se como o sistema Domain Controller e tomar controlo da máquina.

Se você tiver o certificado da CA do SCEPman no armazenamento NTAuth e quiser impedir o ataque, pode definir [AppConfig:IntuneValidation:AllowRequestedSidExtension](https://docs.scepman.com/pt/configuracao-do-scepman/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-allowrequestedsidextension) para *falso*. Isto irá filtrar extensões SID, incluindo as falsificadas. Este também é o valor predefinido para esta definição no SCEPman 2.11.1460 ou mais recente. Versões anteriores do SCEPman também removem os URIs SID da extensão SAN que normalmente são legítimos se você configurar esta definição, podendo impedir casos de uso válidos.