Gefährdung der Active Directory Gesamtstruktur durch das Flag EDITF_ATTRIBUTESUBJECTALTNAME2

Autor Uwe GradeneggerVeröffentlicht am Kategorien Active Directory, Penetration Testing, Security, SmartcardSchlagwörter , , , , , , , ,

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.

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

Hintergrund

Kennen Sie TameMyCerts? TameMyCerts ist ein Add-On für die Microsoft Zertifizierungsstelle (Active Directory Certificate Services). Es erweitert die Funktion der Zertifizierungsstelle und ermöglicht die Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikat-Ausstellungen zu realisieren. TameMyCerts ist einzigartig im Microsoft-Ökosystem, hat sich bereits in unzähligen Unternehmen auf der ganzen Welt bewährt und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden. Professionelle Wartung wird ebenfalls angeboten.

Ist die Einstellung für die Ausstellen von Zertifikaten mit SAN-Erweiterung erforderlich?

Klares Nein!

Beinhaltet der Zertifikatantrag bereits eine SAN-Erweiterung, kann diese durch die Zertifizierungsstelle auch bei manueller Antragstellung ausgestellt werden. Für diesen Zweck ist der Objektidentifizierer für die SAN-Zertifikaterweiterung im Policy-Modul der Zertifizierungsstelle in der Standardeinstellung bereits unter "EnableEnrolleeRequestExtensionList" eingetragen.

Die Ursache, warum die meisten im Internet und einschlägiger Literatur beschriebenen Fälle zur Aktivierung des Flag raten ist, dass die an die Zertifizierungsstelle gesendete Zertifikatanforderung (engl. Certificate Signing Request, CSR) nicht über eine SAN-Erweiterung verfügt, dies aber gewünscht ist.

Das eigentliche Problem, das die Verfasser also zu lösen versuchen, ist, die SAN-Erweiterung nachträglich der Zertifikatanforderung zuzufügen. Verändern können sie die Zertifikatanforderung aber nicht direkt, ohne deren Signatur unbrauchbar zu machen.

In der Tat ist man nach setzen des Flag in der Lage, beim Einreichen der Zertifikatanforderung beliebige Attribute – unter Anderem eben auch die SAN-Erweiterung, anzugeben – jedoch hat dies einen sehr hohen Preis.

Was bewirkt das Flag EDITF_ATTRIBUTESUBJECTALTNAME2?

Ist das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 gesetzt, kann ein Antragsteller während er die Zertifikatanforderung an die Zertifizierungsstelle schickt, zusätzliche Attribute über eine Name/Wert Kombination mit an die Zertifizierungsstelle übergeben.

Üblicherweise entscheidet die Zertifizierungsstelle anhand der in der Zertifikatvorlage gesetzten Einstellungen über den Inhalt des ausgestellten Zertifikats. Diese Entscheidung wird vom Policy Modul der Zertifizierungsstelle getroffen.

Ist das EDITF_ATTRIBUTESUBJECTALTNAME2 Flag gesetzt, werden die diesbezüglichen Einstellungen in der Zertifikatvorlage jedoch ignoriert, wenn abweichende Angaben mit der Zertifikatanforderung eintreffen.

Im Klartext bedeutet dies, dass jeder, der das Recht hat, Zertifikate von der Zertifizierungsstelle zu beantragen ("Enroll"-Berechtigung), beliebige Subject Alternative Names angeben kann, welche dann ungeprüft von der Zertifizierungsstelle in das ausgestellte Zertifikat geschrieben werden.

Da viele Anwendungen und Protokolle (unter Anderem HTTPS, siehe RFC 2818) die Identität bevorzugt über den Subject Alternative Name bilden, ermöglicht es dieser Umstand einem Angreifer, die Identitäten beliebiger anderer Benutzer – auch von Administratoren anzunehmen.

Je nach Zertifikattypen, die von der Zertifizierungsstelle angeboten werden, kann ein Angreifer hiermit verschiedene unerlaubte Aktivitäten durchführen, beispielsweise:

  • Fälschen der Identität eines Web Servers (SAN-Typ "DNS Name")
  • Versenden von signierten E-Mails in Namen eines anderen Benutzers (SAN "Typ RFC 822 Name")
  • Übernehmen der gesamten Active Directory Gesamtstruktur (SAN-Typ "User Principal Name")

Der letztere Fall soll in diesem Artikel näher beschrieben werden.

Der Angriff

Interessante Zertifikatvorlagen identifizieren

Für die Übernahme der Active Directory Gesamtstruktur wird eine Zertifikatvorlage benötigt, welche die Anmeldung via Smart Card ermöglicht.

