Microsoft Active Directory Public Key Infrastructure (PKI), besser bekannt als Active Directory Certificate Services (AD CS), ist eine Windows Server Rolle zur Ausstellung und Verwaltung von PKI-Zertifikaten, die in sicheren Kommunikations- und Authentifizierungsprotokollen verwendet werden. Diese Zertifikate können zur Verschlüsselung und Signatur von Dokumenten und Nachrichten sowie zur Authentifizierung von Computer- und/oder Benutzerkonten verwendet werden. In diesem Beitrag werden wir einen genaueren Blick auf die Fehlkonfigurationen werfen und wie wir sie nutzen können, um Active Directory-Umgebungen anzugreifen. Die Möglichkeiten reichen vom Diebstahl von Anmeldeinformationen über die Persistenz von Rechnern bis hin zur Domäneneskalation. Die Techniken basieren auf dem Certified Pre-Owned Whitepaper von Will Schroeder und Lee Christensen.

Ziel dieses Beitrags ist es, eine kurze Einführung in dieses komplexe und offen gesagt manchmal etwas trockene, aber sehr wichtige Thema zu geben. Wir werden einige grundlegende Funktionen behandeln, wie Zertifikate aussehen und wie sie ge- und missbraucht werden können.

Übersicht

AD CS kann entweder als Standalone Certificate Authority (CA) oder als Enterprise CA eingesetzt werden. Eine Standalone CA verfügen nicht über Funktionen wie Zertifikatsvorlagen und AutoEnrollment, weshalb sie eher als Root- und Policy-CAs eingesetzt werden und nur Zertifikate für andere CAs ausstellen. Die Enterprise CA verfügt über Funktionen wie Zertifikatsvorlagen und AutoEnrollment, die in den meisten Fällen für Unternehmensumgebungen entscheidend sind. Was sind diese Funktionen und wie funktionieren sie?

• Zertifikatsvorlagen können als Blaupausen mit vordefinierten Einstellungen für Zertifikate betrachtet werden. Die Einstellungen definieren Dinge wie Wofür wird das Zertifikat verwendet, Wer kann ein Zertifikat beantragen, Wie lange ist das Zertifikat gültig und so weiter. Je nach Verwendung eines Zertifikats können die Einstellungen in diesen Blaupausen angepasst werden.
• AutoEnrollment ermöglicht es Clients (Benutzern und Computern), automatisch Zertifikate in einer Active Directory-Domäne auf der Grundlage vordefinierter Zertifikatsvorlagen anzufordern und zu erhalten.

Zertifikate

Wie bereits erwähnt, enthält ein Zertifikat verschiedene Felder mit Informationen darüber, wie und wofür das Zertifikat verwendet werden soll. Schauen wir uns einige dieser Felder und die erwarteten Werte genauer an:

• Seriennummer Kennung für ein von der Zertifizierungsstelle zugewiesenes Zertifikat
• Issuer Gibt an, wer das Zertifikat ausgestellt hat, normalerweise eine Zertifizierungsstelle
• Gültig von und Gültig bis Gibt das Datum an, ab dem das Zertifikat gültig ist, bis es abläuft.
• Subject Eigentümer des Zertifikats
• Enhanced Key Usages auch bekannt als Extended Key Usages (EKUs) – Objektbezeichner (OIDs) beschreiben, wofür das Zertifikat verwendet werden kann.

Die im Zertifikat enthaltenen Informationen binden eine Identität – das Subject – an das Schlüsselpaar.

EKUs und OIDs stehen in Beziehung zueinander, eine OID ist im Grunde eine Kette von Dezimalzahlen, die ein Objekt eindeutig identifiziert. Im Moment sind die EKUs, die die Authentifizierung bei AD ermöglichen, interessant und wir konzentrieren uns auf folgende:

Weitere Informationen über OIDs in PKI finden Sie in diesem PKI Solutions Post.

Zertifikatsregistrierung

Nach der Installation der AD CS-Rolle als Enterprise CA muss ein Administrator zunächst Zertifikatsvorlagen erstellen und definieren. Diese werden dann von der Enterprise CA veröffentlicht und den Benutzern und Computern zur Registrierung zur Verfügung gestellt. Ohne zu sehr ins Detail zu gehen, ein Client kann nur dann ein Zertifikat anfordern, wenn er sowohl auf der Enterprise CA als auch in der Zertifikatsvorlage selbst berechtigt ist, ein solches Zertifikat zu beantragen. Weitere technische Informationen darüber, wie diese Berechtigungen festgelegt werden, können im Whitepaper im Kapitel Certificate Enrollment gefunden werden.

Wenn die Berechtigungen erteilt sind und ein Client ein Zertifikat anfordern darf, kann dies je nach AD CS-Umgebung auf unterschiedliche Weise geschehen:

