Domänencontroller überprüfen erweiterte Schlüsselverwendung (Extended Key Usage) bei Smartcard Anmeldung nicht

Wer die Smartcard Logon Funktion im Unternehmen verwenden möchte, ist gut beraten, für eine möglichst starke Sicherheitshärtung seiner Zertifizierungsstelle zu sorgen. Hierzu zählen einige essentielle Maßnahmen:

Entfernen aller nicht notwendigen Zertifizierungsstellen-Zertifikate aus dem NTAuthCertificates Objekt im Active Directory: Jede Zertifizierungsstelle, welche sich in diesem Speicher befindet, ist im Active Directory für die komplette Gesamtstruktur für die Ausstellung von Smartcard Logon Zertifikaten berechtigt.
Verwenden von qualifizierter Subordinierung: Einschränken der Zertifizierungsstellen-Zertifikate, sodass diesen nur für die tatsächlich ausgestellten Extended Key Usages vertraut wird. Im Fall einer Kompromittierung der Zertifizierungsstelle ist der Schaden dann auf diese Extended Key Usages beschränkt. Das "Smart Card Logon" Extended Key Usage wäre dann nur in dem Zertifizierungsstellen-Zertifikat derjenigen Zertifizierungsstelle, die auch tatsächlich solche Zertifikate ausstellt, vorhanden.

Interessant bei diesen Gedanken ist jedoch, dass die Domänencontroller bei der Anmeldung via Smartcard die Extended Key Usages überhaupt nicht überprüfen.

Microsoft verwendet den Terminus "Enhanced Key Usage", die korrekte Bezeichnung gemäß RFC 5280 ist allerdings "Extended Key Usage".

Überprüfen des Verhaltens

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Überprüfen kann man dieses Verhalten über die Ereignisanzeige auf dem Domänencontroller, der die Anmeldung verarbeitet. Man kann die Operationen, die gegen Zertifikate stattfinden im Log der CryptoAPI (CAPI) nachverfolgen. Dieses Protokoll ist in der Standardkonfiguration aufgrund der großen Menge an anfallenden Daten deaktiviert. Es ist zu finden unter Applications and Services Logs – Microsoft – Windows – CAPI2 – Operational. Mit Rechtsklick kann man es mit dem Befehl "Enable Log" aktivieren.

Führt man nun eine Anmeldung per Smartcard durch, werden verschiedene Ereignisse betreffend des Smartcard Zertifikats protokolliert. Für uns von Interesse ist das Event mit der Nummer 11.

Im Karteireiter "Details" sieht man, dass die CertGetCertificateChain Funktion vom Local Security Authority Subsystem (lsass) Prozess aufgerufen wird. Beim Aufgruf gibt es ein Attribut "ExtendedKeyUsage", welches leer ist. Dies bedeutet, dass bei der Prüfung des Zertifikats jedes beliebige Extended Key Usage erlaubt ist.

Es handelt sich hierbei keineswegs um einen Bug: Dieses Verhalten wurde zu Zeiten von Windows Vista in den Windows Server 2008 integriert und besteht bis heute in allen Windows Server Versionen. Ziel war es damals, die Anmeldung mit digitalen Personalausweisen und vergleichbaren Ausweisdokumenten zu ermöglichen. Hier konnte nicht sichergestellt werden, ob die darauf befindlichen Zertifikate die korrekten Extended Key Usages aufweisen würden, oder überhaupt über eine solche Erweiterung verfügen. Also schaltete man die gesamte Prüfung einfach komplett ab.

Aktivierung der Prüfung der Extended Key Usages

Möchte man die Prüfung auf die Extended Key Usages wieder aktivieren, gibt es hierfür einen Registry-Schlüssel, der für den Kerberos Key Distribution Center (KDC) Prozess auf jedem Domänencontroller aktiviert werden muss. Er befindet sich unter folgendem Schlüssel:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc

Legt man dort einen DWORD (32-Bit) Wert namend SCLogonEKUnotrequired mit Wert 0 an, ist die Prüfung auf Extended Key Usages wieder aktiv.

Der KDC-Dienst muss zum Anwenden der Änderung neu gestartet werden.

Ergebniskontrolle

Führt man nun erneut eine Anmeldung via Smartcard durch und schneidet mit dem CAPI-Log mit, sieht man, dass CertGetCertificateChain nun eines der drei folgenden Extended Key Usages erwartet:

id-pkinit-KPClientAuth (1.3.6.1.5.2.3.4)
TLS/SSL Client Authentication (1.3.6.1.5.5.7.3.2)
Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

Aber auch in dieser Konstellation bleiben einige Lücken: So ist das Client Authentication Extended Key Usage sehr weit verbreitet und wird beispielsweise häufig in Verbindung mit dem Microsoft Network Policy Service (NPS) verwendet, welcher erfordert, dass sich das Zertifizierungsstellen-Zertifikat im NTAuthCertificates Objekt im Active Directory befindet.

Kann ich also mit einem beliebigen Extended Key Usage eine Smartcard Anmeldung durchführen?

Nein, das ist nicht möglich. Der KDC-Prozess scheint wiederum zu prüfen, ob das vorgezeigte Zertifikat eines der einschlägigen Extended Key Uages aufweist (zumindest legen das durchgeführte Tests zu TGT Forging mit kekeo nah: Der KDC wird das Ereignis Nr. 21 mit der Fehlermeldung "The certificate is not valid for the requested usage." protokollieren.). Der KDC führt an dieser Stelle aber keine erneute Gültigkeitsprüfung für das Zertifikat aus.

Somit kann diese Lücke immerhin wie dargestellt ausgenutzt werden, um eventuell vorhandene Einschränkungen der Extended Key Usages für Zertifizierungsstellen-Zertifikate zu umgehen.

Weiterführende Links:

Externe Quellen

Smartcard in 2008 and Vista..National ID card? No UPN? No EKU? No problem! (Microsoft, Archivlink)
Object IDs associated with Microsoft cryptography (Microsoft)