Smartcard – Uwe Gradenegger

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle

Immer wieder kommt in Diskussionen zur Sicherheit einer Zertifizierungsstelle auf, dass ein Missbrauch der Zertifizierungsstelle durch deren Sicherheitseinstellungen eingedämmt werden könnte.

Dass die Integrität einer Zertifizierungsstelle jedoch unmittelbar an ihr Schlüsselmaterial gebunden ist und sie somit durch dieses auch kompromittiert werden kann, ist auf den Ersten Blick nicht offensichtlich.

Muss man sich die Zertifizierungsstellen-Software als eine Art Management um das Schlüsselmaterial herum vorstellen. Die Software bietet beispielsweise eine Online-Schnittstelle für die Zertifikatbeantragung an, kümmert sich um die Authentifizierung der Antragsteller, um die automatisierte Durchführung von Signaturoperationen (Ausstellen von Zertifikaten und Sperrlisten) und deren Protokollierung (Zertifizierungsstellen-Datenbank, Auditprotokoll, Ereignisprotokoll).

Signaturoperationen benötigen jedoch nichts weiter als den privaten Schlüssel der Zertifizierungsstelle. Nachfolgend wird anhand eines Beispiels aufgezeigt, wie ein Angreifer, wenn er Zugang zum privaten Schlüssel der Zertifizierungsstelle erhält, Zertifikate erzeugen und ausstellen kann, ohne dass die Zertifizierungsstellen-Software und deren Sicherheitsmechanismen dies mitbekommen würden.

Mit einem solchen Zertifikat wäre es im schlechtesten Fall sogar möglich, die Active Directory Gesamtstruktur unerkannt zu übernehmen.

SSH (PuTTY) auf Windows mit einem Zertifikat / einer Smartcard verwenden

Zur sicheren Administration von Linux-System gehört, dass man SSH-Anmeldungen per Passwort vermeidet und stattdessen eine Anmeldung mit RSA Schlüsseln vornimmt.

Der de-facto Standard für SSH-Verbindungen auf Windows ist PuTTY. Hier ist eine Anmeldung mit RSA Schlüsseln zwar implementiert, jedoch können lediglich Schlüssel-Dateien verwendet werden, was den Nachteil hat, dass diese nahezu ungeschützt im Dateisystem liegen.

Eine tolle Option wäre doch sicherlich, RSA-Schlüssel aus der Windows-Welt, und vielleicht sogar gespeichert auf einer physischen oder virtuellen Smartcard einzusetzen.

Die Anmeldung via Smartcard über Remotedesktop (RDP) schlägt fehl mit Fehlermeldung "The requested key container does not exist on the smart card."

Folgendes Szenario angenommen:

Ein Benutzer meldet sich mittels Smartcard Logon Funktion auf einem Remote Desktop System an.
Der Benutzer verwendet einen Yubico Yubikey als Smartcard. Die benötigte Middleware ist sowohl auf dem lokalen als auch auf dem Remotesystem installiert.
Die Anmeldung schlägt mit folgender Fehlermeldung fehl:

The system could not log you on. The requested key container does not exist on the smart card.

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.

Eine universelle Sicherheitsgruppe mit einem Object Identifier (OID) im Active Directory Verzeichnisdienst verbinden (Authentication Mechanism Assurance)

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 man die Verbindung zwischen dem Zertifikat und der Sicherheitsgruppe herstellt.

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

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.

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.

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.

Gefährdung der Active Directory Gesamtstruktur durch das Flag EDITF_ATTRIBUTESUBJECTALTNAME2

In Netz kursieren leider viel zu viele Anleitungen (auch die großen Player sind hiervon nicht ausgenommen, nicht einmal Microsoft selbst oder der Großmeister Komar), welche fatalerweise empfehlen, dass das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 auf der Zertifizierungsstelle gesetzt werden sollte – angeblich damit man in der Lage wäre, für manuell gestellte Zertifikatanforderungen Zertifikate mit Subject Alternative Name (SAN) Erweiterung ausstellen zu können.

Leider ist diese Vorgehensweise nicht nur unnötig, sie hat auch einige unangenehme Nebenwirkungen, welche einem Angreifer im schlechtesten Fall dazu verhelfen können, die gesamte Active Directory Gesamtstruktur zu übernehmen.