Hierfür müssen folgende Voraussetzungen erfüllt sein:

  • Die Umgebung muss Smart Card Anmeldungen zulassen, was in den meisten Fällen möglich sein sollte.
  • Der Benutzer muss ein Zertifikat von der Vorlage beantragen können (Enroll-Berechtigung haben).
  • Das ausgestellte Zertifikat muss entweder das Extended Key Usage für Smart Card Logon oder (mit einem kleinen Trick) für Client Authentication beinhalten.
  • Der Benutzer benötigt eine Smartcard mitsamt Smartcard-Leser. Die Middleware der Smart Card muss auf einem Domänencomputer installiert sein. Alternativ können die Kerberos-Anmeldedaten auch ohne Smartcard generiert werden.

Folgende Sicherheitsmaßnahmen können umgangen werden:

  • Die Einstellung in der Zertifikatvorlage, die Identität des Antragstellers aus dem Active Directory zu bilden, kann durch das Vorhandensein von EDITF_ATTRIBUTESUBJECTALTNAME2 durch den Antragsteller zumindest für den Subject Alternative Name Teil überschrieben werden.
  • Die Einstellung in der Zertifikatvorlage, den privaten Schlüssel nicht als exportierbar zu markieren, kann vom Antragsteller außer Kraft gesetzt werden.
  • Die Einstellung in der Zertifikatvorlage, dass eine Zertifikatanforderung erst durch einen Zertifikatmanager überprüft werden kann, wird vermutlich dennoch zu einem Ergebnis führen, da die Änderung nicht beim Inspizieren der Zertifikatanforderung sichtbar ist, sondern nur im View Attributes/Extensions Dialog in der Zertifizierungsstellen-Verwaltungskonsole (certsrv.msc). Ein unbedarfter Zertifikatmanager wird die Zertifikatanforderung somit höchstwahrscheinlich freigeben.

Ein Zertifikat beantragen

Der Angreifer könnte auch eine komplett fertige Zertifikatanforderung mitbringen, und diese dann nur noch mit der Identität des Benutzers an die Zertifizierungsstelle senden. Aus Gründen der Einfachkeit und Nachvollziehbarkeit wird hier der Weg über die vorhandenen Bordmittel beschrieben.

Zunächst benötigen wir eine Zertifikatanforderung als Textdatei. Diese kann über die Zertifikatverwaltungskonsole (certmgr.msc) erzeugt werden. Dazu wird rechts auf Personal – Certificates geklickt und All Tasks – Advanced Operations – Create Custom Request… ausgewählt.

Man wird zur Angabe der Zertifikatvorlage aufgefordert.

In diesem Beispiel ist die Zertfikatvorlage für die Verwendung einer Smart Card konfiguriert, sodass das Schlüsselpaar direkt auf der Smart Card erzeugt wird.

Wenn die Zertifikatvorlage stattdessen einen softwaregestützten Cryptographic Service Provider (CSP) oder Key Storage Provider (KSP) verlangt, kann bei diesen der private Schlüssel als exportierbar eingestellt und das resultierende Zertifikat dann auf eine Smartcard importiert werden.

Die Zertifikatanforderung wird nun als Datei abgespeichert.

Im nächsten Schritt wird die Zertifikatanforderung an die Zertifizierungsstelle gesendet und dabei mit dem -attrib Argument ein Subject Alternative Name in Form des User Principal Name (UPN) des vordefinierten Enterprise Administrator Kontos angegeben.

certreq ^
-submit ^
-config "CA03.intra.adcslabor.de\ADCS Labor Issuing CA 2" ^
-attrib "SAN:upn=Administrator@intra.adcslabor.de" ^
test.req ^
test.cer

Sofern die Zertifikatanforderung konfiguriert ist, dass ein Zertifikatmanager die Anforderung überprüfen soll, so ist dies nicht in der gespeicherten Zertifikatanforderung zu sehen, sondern nur im "View Attributes/Extensions" Dialog in der Zertifizierungsstellen-Verwaltungskonsole.

Auf den ersten Blick scheint das ausgestellte Zertifikat keine auffälligen Merkmale zu haben, da in diesem Fall das Subject des Zertifikats erwartungsgemäß mit der Identität des Antragstellers befüllt ist.

Sieht man sich jedoch die Subject Alternative Name Erweiterung an, sieht man, dass hier der UPN des vordefinierten Enterprise Administrator Kontos eingetragen ist.

Nachdem das Zertifikat von der Zertifizierungsstelle abgeholt wurde, kann es mit nachfolgendem Befehl installiert werden.

certreq -accept test.cer

Auch hier ist kein Hinweis auf den abweichenden UPN zu sehen.

Anmeldung durchführen

Nun kann sich der Benutzer mit der Smart Card an einem Client anmelden. Sobald der Smart Card Leser und die eingesteckte Karte erkannt wurden, sollte eine entsprechende Auswahl zur Verfügung stehen.

In diesem Dialog sieht man die abweichenden Identitäten – oben das Subject, unten der Subject Alternative Name.