• Mit dem Windows Client Certificate Enrollment Protocol (MS-WCCE).
• Mit dem ICertPassage Remote Protocol (MS-ICPR).
• Über eine Web-Enrollment-Anwendung, dazu muss auf dem AD CS Server die Rolle Certificate Authority Web Enrollment installiert sein.
• Über den Certificate Enrollment Service (CES), hierfür muss auf dem AD CS Server die Rolle Certificate Enrollment Web Service installiert sein.
• Über den Network Device Enrollment Service, hierfür muss auf dem AD CS Server die Rolle Network Device Enrollment Service installiert sein.

Ein Beispiel: Ein Benutzer muss manuell ein neues Zertifikat für seinen Windows-Rechner anfordern. Der erste Schritt besteht darin, die grafische Benutzeroberfläche zu öffnen, indem certmgr.msc (certlm.msc für Computerzertifikate) in das Suchfeld von Windows eingeben wird. Öffnen Sie den Ordner Persönlich, klicken Sie mit der rechten Maustaste auf den Ordner Zertifikate und wählen Sie Alle Aufgaben, Neues Zertifikat anfordern.

Nun öffnet sich ein weiterer Assistent und alle veröffentlichten Zertifikatsvorlagen, die der Benutzer anfordern darf, werden angezeigt und können angefordert werden. Standardmässig fordert Windows dann das Zertifikat mit MS-WCCE an.

Offensivtechniken

Die Angriffstechniken werden in vier verschiedene Kategorien, basierend auf den verschiedenen Angriffstechniken aus dem Whitepaper, unterteilt: Diebstahl, Persistenz, Eskalation und Domänenpersistenz. Die folgende Tabelle hilft, die Unterschiede zwischen den Kategorien zu verstehen.

Um zu verstehen, welche Techniken in diesen Kategorien enthalten sind, sehen wir uns eine der Eskalations-Möglichkeiten an, wenn AD CS falsch konfiguriert ist.

NTLM-Relay zu einem anfälligen AD CS HTTP-Endpunkt (ESC8)

Wie im Kapitel Zertifikatsregistrierung erwähnt, stehen mehrere HTTP-basierte Schnittstellen für die Zertifikatsregistrierung zur Verfügung, sofern sie installiert sind. Diese HTTP-Schnittstellen sind im Allgemeinen anfällig für NTLM-Relay-Angriffe. Ein Angreifer auf einem kompromittierten Rechner könnte die Net-NTLMv2-Authentifizierung manipulieren und sich als dieses AD-Konto ausgeben, um Zugriff auf Zertifikatsanforderungen zu erhalten oder andere Operationen im Namen des Benutzers durchzuführen. Dies könnte zu Sicherheitsproblemen wie unbefugtem Zugriff und der Ausstellung nicht autorisierter Zertifikate führen.

Gehen wir einen möglichen Angriff durch, bei dem AD CS für ESC8 anfällig ist:

1. Einem Angreifer gelingt es, einen Rechner eines Endbenutzers zu kompromittieren und auf diesem Fuss zu fassen.
2. Nach einer ersten Erkundung des Active Directory wurde die ESC8-Schwachstelle mit Hilfe des Tools Certify in der Active Directory Certificate Service Rolle identifiziert.
3. Um den Angriff auf die AD CS-Webschnittstelle zu starten, muss sich ein Opfer am vom Angreifer kontrollierten Client authentifizieren, um den NTLM-Relay-Angriff zu starten. Bei diesem Beispiel gehen wir davon aus dass eines der folgenden Szenarien eingetreten ist:
   1. Der Angreifer hat genügend Zeit und kann darauf warten, dass dies als Teil des Tagesgeschäfts im Netzwerk geschieht.
   2. Der Angreifer schafft es, ein Konto zu zwingen, sich gegenüber dem vom Angreifer kontrollierten Rechner zu authentifizieren. Bevorzugte Ziele sind Domänencontroller und/oder hochprivilegierte Konten.
4. Nachdem ein Domänencontroller erfolgreich dazu gebracht wurde sich bei dem vom Angreifer kontrollierten Rechner zu melden, wird der Net-NTLMv2-Hash des DC mitgesendet und kann danach an den AD CS HTTP-Endpunkt weitergeleitet werden.
5. Da der HTTP-Endpunkt keinen Relay-Schutz hat, kann der Angreifer Zertifikate im Namen des ursprünglichen Absenders, in diesem Fall des Domänencontrollers, anfordern.
   1. Nun wird ein Zertifikat ausgestellt, das auf einer Zertifikatsvorlage mit geeigneten Enhanced Key Usage Werten wie Client Authentication oder SmartCard Logon basiert.
6. Da der betroffene Computer ein Domänencontroller war, der hochprivilegierte Aktionen wie Domänenreplikation durchführen kann, könnte der Angreifer das Zertifikat verwenden, um die Domäne zu kompromittieren. Einige der Möglichkeiten wären zum Beispiel der Versuch, einen DCSync-Angriff auszuführen, den NTHash oder ein Kerberos Ticket Granting Ticket (TGT) über PKINIT zu erhalten.

Defensivtechniken

