# SID-Spoofing-Sicherheitslücke

Dirk-jan Mollema hat kürzlich [beschrieben, wie man Certifried-ähnliche Angriffe auf Intune ausweiten kann](https://dirkjanm.io/extending-ad-cs-attack-surface-intune-certs/). Zwar verwendete er im Artikel AD CS und NDES, die beschriebenen Probleme sind jedoch nicht spezifisch dafür und gelten im Allgemeinen für alle PKIs, die Intune für SCEP-Enrolment verwenden, einschließlich SCEPman.

Es gibt jedoch einige zusätzliche Einschränkungen für andere PKIs. Am wichtigsten ist, dass dies auf der allgemeinen [Certifried-Schwachstelle](https://docs.scepman.com/de/sonstiges/troubleshooting/certifried) aufbaut und daher erfordert, dass das CA-Zertifikat im NTAuth-Store der Domäne vorhanden ist. Während AD CS standardmäßig im NTAuth-Store enthalten ist, ist SCEPman das nicht. Daher können SCEPman-Benutzer nur betroffen sein, wenn sie das CA-Zertifikat explizit zum NTAuth-Store hinzugefügt haben. Wenn Sie das nicht getan haben, sind Sie sicher. Es gibt jedoch einige Anwendungsfälle, die das Hinzufügen des CA-Zertifikats zum NTAuth-Store erfordern, insbesondere [Domänencontroller-Zertifikate](https://docs.scepman.com/de/zertifikatsverwaltung/domain-controller-certificates) und [zertifikatsbasierte RDP-Authentifizierung](https://docs.scepman.com/de/scepman-bereitstellung/deployment-guides/scenarios/certificate-based-authentication-for-rdp). Wenn sich Ihr CA-Zertifikat im NTAuth-Store befindet und Sie die Intune-Enrolment auf SCEPman aktivieren, können Ihre Intune-Admins dies in der Regel ausnutzen und Zertifikate enrolen, mit denen sie die Domäne übernehmen können, d. h. Ihre Intune-Admins sollten als Tier-0-Admins behandelt werden.

Doch Dirk-jan beschrieb noch ein weiteres, schwerwiegenderes Problem. Intune prüft offenbar nicht, ob eine vom Benutzer angegebene SID mit dem onPremisesSecurityIdentifier-Attribut des Benutzers oder Geräts übereinstimmt, und hebt damit die von Microsoft mit der Durchsetzung von Strong Mapping ergriffenen Gegenmaßnahmen auf. Ein Benutzer ohne erhöhte Rechte (nun ja, lokale Administratorrechte auf seinem Gerät können notwendig sein oder auch nicht) kann ein Zertifikat mit der SID eines anderen Benutzers enrolen. Der Benutzer muss dennoch die UPN des anderen Benutzers in das Zertifikat bekommen; hierfür kennen wir derzeit keinen bekannten Exploit, aber es ist eine Sicherheitsbarriere weniger. Bei Gerätezertifikaten ist es sogar noch schlimmer, und Dirk-jan erläuterte die genauen Voraussetzungen, unter denen ein normaler Benutzer ein Zertifikat enrolen kann, das es ihm ermöglicht, sich als Domänencontroller-System zu authentifizieren und das Gerät zu übernehmen.

Wenn Sie das SCEPman-CA-Zertifikat im NTAuth-Store haben und den Angriff verhindern möchten, können Sie [AppConfig:IntuneValidation:AllowRequestedSidExtension](https://docs.scepman.com/de/scepman-konfiguration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-allowrequestedsidextension) nach *false* setzen. Dadurch werden SID-Erweiterungen, einschließlich gefälschter, herausgefiltert. Dies ist auch der Standardwert für diese Einstellung in SCEPman 2.11.1460 oder neuer. Frühere Versionen von SCEPman entfernen bei Aktivierung dieser Einstellung außerdem SID-URIs aus der SAN-Erweiterung, die normalerweise legitim sind, und könnten dadurch gültige Anwendungsfälle verhindern.