Policy Modul – 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) dieses 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.

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.

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.

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

Die "Application Policies" Zertifikaterweiterung

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 werden regelmäßig neue Zertifikate über Autoenrollment beantragt

Folgendes Szenario angenommen:

Es ist eine Zertifikatvorlage für die automatische Beantragung und Ausstellung (AutoEnrollment) konfiguriert.
Benutzer oder Computer beantragen in regelmäßigen Abständen und lange vor dem definierten Erneuerungszeitraum neue Zertifikate.

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.

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.