Wie man sieht, sollte nun eine Anmeldung mit dem vordefinierten Enterprise Administrator Konto stattfinden.

Eine Überprüfung ergibt, dass wir nun "Enterprise Administrator"- Berechtigungen besitzen.

Wie lautet der Trick, um Zertifikate mit Client Authentication Extended Key Usage benutzen zu können?

Sofern der Benutzer auf dem Computer, an welchem er sich anmeldet, über administrative Rechte verfügt, kann er eine lokale Gruppenrichtlinie anwenden, welche die Einschränkung auf das Smart Card Logon EKU für den Windows-Anmeldedialog deaktiviert.

Die Einstellung ist zu finden unter Computer Configuration – Administrative Tools – Windows Components – Smart Card und trägt den Namen "Allow Certificates with noch extended key usage certificate attribute".

Danach können auch Zertifikate, welche kein Smart Card Logon Extended Key Usage beinhalten, verwendet werden. Solche Zertifikatvorlagen sind deutlich häufiger anzutreffen, und oft auch ohne Anforderung, eine Smart Card zu benötigen.

Warum akzeptieren Domänencontroller Zertifikate, die kein Smart Card Logon Extended Key Usage beinhalten?

Die zuvor beschriebene Gruppenrichtlinie bewirkt lediglich, dass auf dem Client, an dem die Smart Card Anmeldung durchgeführt wird, Zertifikate, die kein Smart Card Logon Extended Key Usage beinhalten, zur Auswahl für die Anmeldung anbieten.

Im Umkehrschluss heißt dies, dass die Domänencontroller das Extended Key Usage des anmeldenden Zertifikats nicht prüfen. Dies ist in der Standardeinstellung tatsächlich der Fall, siehe hierzu Artikel "Domänencontroller überprüfen erweiterte Schlüsselverwendung (Extended Key Usage) bei Smartcard Anmeldung nicht".

Die Lösung

Das Flag EDITF_ATTRIBUTESUBJECTALTNAME2 sollte auf jeder Online-Zertifizierungsstelle niemals aktiviert bzw. dringend deaktiviert werden. Zertifikatanforderungen sollten nach Möglichkeit immer so gestellt werden, dass sie die SAN-Erweiterung bereits beinhalten. Zwar ist es manchmal nicht möglich, direkt eine solche Zertifikatanforderung zu erzeugen, aber auch für solche Fälle gibt es eine sicherere Alternative.

Wie kann ich prüfen, ob das Flag gesetzt ist?

Eine Auflistung aller Flags auf der Zertifizierungsstelle erhält man mit nachfolgendem Kommandozeilenbefehl. Ist EDITF_ATTRIBUTESUBJECTALTNAME2 nicht in Klammern und nicht eingerückt, so ist das Flag aktiv.

certutil -v -getreg Policy\Editflags

Wie kann ich das Flag deaktivieren?

Das Flag kann mit folgendem Kommandozeilenbefehl entfernt werden:

certutil -v -setreg Policy\Editflags -EDITF_ATTRIBUTESUBJECTALTNAME2

Der Zertifizierungsstellen-Dienst muss anschließend neu gestartet werden, damit die Änderungen wirksam werden.

Wie kann ich die SAN-Erweiterung auf sicherem Weg nachträglich einer Zertifikatanforderung hinzufügen?

Der ideale Weg wäre natürlich, dass der Zertifikatantrag direkt inklusive einem korrekt befüllte Subject Alternative Name gestellt wird. Dies ist aber nicht immer möglich.

Die Möglichkeiten, einen Subject Alternative Name zu einem bestehenden Zertifikatantrag hinzuzufügen habe ich im Artikel "Den Subject Alternative Name (SAN) eines Zertifikats vor dessen Ausstellung verändern – aber sicher!" beschrieben.

Das TameMyCerts Policy Modul für Microsoft Active Directory Certificate Services unterstützt das automatische Übertragen jeglicher DNS-Namen oder IP-Adressen, die im commonName eines Zertifikatantrags gefunden werden in den Subject Alternative Name ausgestellter Zertifikate, sofern diese fehlen. Wie dies funktioniert ist im Artikel "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)" beschrieben.

TameMyCerts ist ein Policy Modul, um die Microsoft Zertifizierungsstelle (Active Directory Certificate Services) abzusichern. Es erweitert die Funktionen der Zertifizierungsstelle und ermöglicht die erweitere Anwendung von Regelwerken, um die sichere Automatisierung von Zertifikatausstellungen zu ermöglichen. TameMyCerts ist einzigartig im Microsoft-Ökosystem und steht unter einer freien Lizenz. Es kann über GitHub heruntergeladen und kostenlos verwendet werden.

Weiterführende Links:

Externe Quellen

de_DEDeutsch
en_USEnglish de_DEDeutsch