Wenn die Angriffstechniken bekannt sind, ist es etwas einfacher, sich gegen sie zu schützen. Will Schroeder und Lee Christensen haben diese Abwehrtechniken bereits nummeriert und kategorisieren diese defensiven Techniken in präventive und detektive Massnahmen. Das Tool PSPKIAudit kann zur Auflistung von fehlkonfigurierten Vorlagen verwendet werden. Nach der Identifizierung von Fehlkonfigurationen ist es empfehlenswert, sich mit den Defensivtechniken zu befassen und den Abschnitt Defensive Guidance zu befolgen, um sie entsprechend zu verwalten. Wir werden nicht auf die verschiedenen Kontrollen eingehen und wie sie den offensiven Techniken zugeordnet werden, da dies im Whitepaper gut beschrieben ist, ich möchte jedoch kurz auf die Präventivmassnahmen gegen die ESC8-Schwachstelle eingehen.

AD CS HTTP-Endpunkte härten (PREVENT8)

Die effektivste Methode, um die ESC8-Schwachstelle zu verhindern, besteht darin die AD CS HTTP-Endpunkte gar nicht erst zu aktivieren. Um zu ermitteln welche Endpunkte aktiviert sind, und sie zu entfernen, verbinden Sie sich mit dem Server, auf dem die AD CS-Rolle ausgeführt wird, öffnen Sie die App Server Manager und verwenden Sie den Assistenten Rollen und Funktionen entfernen.

Wenn die Endpunkte notwendig sind und es nicht möglich ist, sie zu entfernen, könnten diese Abwehrmassnahmen gegen ESC8 in Betracht gezogen werden.

• Deaktivieren Sie die NTLM-Authentifizierung, die Deaktivierung von NTLM kann auf der Ebene des Hosts oder des Webservers (Internet Information Services (IIS)) vorgenommen werden.
• Erzwingen Sie HTTPS auf IIS-Ebene, aktivieren Sie Erweiterter Schutz für die Authentifizierung und setzen Sie den Wert Erweiterter Schutz auf Erforderlich.

Zusammenfassung

Active Directory Certificate Services können sehr schnell komplex werden und sind in den meisten Umgebungen nicht einfach zu implementieren und zu sichern. Die verschiedenen Möglichkeiten, wie AD CS konfiguriert, erweitert und für verschiedene Anwendungsfälle angepasst werden kann, machen es schwer, dies effektiv abzusichern. Die verschiedenen Techniken des Zertifikatsmissbrauchs ermöglichen Angreifern in kurzer Zeit von Credential Theft über Domain Persistence bis hin zu Domain Escalation zu gelangen. Die erwähnten Tools Certify (AD CS Enumeration) und PSPKIAudit (Auditing AD CS) eignen sich hervorragend, um etwaige Schwachstellen in der Infrastruktur aufzuzeigen, die dann behoben werden können. Falls noch nicht geschehen, empfiehlt es sich, die AD CS-Umgebung und die Zertifikatsvorlagen kontinuierlich zu überprüfen. Zusammengefasst: Nicht nur die Domänencontroller müssen geschützt werden, sondern auch die CA-Server, behandeln Sie sie wie ein Tier 0 System

Über den Autor

Eric Maurer hat eine IT-Ausbildung im Finanzsektor absolviert und konnte danach Erfahrungen in den Rollen Administrator, Engineer und Consultant sammeln. Dabei war er involviert in Entwicklung, Aufbau und Betrieb eines Enhanced Security Administrative Environment und dem internationalen Rollout von Active Directory Services. Zudem hat er Erfahrung mit Azure Active Directory mit Fokus auf Security.

Links

• https://blog.quest.com/everything-you-need-to-know-about-dcsync-attacks/
• https://github.com/GhostPack/Certify
• https://github.com/GhostPack/PSPKIAudit
• https://learn.microsoft.com/en-us/archive/technet-wiki/9063.active-directory-certificate-services-ad-cs-network-device-enrollment-service-ndes
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-icpr/9b8ed605-6b00-41d1-9a2a-9897e40678fc)@
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wcce/446a0fca-7f27-4436-965d-191635518466
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wcce/446a0fca-7f27-4436-965d-191635518466)@
• https://learn.microsoft.com/en-us/windows-server/identity/ad-cs/certificate-authority-web-enrollment#certification-authority-web-enrollment
• https://learn.microsoft.com/en-us/windows/win32/seccrypto/cryptoapi-system-architecture
• https://msrc.microsoft.com/blog/2009/12/extended-protection-for-authentication/
• https://posts.specterops.io/operational-guidance-for-offensive-user-dpapi-abuse-1fb7fac8b107
• https://specterops.io/assets/resources/Certified_Pre-Owned.pdf
• https://twitter.com/harmj0y
• https://twitter.com/tifkin_
• https://twitter.com/tifkin_..
• https://web.mit.edu/kerberos/krb5-1.12/doc/admin/pkinit.html#pkinit-configuration
• https://www.pkisolutions.com/object-identifiers-oid-in-pki/
• https://www.tripwire.com/state-of-security/how-to-prevent-high-risk-authentication-coercion-vulnerabilities