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.

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

Die nachfolgenden Schritte sollten niemals in einer produktiven Umgebung durchgeführt werden. Bei der hier durchgeführten Demonstration handelt es sich nicht um eine Anleitung zum Einbrechen in Computersysteme, sie soll vielmehr das Sicherheitsrisiko aufzeigen, um Gegenmaßnahmen einleiten zu können.

Um das Active Directory anzugreifen, bietet sich der als Smartcard Logon bezeichnete Mechanismus an. Hierbei meldet sich der Benutzer mittels eines von einer Zertifizierungsstelle ausgestellten Zertifikats an. Die Identität des Benutzers ist im Zertifikat "Subject Alternative Name" (SAN) vom Typ "User Principal Name" (UPN) abgebildet.

Ein Domänencontroller, welcher die Anmeldung des Benutzers erfolgreich geprüft hat, wird dann das gleiche Feld im Active Directory aufsuchen und dem anmeldenden Benutzer ein entsprechendes Ticket Granting Ticket (TGT) ausstellen – inklusive der Berechtigungen dieses Benutzers.

Der Domänencontroller delegiert hierbei die korrekte Identifikation des Benutzers an die Zertifizierungsstelle. Sie ist dafür verantwortlich, dass die digitale Identität tatsächlich der dahinterstehenden natürlichen Person zugeordnet ist.

Auch eine fehlerhaft konfigurierte Zertifizierungsstelle, Zertifikatvorlage oder Schnittstelle kann zur Ausstellung eines für diesen Angriff verwendbaren Zertifikats missbraucht werden.

Ist der private Schlüssel der Zertifizierungsstelle kompromittiert, können Signaturen gefälscht werden. Dadurch wäre ein Angreifer in der Lage, jede beliebige Identität im Active Directory anzunehmen, inklusive administrativer Konten.

Ein Diebstahl der privaten Schlüssel wird durch die Verwendung von Hardware Security Modulen (HSM) auf den Zertifizierungsstellen wirksam verhindert. Bei HSMs handelt es sich um spezielle Hardwaregeräte, die u.A. die Verwendung eines kryptographischen Schlüssels durch berechtigte Teilnehmer (etwa eine Zertifizierungsstelle) ermöglichen, aber die Anfertigung von Kopien des Schlüssels unterbinden.

Es verbleibt aber auch bei Verwendung von Hardware Security Modulen noch ein Angriffsvektor über die Zertifizierungsstelle selbst: Damit diese mit dem HSM kommunizieren kann, ist eine vom HSM-Hersteller bereitgestellte Middleware, ein Key Storage Provider (KSP) auf dem dazugehörigen Server installiert. Dieser ermöglicht Programmen, verschiedenste Schlüsselspeicher (z.B. Smartcard, Trusted Platform Modul, Software, Hardware Security Modul) über eine einheitliche Schnittstelle anzusprechen.

Die Zertifizierungsstelle läuft im Sicherheitskontext des Computerkontos (SYSTEM). Gelingt es einem Angreifer, sich administrative Rechte auf einer Zertifizierungsstelle zu erschleichen, kann er mit entsprechender Software den KSP direkt ansprechen, und Signaturen auslösen.

Aus Gründen der Vereinfachung werden die Wege, wie sich ein Angreifer Systemrechte auf einer CA verschafft, nicht besprochen, da diese allgemeingültig für Windows Server sind.

Entsprechende Software ist in einschlägigen Kreisen seit spätestens 2017 verfügbar und existiert auch in Form quelloffener Projekte. Da es sich beim Signieren von Zertifikaten um einen ganz legitimen technischen Vorgang handel, können auch Administrations-Werkzeuge wie das PSCertificateEnrollment PowerShell Modul oder gar Windows-Bordmittel für einen solchen Zweck eingesetzt werden.

Mit dem resultierenden Zertifikat kann sich der Angreifer dann an der Domäne anmelden.

Ihm werden dann die Berechtigungen des impersonierten Benutzers zugewiesen (im Beispiel Enterprise Administrator).

Gegenmaßnahmen

Folgende Möglichkeiten bieten sich an, dem Problem entgegenzuwirken:

Entfernen aller Zertifizierungsstellen, für die keine Smartcard-Anmeldung gewünscht ist, aus dem NTAuthCertificates Objekt der Active Directory Gesamtstruktur entfernen (sofern keine anderen Dienste das Zertifikat hier benötigen). Siehe Artikel "Bearbeiten des NTAuthCertificates Objektes im Active Directory".
Grundlagen: Einschränken der erweiterten Schlüsselverwendung (Extended Key Usage, EKU) in Zertifizierungsstellen-Zertifikaten.
Ausstellen von Domänencontroller-Zertifikaten, die keine Smartcard-Anmeldung ermöglichen, wenn Smartcard-Anmeldungen im Unternehmen nicht gewünscht sind. Siehe Artikel "Konfigurieren einer Zertifikatvorlage für Domänencontroller".
Domänencontroller (oder andere Teilnehmer) zwingen, einen Onlineresponder (OCSP) zu verwenden und dies mit dem deterministic Good kombinieren, um einen Auditierungspfad für die durchgeführten Anmeldungen zu erhalten und Anmeldungen mit unbekannten Zertifikaten zu unterbinden.
Unsichere Schnittstellen (wie SCEP) und Zertifikatvorlagen, welche eine Angabe der Identität durch den Antragsteller erlauben, können mit dem TameMyCerts Policy Modul für die Microsoft-Zertifizierungsstelle wirksam eingeschränkt werden.

Weiterführende Links:

Externe Quellen

Guidelines for enabling smart card logon with third-party certification authorities (Microsoft)

Gegenmaßnahmen

Weiterführende Links:

Externe Quellen

17 Gedanken zu „Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus“