PSCertificateEnrollment – Uwe Gradenegger

Neue Sicherheitslücke ESC15 in Active Directory Certificate Services entdeckt – einfach umzusetzende Gegenmaßnahmen

Für welche Zwecke ein digitales Zertifikat verwendet werden darf, wird über die Zertifikaterweiterungen "Key Usage" und "Extended Key Usage" gesteuert. In der "Extended Key Usage" Zertifikaterweiterung werden die erweiterten Schlüsselverwendungen eingetragen, für welche das Zertifikat verwendet werden darf.

Es gibt jedoch bei von einer Microsoft Zertifizierungsstelle ausgestellten Zertifikaten noch eine weitere Zertifikaterweiterung namens "Anwendungsrichtlinien" (engl. "Application Policies"), die ebenfalls eine der Extended Key Usages Erweiterung sehr ähnliche Liste enthält.

Justin Bollinger von TrustedSec hat herausgefunden, dass es bei Offline-Zertifikatanforderungen gegen Zertifikatvorlagen der Schema-Version 1 möglich ist (ähnlich wie bei der Security Identifier Erweiterung), beliebige Application Policies im Zertifikatantrag mitzusenden, welche unverändert in das ausgestellte Zertifikat übernommen werden und anschließend für einen Angriff auf die Active Directory Gesamtstruktur verwendet werden können. Der Angriff wurde auf den Namen ESC15 getauft.

Zeichenkodierung im Subject Distinguished Name von Zertifikatanforderungen und ausgestellten Zertifikaten

Üblicherweise ist die Kodierung von Zeichen und Zeichenketten in Zertifikaten kein Thema, welches die Nutzer einer PKI groß interessiert. Es gibt jedoch Fälle, in welchen die Standardeinstellungen der Zertifizierungsstelle nicht die gewünschten Ergebnisse liefern.

Deaktivieren von NTLM und erzwingen von Kerberos an der Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES)

Viele Unternehmen verfolgen die Strategie, das NT LAN Manager (NTLM) Authentisierungsprotokoll in ihren Netzwerken (weitestgehend) abzuschalten.

Auch für die Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES) ist dies möglich. Wie genau die Umsetzung erfolgt, und wie sich dadurch eventuell das Anwendungsverhalten ändert soll nachfolgend erläuert werden.

Der Schlüsselalgorithmus von Zertifikatanforderungen wird vom Policy Modul der Zertifizierungsstelle nicht überprüft

Folgendes Szenario angenommen:

Es ist eine Zertifikatvorlage für die Verwendung von auf elliptischen Kurven basierenden Schlüsseln konfiguriert (z.B. ECDSA_P256).
Als Folge dessen ist eine Mindest-Schlüssellänge von 256 Bit konfiguriert.
Es werden dennoch auch Zertifikatanforderungen, die andere ECC-Kurven oder RSA-basierte Schlüssel verwenden, signiert.

Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann

Nachfolgend möchte ich eine der breiten Öffentlichkeit vielleicht nicht unbedingt bekannte hochgefährliche PKI-Konfiguration vorstellen, die so in Unternehmensnetzwerken wahrscheinlich recht häufig angetroffen werden kann.

Ich zeige auf, wie durch Ausnutzung verschiedener unglücklicher Umstände in der Windows-PKI eine Erhöhung von Rechten, ausgehend von bloßem Netzwerkzugang bis hin zur vollständigen Übernahme des Active Directory möglich ist.

Der initiale Angriffspunkt ist in diesem Beispiel der Registrierungsdienst für Netzwerkgeräte (NDES).

Grundlagen: Einschränkung der Pfadlänge (Path Length Constraint)

Der Ende 2008 vorgeführte Angriff auf den MD5 Signaturalgorithmus konnte nur deshalb zur Erstellung eines nutzbaren gefälschten Zertifizierungsstellen-Zertifikats verwendet werden, da die angegriffene Zertifizierungsstelle keine Einschränkung der Pfadlänge konfiguriert hatte.

