Security – 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.

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.

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

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

Ein Policy Modul, um sie zu bändigen: Vorstellung des TameMyCerts Policy Moduls für Microsoft Active Directory Certificate Services

Als Betreiber einer Zertifizierungsstelle ist man (unter Anderem) für die Identifikation der Antragsteller und die Bestätigung der beantragten Identitäten verantwortlich. Dass diese Aufgabe gewissenhaft und fehlerfrei ausgeführt wird, ist der zentrale Grundpfeiler für das Vertrauen, das der Zertifizierungsstelle eingeräumt wird. Namhafte Unternehmen sind bereits an dieser Aufgabe gescheitert, mussten in Folge von Falschausstellungen sogar Insolvenz anmelden und/oder wurden durch die großen Player am Markt empfindlich bestraft.

In vielen Fällen sind wir als (Microsoft-)PKI-Betreiber in Unternehmen (ungeachtet der damit einhergehenden Qualität) in der Lage, unsere Aufgabe der eindeutigen Identifikation eines Antragstellers an das Active Directory zu delegieren. In vielen Fällen müssen wir unsere Zertifizierungsstelle(n) aber leider auch anweisen, einfach alles auszustellen, was beantragt wird.

Aktivieren der Basic Authentication für den Registrierungsdienst für Netzwerkgeräte (NDES)

Wird der Registrierungsdienst für Netzwerkgeräte (NDES) neu installiert (Vorzugsweise ohne Enterprise Administrator Berechtigungen), wird zunächst nur die Windows-integrierte Authentisierung für die Administrations-Webseite aktiviert. Mit dieser ist (per NT LAN Manager, NTLM) Protokoll auch eine Authentisierung per Benutzername und Passwort möglich. Nicht alle Client-Anwendungen unterstützen diese jedoch.

Ebenso könnte ein Unternehmen gewillt sein, NTLM wo möglich zu deaktivieren und Kerberos für die Anmeldung zu erzwingen. Mit dem Erzwingen von Kerberos fällt die Möglichkeit weg, sich per Benutzername und Passwort an der Administrations-Seite für den Registrierungsdienst für Netzwerkgeräte anzumelden (da dies mit NTLM-Anmeldedaten erfolgt). Um hier wieder eine Möglichkeit zu schaffen, kann jedoch die Basic Authentication nachgerüstet werden.

Einen Ausweg aus diesem Dilemma kann die Basic Authentisierung sein, deren Einrichtung im folgenden dargelegt werden soll.

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.

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

Mit dem Patch vom 10. Mai 2022 versucht Microsoft, eine Sicherheitslücke im Active Directory zu schließen, in welcher die zertifikatbasierte Anmeldung (im Allgemeinen bekannt als PKINIT oder auch Smartcard Logon) zu schließen.

Das Update ändert sowohl das Verhalten der Zertifizierungsstelle als auch das Verhalten des Active Directory beim Verarbeiten von zertifikatbasierten Anmeldungen.

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.

Grenzen der Microsoft Active Directory Certificate Services

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory besierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

Gerne wird auf die vielen Möglichkeiten hingewiesen, welche die Active Directory Certificate Services bieten. Selten wird allerdings darauf verwiesen, was mit ihnen nicht möglich ist. Das Produkt stößt nämlich mittlerweile an vielen Stellen auch an seine Grenzen.

Welche das sind, soll nachfolgend näher ausgeführt werden, um besser entscheiden zu können, ob die AD CS für geplante Vorhaben die richtige Lösung sein können.

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.

Konfigurieren der Trusted Platform Module (TPM) Key Attestation

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.

Um sicherzustellen, dass der private Schlüssel einer Zertifikatanforderung wirklich mit einem Trusted Platform Modul geschützt wurde verbleibt also nur die TPM Key Attestation.

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.

Gibt es eine Abhängigkeit des Registrierungsdienstes für Netzwerkgeräte (NDES) mit dem NTAuthCertificates Objekt?

Der Registrierungsdienst für Netzwerkgeräte (NDES) verfügt über zwei Registration Authority Zertifikate. Mit dem Enrollment-Agenten-Zertifikat werden Zertifikatanforderungen signiert und man kann die NDES-Gerätevorlage entsprechend konfigurieren, sodass Zertifikate auch nur dann ausgestellt werden, wenn die eingereichten Zertifikatanforderungen auch eine entsprechende Signatur aufweisen.

Plant man, die mit dem NDES verbundene Zertifizierungsstelle aus dem NTAuthCertificates Objekt zu entfernen, kommt eventuell die Frage auf, ob hier wechselseitige Abhängigkeiten zu berücksichtigen sind – schließlich erfordert Enroll on Behalf Of (EOBO) das Vorhandensein des Zertifizierungsstellen-Zertifikats in NTAuthCertificates.

Deutsch