Subject Alternative Name (SAN) – Uwe Gradenegger

Wie das Absichern von Druckern zum Security-Desaster werden kann – und wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) diese verhindern kann

In der heutigen Zeit ist es unumgänglich, die Authentisierung von Geräten am Unternehmens-Netzwerk sowie administrative Schnittstellen zu schützen. In der Regel kommen hierbei auf digitale Zertifikate zum Einsatz.

Auch Drucker benötigen somit in der Regel digitale Zertifikate, um sicher betrieben werden zu können. Ab einer gewissen Anzahl von Geräten kommt man um eine automatische Zertifikatverteilung nicht mehr herum.

Manche Drucker-Hersteller bieten für die Zertifikatverteilung zentrale Management-Lösungen an.

Leider zeigt sich immer wieder, dass der sichere Umgang digitalen Zertifikaten viel Wissen, Erfahrung und Sorgfalt erfordert, was leider oft nicht gegeben ist.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) dabei helfen kann, Szenarien mit Microsoft Intune und anderen Mobile Device Management (MDM) Systemen abzusichern

Unternehmen verwenden Mobile Device Management (MDM) Produkte um mobile Geräte wie Smartphones, Tablet-Computer oder Desktopsysteme über das Internet (Over-the-Air, OTA) zu verwalten, zu konfigurieren und zu aktualisieren.

Gängige Mobile Device Management Produkte sind:

Microsoft Intune
VMware Workspace One (zuvor bekannt unter dem Markennamen AirWatch)
Ivanti MobileIron UEM
Jamf Pro
Baramundi Enterprise Mobility Management
BlackBerry Enterprise Mobility Suite
Sophos Mobile Control
SOTI MobiControl

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) eingehende Zertifikatanträge reparieren kann, um sie RFC-konform zu machen

Beginnend mit Version 58 hat Google beschlossen, im Chrome Browser die Unterstützung für den Subject Distinguished Name von Webserver-Zertifikaten zu entfernen und stattdessen nur noch Zertifikate mit Subject Alternative Name zu akzeptieren.

Seit diesem Moment werden Webserver-Zertifikate ohne Subject Alternative Name in Form eines dNSName von Google Chrome und anderen Chromium-basierten Browsern (also auch Microsoft Edge) abgelehnt. Andere Browserhersteller haben diesen Ansatz schnell übernommen, sodass dieses Problem mittlerweile alle gängigen Browser betrifft.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen den ESC1 Angriffsvektor verhindern kann

Angriffe auf Microsoft Zertifizierungsstellen können auf das Ausnutzen von Berechtigungen auf Zertifikatvorlagen abzielen. In vielen Fällen müssen Zertifikatvorlagen konfiguriert werden, dem Antragsteller das Recht einzuräumen, beliebige Identitäten beantragen zu können. Dies kann zur Übernehme der Identitäten von Active Directory Konten und in Folge zur Erhöhung von Rechten durch den Angreifer führen. Angriffe dieser Art werden in der Security Szene als "ESC1" bezeichnet.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) Angriffe gegen die ESC6 und ESC7 Angriffsvektoren erkennen und verhindern kann

In der vermeintlich guten Absicht, damit die Ausstellung solcher Zertifikatanforderungen mit einem SAN möglich zu machen, raten leider viel zu viele Anleitungen dazu, auf der Zertifizierungsstelle das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 zu aktivieren.

Aktiviert man dieses Flag, wird eine sehr große Angriffsfläche geboten, da nun jeder Antragsteller die Zertifizierungsstelle anweisen kann, Zertifikate mit beliebigen Inhalten auszustellen. Diese Art von Angriffen ist in der Security-Szene als ESC6 und ESC7 bekannt.

DNS-Namen automatisch in den Subject Alternate Name (SAN) ausgestellter Zertifikate eintragen – mit dem TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services (ADCS)

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 dieses nicht mehr erfüllen.

Für uns ist folgender Satz von großer Brisanz:

If 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

Den Subject Alternative Name (SAN) eines Zertifikats vor dessen Ausstellung verändern – aber sicher!

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.

Grundlagen: Namenseinschränkungen (Name Constraints)

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.

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: 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.

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.

Details 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.

Deutsch