Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.
„Grundlagen: Namenseinschränkungen (Name Constraints)“ weiterlesenSchlagwort: Subject Alternative Name (SAN)
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).
„Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann“ weiterlesenGrundlagen: Konfigurationsdatei für die Zertifizierungsstelle (capolicy.inf)
Die capolicy.inf beinhaltet grundlegende Einstellungen, die vor der Installation einer Zertifizierungsstelle festgelegt werden können oder sollten. Vereinfacht ausgedrückt kann man sagen, dass keine Zertifizierungsstelle ohne sie installiert werden sollte.
„Grundlagen: Konfigurationsdatei für die Zertifizierungsstelle (capolicy.inf)“ weiterlesenSignieren 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.
„Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle“ weiterlesenZertifikatbeantragung 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.
„Zertifikatbeantragung für Windows-Systeme über den Registrierungsdienst für Netzwerkgeräte (NDES) mit Windows PowerShell“ weiterlesenDetails zum Ereignis mit ID 30 der Quelle Microsoft-Windows-NetworkDeviceEnrollmentService
| Ereignisquelle: | Microsoft-Windows-NetworkDeviceEnrollmentService |
| Ereignis-ID: | 30 (0x1E) |
| Ereignisprotokoll: | Application |
| Ereignistyp: | Fehler |
| Symbolischer Name: | EVENT_MSCEP_FAIL_ADD_ALT |
| Ereignistext (englisch): | The Network Device Enrollment Service cannot add an alternative subject name extension to the certificate request (%1). %2 |
| Ereignistext (deutsch): | Der Zertifikatanforderung kann vom Registrierungsdienst für Netzwerkgeräte keine Erweiterung für einen alternativen Antragstellernamen hingezufügt werden (%1). %2 |
Details zum Ereignis mit ID 21 der Quelle Microsoft-Windows-Kerberos-Key-Distribution-Center
| Ereignisquelle: | Microsoft-Windows-Kerberos-Key-Distribution-Center |
| Ereignis-ID: | 21 (0x80000015) |
| Ereignisprotokoll: | System |
| Ereignistyp: | Warnung |
| Ereignistext (englisch): | The client certificate for the user %1\%2 is not valid, and resulted in a failed smartcard logon. Please contact the user for more information about the certificate they’re attempting to use for smartcard logon. The chain status was : %3 |
| Ereignistext (deutsch): | Das Clientzertifikat für den Benutzer %1\%2 ist nicht gültig. Das Ergebnis war ein Fehler bei der Smartcard-Anmeldung. Wenden Sie sich an den Benutzer, um weitere Informationen über das Zertifikat zu erhalten, das für die Smartcard-Anwendung verwendet werden soll. Kettenstatus: %3 |
Konfigurieren einer Zertifikatvorlage für Domänencontroller
Auch bei einer vermeintlich simpel zu konfigurierenden Zertifikatvorlage für Domänencontroller gibt es einiges zu beachten.
„Konfigurieren einer Zertifikatvorlage für Domänencontroller“ weiterlesenDen Network Device Enrollment Service (NDES) für die Verwendung mit einem Alias konfigurieren
Nachfolgend wird beschrieben, welche Schritte erforderlich sind, um den Registrierungs dienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) für die Verwendung mit einem Alias zu konfigurieren.
Mit dem Begriff Alias ist gemeint, dass der Dienst nicht mit dem Namen des Servers, auf welchem er installiert ist, aufgerufen wird, sondern mit einem hierbon unabhängigen, generischen Namen. Die Verwendung eines Alias ermöglicht, dass der Dienst zu einem späteren Zeitpunkt auf ein anderes System umgezogen werden kann, ohne dass die neue Adresse allen Teilnehmern mitgeteilt werden muss.
„Den Network Device Enrollment Service (NDES) für die Verwendung mit einem Alias konfigurieren“ weiterlesenManuelle Beantragung eines Remotedesktop (RDP) Zertifikats
Es gibt Fälle, in welchen man Remotedesktop-Zertifikate nicht 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).
„Manuelle Beantragung eines Remotedesktop (RDP) Zertifikats“ weiterlesenZertifikate für Domänencontroller enthalten nicht den Domänennamen im Subject Alternative Name (SAN)
Folgendes Szenario angenommen:
- Es werden Zertifikate für Domänencontroller von einer Active Directory integrierten Zertifizierungsstelle (Enterprise CA) ausgestellt
- Die hierfür verwendete Zertifikatvorlage wurde selbst erzeugt
- Die ausgestellten Zertifikate enthalten im Subject Alternative Name (SAN) nur den vollqualifizierten Computernamen des jeweiligen Domänencontrollers, jedoch nicht den vollqualifizierten Namen und den NETBIOS Namen der Domäne
Erlaubte Relative Distinguished Names (RDNs) im Subject ausgestellter Zertifikate
Grundsätzlich erlaubt das RFC 5280 die Verwendung beliebiger Zeichenketten im Subject String eines Zertifikats. Gängige Felder sind im Standard X.520 beschrieben. Die Längenbeschränkungen werden ebenfalls von der ITU-T empfohlen. Die heute gängigen Abkürzungen entstammen überwiegend dem RFC 4519.
Die Microsoft Active Directory Certificate Services erlauben in der Standardeinstellung jedoch nur bestimmte RDNs.
Folgende Relative Distinguished Names (RDNs) werden in der Standardeinstellung von der Active Directory Certificate Services (ADCS) Zertifizierungsstelle angenommen:
„Erlaubte Relative Distinguished Names (RDNs) im Subject ausgestellter Zertifikate“ weiterlesenEine Zertifikatanforderung (CSR) inspizieren
Oft möchte man eine Zertifikatanforderung vor der Übermittlung an eine Zertifizierungsstelle – oder vor der Ausstellung des Zertifikats – überprüfen, ob sie die gewünschten Werte beinhaltet.
Nachfolgend wird beschrieben, wie man dies erreichen kann.
„Eine Zertifikatanforderung (CSR) inspizieren“ weiterlesenAngriffsvektor 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.
„Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus“ weiterlesenErzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate
Google ist mit dem Chromium Projekt und darauf basierenden Produkten wie Google Chrome und Microsoft Edge dazu übergegangen, das im Jahr 2000 verabschiedete RFC 2818 zu erzwingen und Zertifikaten nicht mehr zu vertrauen, welche das RFC nicht mehr erfüllen. Für uns ist folgender Satz von großer Brisanz:
„Erzeugen einer RFC 2818 konformen Zertifikatanforderung für SSL Zertifikate“ weiterlesenIf a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used. Although the use of the Common Name is existing practice, it is deprecated and Certification Authorities are encouraged to use the dNSName instead
https://tools.ietf.org/html/rfc2818