Die Einschränkung der Pfadlänge ist im RFC 5280 beschrieben. Die Idee dahinter ist, dass in der "Basic Constraints" Erweiterung eines Zertifizierungsstellen-Zertifikats die maximale Tiefe der Zertifizierungsstellen-Hierarchie hinterlegt wird.

Manuelle Beantragung eines Webserver-Zertifikats

Es gibt Fälle, in welchen man Webserver-Zertifikate nicht über die Microsoft Management Console direkt von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte, beispielsweise wenn das betreffende System kein Domänenmitglied ist.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).

Beantragen eines durch ein Trusted Platform Modul (TPM) geschütztes Zertifikat – ohne ein TPM zu besitzen

Seit Windows 8 ist es möglich, dass private Schlüssel für Zertifikate mit einem – sofern vorhanden – Trusted Platform Modul (TPM) geschützt werden. Dadurch ist eine Nichtexportierbarkeit des Schlüssels – auch mit Werkzeugen wie mimikatz – gegeben.

Auf den Ersten Blick ist allerdings nicht ersichtlich, dass nicht garantiert werden kann, dass auch wirklich ein TPM zum Einsatz kommt. Zwar wird keine Beantragung über die Microsoft Management Console oder AutoEnrollment möglich sein, wenn der Computer über kein TPM verfügt.

Es handelt sich jedoch bei der Konfiguration in der Zertifikatvorlage lediglich um eine Voreinstellung für den Client. Die Zertifizierungsstelle wird bei Beantragung nicht explizit prüfen, ob auch wirklich ein Trusted Platform Modul verwendet wurde.

Somit können – wenn die Zertifikatbeantragung abseits der MMC erfolgt, beliebige Parameter für den privaten Schlüssel verwendet werden.

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.

Zertifikatbeantragung für Windows-Systeme über den Registrierungsdienst für Netzwerkgeräte (NDES) mit Windows PowerShell

Möchte man Windows-Systeme mit Zertifikaten ausrüsten, welche nicht die Möglichkeit haben, direkt mit einer Active Directory integrierten Zertifizierungsstelle zu kommunizieren, oder die sich gar überhaupt nicht in der gleichen Active Directory Gesamtstruktur befinden, bleibt in den meisten Fällen nur die manuelle Installation von Zertifikaten.

Seit Windows 8.1 / Windows Server 2012 R2 befindet sich jedoch ein integrierter Client für das Simple Certificate Enrollment Protocoll (SCEP) an Bord. Serverseitig wird SCEP über den Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) in der Microsoft-PKI seit Windows Server 2003 implementiert.

Eine besonders interessante Eigenschaft von SCEP ist, dass das Protokoll eine Erneuerung eines Zertifikats unter Angabe eines bereits vorhandenen erlaubt. Was läge also näher, als diese Schnittstelle zu verwenden? Was noch fehlt, ist eine entsprechende Automatisierung über die Windows PowerShell.

Authentifizierung am Registrierungsdienst für Netzwerkgeräte (NDES) mit einem existierenden Zertifikat (Renewal-Modus)

Der Registrierungsdienst für Netzwerkgeräte (NDES) verfügt über die Möglichkeit, sich mit einem bereits ausgestellten Zertifikat zu authentifizieren, um ein inhaltlich gleiches Zertifikat erneut zu beantragen. Dies ist sehr praktisch für Erneuerungs-Operationen, da somit der Bedarf entfällt, vorher ein One-Time Passwort zu beantragen.

Manuelle Beantragung eines Domänencontroller-Zertifikats

Es gibt Fälle, in welchen man Domain Controller Zertifikate nicht von einer Zertifizierungsstelle in der eigenen Active Directory Gesamtstruktur beziehen kann oder möchte.

In diesem Fall ist die Verwendung von Zertifikatvorlagen nicht möglich, und man muss manuell einen Zertifikatantrag (Certificate Signing Request, CSR erstellen).