Smartcard Logon – Uwe Gradenegger

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754)

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

Domänencontroller (oder andere Teilnehmer) zwingen, einen Onlineresponder (OCSP) zu verwenden

In der Standardeinstellung werden Windows-Systeme, auch wenn ein Onlineresponder (OCSP) konfiguriert ist, nach einer bestimmten Anzahl von OCSP-Anfragen auf eine (falls vorhanden) Sperrliste zurückfallen, weil dies in einem solchen Fall meistens effizienter ist. Nicht immer ist dieses Verhalten aber gewünscht.

Setzt man beispielsweise Smartcard-Anmeldungen ein, möchte man vielleicht wissen, ob Anmeldungen mit unberechtigt ausgestellten Zertifikaten ausgeführt wurden. In Verbindung mit dem deterministischen Good des Onlineresponders kann man so einen (beinahe) lückenlosen Auditierungspfad für alle Smartcard-Anmeldungen schaffen.

Konfigurieren einer Zertifikatvorlage für Domänencontroller

Auch bei einer vermeintlich simpel zu konfigurierenden Zertifikatvorlage für Domänencontroller gibt es einiges zu beachten.

Smartcard Anmeldung im Netzwerk unterbinden

Installiert man die Active Directory Zertifikatdienste in der Standard-Konfiguration, wird die Umgebung automatisch dafür konfiguriert, dass Smartcard-Anmeldungen von den Domänencontrollern akzeptiert werden.

Wenn die Verwendung von Smartcard Anmeldungen nicht gewünscht ist, ist es daher sinnvoll, die Funktionalität abzustellen, um im Falle der Kompromittierung der Zertifizierungsstelle das Active Directory nicht zu gefährden.

Automatisches Ändern der Passwörter für Konten, die eine Anmeldung via Smartcard oder Windows Hello for Business erfordern

Eine neue Funktion von Windows Server 2016 ist, dass die Passwörter für Konten, die eine reine Anmeldung mit Smartcards erfordern, gemäß den Passwortlichtlinien automatisch erneuert werden.

Wird die Option "Smart card is required for interactive logon" für ein Benutzerkonto aktiviert, wird das Kennwort des Benutzerkontos einmalig auf einen zufälligen Wert gesetzt. Das Passwort ändert sich jedoch anschließend nie mehr, was das Konto anfälliger für Pass-the-Hash Angriffe macht.

Die neu eingeführte Funktion löst dieses Problem, indem für entsprechende Konten regelmäßig (in Abhängigkeit der für das Konto konfigurierten Passwortrichtlinie) neue zufallsgenerierte Passwörter erzeugt werden.

Verwenden von Authentication Mechanism Assurance (AMA) für die Absicherung der Anmeldung administrativer Konten

Bei der Authentication Mechanism Assurance (AMA) handelt es sich um eine Funktion, welche sicherstellen soll, dass ein Benutzer nur dann Mitglied einer Sicherheitsgruppe ist, wenn er sich nachweislich mit einer starken Authentifizierunsmethode (also einer Smartcard) angemeldet hat. Meldet sich der Benutzer stattdessen via Benutzername und Kennwort an, hat er keinen Zugriff auf die angeforderten Ressourcen.

Ursprünglich für den Zugriff auf Dateiserver gedacht, kann man die AMA (mit einigen Einschränkungen) jedoch auch für die administrative Anmeldung verwenden. Somit wäre es beispielsweise denkbar, dass ein Benutzer unprivilegiert ist, wenn er sich mit Benutzername und Passwort anmeldet, und über administrative Rechte verfügt, wenn er sich mit einem Zertifikat anmeldet.

Die Anmeldung via Smartcard schlägt fehl mit Fehlermeldung "Signing in with a security device isn’t supported for your account."

Folgendes Szenario angenommen:

Ein Benutzer verfügt über ein Smartcard Logon Zertifikat und meldet sich mit diesem an der Active Directory Domäne an.
Die Anmeldung schlägt fehl. Folgende Fehlermeldung wird dem Benutzer an seinem Computer zurückgegeben:

Signing in with a security device isn't supported for your account. For more info, contact your administrator.

Konfigurieren einer Zertifikatvorlage für Authentication Mechanism Assurance (AMA)

Die Authentication Mechanism Assurance (AMA) bietet die Möglichkeit, die Mitgliedschaft in einer Sicherheitsgruppe an die Anmeldung mit einem Smartcard Zertifikat, welches einen bestimmten Object Identifier (OID) enthält, zu binden.

Meldet sich der Benutzer nicht mit dem Smartcard Zertifikat, sondern mit Benutzername und Passwort an, ist er auch nicht Mitglied der Sicherheitsgruppe.

Nachfolgend wird beschrieben, wie eine Zertifikatvorlage für die Nutzung mit der Authentication Mechanism Assurance erzeugt werden kann.

Die Anmeldung via Smartcard schlägt fehl mit Fehlermeldung "The revocation status of the authentication certificate could not be determined."

Folgendes Szenario angenommen:

Ein Benutzer verfügt über ein Smartcard Logon Zertifikat und meldet sich mit diesem an der Active Directory Domäne an.
Die Anmeldung schlägt fehl. Folgende Fehlermeldung wird dem Benutzer an seinem Computer zurückgegeben:

The revocation status of the authentication certificate could not be determined.

Erstellen einer virtuellen Smartcard in einem Hyper-V Gastsystem

Für Testumgebungen ist es oft hilfreich, mit Smartcards arbeiten zu können. Nachfolgend eine kurze Anleitung, wie eine virtuelle Smartcard in einem Hyper-V Gast mit Hilfe eines virtualisierten Trusted Platform Moduls (TPM) eingerichtet werden kann.

Domänencontroller-Zertifikatvorlagen und Smartcard Anmeldung

Damit Domänencontroller Smartcard Anmeldungen verarbeiten können, benötigen sie Zertifikate, welche diese Funktion bereitstellen.

Bearbeiten des NTAuthCertificates Objektes im Active Directory

In der Standardkonfiguration befinden sich alle Zertifizierungsstellen-Zertifikate von ins Active Directory integrierten Zertifizierungsstellen (Enterprise Certification Authority) in einem Objekt vom Typ CertificationAuthority namens NTAuthCertificates innerhalb der Configuration Partition der Active Directory Gesamtstruktur.

Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus

Vereinfacht ausgedrückt kann man Public Key Kryptographie auf die Annahme reduzieren, dass der private Teil eines jeden Schlüsselpaares nur dessen Inhaber bekannt ist.

Eine Zertifizierungsstelle ist für die korrekte Identifikation von Benutzern, Computern oder Ressourcen zuständig. Ihren ausgestellten Zertifikaten wird deshalb ein Vertrauensstatus eingeräumt, weil alle Teilnehmer der Annahme sind, dass ihr privater Schlüssel nur ihr bekannt ist.

Gelingt es einem Angreifer, Kenntnis des privaten Schlüssels einer Zertifizierungsstelle zu erlangen, oder zumindest Signaturen mittels des privaten Schlüssels durchzuführen, ist die Integrität der Zertifizierungsstelle nicht länger gewährleistet.

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.

Deutsch