Haftungsausschluss: Dieser Beitrag dient ausschließlich Bildungs- und
Informationszwecken. Die hier gezeigten Informationen und Angriffe dürfen niemals für illegale
Zwecke oder auf Systemen, für die keine explizite Erlaubnis eingeräumt wurde, verwendet werden.
Solche Handlungen können gegen geltende Gesetze verstoßen und schwerwiegende rechtliche Konsequenzen
nach sich ziehen.
Zusammenfassung
In diesem Eintrag in unserer SecCore Essentials Reihe geht es um Public Key Infrastructure (PKI) in Microsoft Active Directory Netzwerken, speziell um die Active Directory-Zertifikatsdienste (ADCS). Dieses SecCore Essential ist implementiert wenn die folgenden Punkte zutreffen:
- Die ADCS-Zertifizierungsstelle (CA) ist nicht auf einem Domänencontroller installiert.
- Es existieren keine Zertifikatsvorlagen, die es einer großen Anzahl an Accounts erlauben, ein Subject Alternative Name (SAN) zu vergeben (ESC1).
- Keine Zertifikatsvorlagen dürfen von einer großen Anzahl an Accounts bearbeitet werden (ESC4).
- Web Enrollment ist deaktiviert oder Extended Protection for Authentication1 ist aktiviert.
Einleitung
Die Active Directory Zertifikatsdienste sind ein zentraler Bestandteil von Active Directory. Sie stellt Zertifikate aus und verwaltet diese. Die ADCS Rolle besteht aus zumindest einer Zertifizierungsstelle, welche für die Ausstellung und den Widerruf von Zertifikaten zuständig ist. Moderne Installationen sollten jedoch mindestens eine Offline-Stammzertifizierungsstelle und eine Online-Zwischenzertifizierungsstelle innerhalb der Domäne haben. Diese wird für die automatische Vergabe von Zertifikaten verwendet, zum Beispiel wenn ein neuer Computer in die Domäne hinzugefügt wird. Dieser erhält dabei ein Zertifikat mit seinem Namen, um sich authentifizieren zu können. Diese Vorlagen können Access Control Lists (ACL) enthalten, um die Ausstellung von Zertifikaten einzuschränken, sowie Extended Key Usage (EKU) um festzulegen, wie Zertifikate verwendet werden dürfen. Wenn diese nicht korrekt implementiert sind, kann es zu Sicherheitsproblemen kommen.
Häufige Angriffsvektoren
Dieser Abschnitt zeigt einige ADCS-Spezifische Konfigurationsprobleme auf, die in Angriffen ausgenutzt werden können.
Fehlkonfigurierte Zertifikatsvorlage (ESC1)
Eine Zertifikatsvorlage ist anfällig für den ESC1-Angriff, wenn die folgenden Bedingungen erfüllt sind:
- Es ist niedrig privilegierten Accounts erlaubt, ein Zertifikat aus der Vorlage zu generieren
- Die Vorlage erlaubt die EKU Client Authentication (oder ähnlich) oder Any Purpose
- Der Subject Alternative Name darf frei verändert werden
- Es ist keine manuelle Freigabe erforderlich
Wenn so eine Zertifikatsvorlage existiert, ist es möglich, ein Zertifikat zur Authentifizierung für jeden beliebigen Account oder Computer in der Domäne anzufordern. Da der SAN in der Zertifikatsanfrage beliebig verändert werden kann, wird ein gültiges Zertifikat ausgestellt. Dieses kann anschließend zur Anmeldung an Computern, darunter auch dem Domain-Controller, verwendet werden.

Weitreichend berechtigte Zertifikatsvorlagen (ESC4)
Wenn der Zugang zu Zertifikatsvorlagen nicht korrekt eingeschränkt wird, oder der Besitzer dieser Vorlagen auf einen niedrig privilegierten Account oder Gruppe gesetzt werden, können diese von niedrig privilegierten Accounts bearbeitet werden. Dies kann ausgenutzt werden, um die Vorlage so zu bearbeiten, dass sie auf den ESC1 Angriff anfällig wird.
Unsicheres Web-Enrollment (ESC8)
Um die Ausstellung von Zertifikaten zu vereinfachen, stellt ADCS ein Web-Enrollment Interface2 bereit, mit welchem über den Browser und Single-Sign-On Zertifikate angefragt und ausgestellt werden können. Dies kann jedoch zu einigen Sicherheitsproblemen führen, wenn die Konfiguration nicht gehärtet wurde.
Wenn das Interface NTLM Authentifizierung und das unsichere HTTP-Protokoll unterstützt, können Zugangsdaten mithilfe eines NTLM-Relay Angriffs weitergeleitet werden. Dies funktioniert nach demselben Prinzip, wie es in den Blogeinträgen SMB Signing und LDAP Signing beschrieben wurde.
Ein Domain-Controller kann dazu gebracht werden, eine Anmeldung auszulösen, die an ein angreifendes System weitergeleitet wird. Dieses leitet die Anmeldung wiederum auf das Zielsystem, in diesem Fall das ADCS Web-Enrollment Interface, weiter.

Dies führt dazu, dass das angreifende System das Zertifikat des Domain-Controllers erhält und sich mit diesem in der Domäne anmelden kann.
Angriffsszenario
Dieser Abschnitt demonstriert, wie ADCS Schwachstellen ausgenutzt werden können, um die Active Directory Domäne vollständig zu kompromittieren. Dieses Szenario ist wie folgt aufgebaut:
- Es wurde bereits ein Client-System kompromittiert oder Zugriff auf das Netzwerk erhalten
- Zugangsdaten für ein niedrig privilegiertes Active Directory Konto wurden erlangt
- Es wurde keine Rücksicht auf OPSEC genommen, der direkteste Ansatz wurde gewählt
Nachdem bereits Zugriff auf das interne Netzwerk erlangt wurde, können mittels Certipy3 verfügbare Zertifikatsvorlagen für den aktuellen Account ausgelesen werden:
certipy find -u 'clientuser1@lab.local' -p <Password> -dc-ip 192.168.30.131 -text
Die Ausgabe dieses Befehls zeigt, dass die WIFI Zertifikatsvorlage auf ESC1 anfällig ist, da es allen Accounts erlaubt ist die Vorlage auszurollen und den Subject Alternative Name zu bearbeiten:

Mit dieser Information ist es nun möglich, ein Zertifikat für den Account administrator@lab.local über die anfällige Vorlage WIFI anzufordern. Dazu kann wieder Certipy verwendet werden:
certipy req -u 'clientuser1@lab.local' -p <Password> -dc-ip 192.168.30.131 -target WIN-4SAHM65HN1H.lab.local -ca lab-WIN-4SAHM65HN1H-CA -template WIFI -upn 'administrator@lab.local' -sid 'S-1-5-21-...-500'
Bei einer erfolgreichen Ausführung dieses Befehls wird ein Zertifikat für den administrator@lab.local Account generiert. Dieses wird in der administrator.pfx Datei gespeichert:

Dieses Zertifikat kann im Anschluss zur Authentifizierung am Domain-Controller verwendet werden, was den Passwort-Hash des administrator@lab.local Accounts preisgibt:

Da es sich um einen NTLM-Hash handelt, der in der NTLM-Authentifizierung einem Klartext-Passwort gleichzusetzen ist, können nun beliebige Befehle auf dem Domain-Controller ausgeführt werden:
Somit gilt die gesamte Domäne als kompromittiert.
Gegenmaßnahmen
Werden die in der Zusammenfassung gelisteten Punkte umgesetzt, ist die Zertifikatsvorlage WIFI nicht mehr anfällig:
Template Name : WIFI
Display Name : WIFI
Enabled : False
Client Authentication : True
Enrollment Agent : False
Any Purpose : False
Enrollee Supplies Subject : False
Certificate Name Flag : SubjectAltRequireUpn
Enrollment Flag : AutoEnrollment
PublishToDs
IncludeSymmetricAlgorithms
Private Key Flag : 16777216
65536
ExportableKey
Extended Key Usage : Client Authentication
Secure Email
Encrypting File System
Requires Manager Approval : False
Requires Key Archival : False
Authorized Signatures Required : 0
Validity Period : 1 year
Renewal Period : 6 weeks
Minimum RSA Key Length : 2048
Permissions
Enrollment Permissions
Enrollment Rights : LAB.LOCAL\Domain Admins
LAB.LOCAL\Domain Users
LAB.LOCAL\Enterprise Admins
Object Control Permissions
Owner : LAB.LOCAL\Administrator
Write Owner Principals : LAB.LOCAL\Domain Admins
LAB.LOCAL\Enterprise Admins
LAB.LOCAL\Administrator
Write Dacl Principals : LAB.LOCAL\Domain Admins
LAB.LOCAL\Enterprise Admins
LAB.LOCAL\Administrator
Write Property Principals : LAB.LOCAL\Domain Admins
LAB.LOCAL\Enterprise Admins
LAB.LOCAL\Administrator
Wird versucht, ein Zertifikat für einen anderen Account anzufordern, wird dies ignoriert und das korrekte Zertifikat ausgestellt:
