Zertifikate des Vertrauens

von Evgenij Smirnov

Microsofts Enterprise-PKI ist ein wenig in Verruf geraten. So eröffnen einige der optionalen Komponenten unter Umständen bereits geschlossen geglaubte Angriffspfade. Und auch im Kern bietet eine standardmäßig installierte Windows-Zertifizierungsstelle den Admins wenig Kontrolle, Angreifern wiederum viele Missbrauchswege. Dabei sieht das Produkt durchaus wirksame Möglichkeiten vor, um den Zertifikats- und Vorlagenzoo zu beherrschen – es bedarf nur eines entsprechenden Moduls. Ein solches ist "Tame My Certs", das für mehr Ordnung und Sicherheit in Ihrer PKI sorgt.

Die Active Directory Certificate Services (ADCS) haben in den letzten 20 Jahren nicht viel Aufmerksamkeit von Microsoft erhalten. Es kamen zwar neuere Verschlüsselungsalgorithmen zum Einsatz, sodass die Zertifizierungsstelle (Certificate Authority, CA) aktuellen Anforderungen entspricht, doch Begleitdienste wie "Web Enrollment" oder "Network Device Enrollment Service" (NDES, die Microsoft-Implementierung des "Simple Certificate Enrollment Protocol" oder SCEP) wurden kaum bis gar nicht weiterentwickelt. Auch hatten sich in der Vergangenheit die wenigsten Administratoren mit Zertifikatsthemen beschäftigt, und so werkelte in vielen Windows- und AD-basierten IT-Landschaften eine Zertifizierungsstelle praktisch unbemerkt vor sich hin.

Die Windows-Zertifikatsdienste sind dann vor einigen Jahren in den Fokus der IT-Verantwortlichen gerückt, weil sie ein sehr bequemes Einfallstor für eine Vielzahl von Angriffen bieten, die bereits für die vollständige Kompromittierung großer IT-Umgebungen verantwortlich waren. Teilweise sind diese Sicherheitslücken sehr einfach zu beseitigen, wie beispielsweise der NTLM-Relay-Angriff, der im klassischen Whitepaper [1] von SpecterOps unter "ESC8" geführt wird. Allerdings ist dort wie in vielen Nachfolge-Publikationen von einem "Angriff auf das HTTP-Interface einer Enterprise CA" die Rede, was den Eindruck entstehen lässt, eine Windows-CA würde grundsätzlich HTTP sprechen. In Wirklichkeit missbraucht der Angriff den "Web Enrollment"-Dienst, der zwar relativ selten genutzt wird, dafür jedoch getreu dem Prinzip "viel hilft viel" umso häufiger mit-installiert wird, ohne dass sich die Zuständigen Gedanken um Absicherung und Härtung des Diensts gemacht hätten. Das wirkungsvollste Mittel gegen ESC8 ist also die Deinstallation des – meist ohnehin nicht benötigten – Rollendiensts.

Andere Angriffswege sind dagegen weitaus schwieriger zu schließen, denn sie missbrauchen tatsächlich benötigte Funktionalitäten. Besonders gravierend sind die Folgen eines erfolgreichen Angriffs auf eine Enterprise-PKI, wenn eine

zertifikatbasierte Authentifizierung für Benutzer oder Computer zum Einsatz kommt. In solchen Fällen kann es dem Angreifer gelingen, die Identität eines hochprivilegierten Benutzers, einer Privileged-Access-Workstation oder sogar eines Domaincontrollers anzunehmen.

Risiko durch mobile Geräte

Es ist durchaus möglich, eine Windows-Zertifizierungsstelle so zu konfigurieren, dass sie gar keine authentifizierungsfähigen Zertifikate ausstellt. Allerdings reduziert eine solche Konfiguration den Nutzen der Zertifizierungsstelle praktisch auf Null. Insbesondere beim Einsatz mobiler Endgeräte sind Benutzerzertifikate ein probates Mittel, um dem Anwender eines Smartphones den Zugriff auf Unternehmensanwendungen mit der Identität seines Active-Directory-Kontos zu ermöglichen. Dafür muss allerdings das Mobile-Device-Management-System (MDM) so konfiguriert und autorisiert sein, dass es Zertifikate für Benutzer beantragen kann.

Im einfachsten Fall bedeutet dies, dass die CA mit dem Konfigurationsmerkmal "EDITF_ATTRIBUTESUBJECTALTNAME2+" versehen wird. Dadurch kann jeder für die Beantragung eines Zertifikats berechtigte Sicherheitskontext den Inhalt des SAN-Attributs des Zertifikats nach seinen Wünschen festlegen. Gelingt es einem Angreifer, das MDM zu manipulieren, könnte er ein Zertifikat für einen Domänen-Administrator ausstellen lassen und später für die Authentifizierung verwenden. Doch auch der Versuch, ein Zertifikat für ein mobiles Gerät auszustellen, das im MDM noch keinem Benutzer zugeordnet ist, birgt gewisse Gefahren – es beinhaltet gar keine Benutzeridentität und unter Umständen ist mit einem solchen Zertifikat die Authentifizierung im Namen eines beliebigen Benutzers möglich. Microsoft hat die Kerberos-Implementierung in Windows zwar bereits dahingehend gehärtet, andere Anwendungen jedoch könnten hier durchaus noch eine offene Flanke aufweisen.

Bereits dieses einfache und sehr verbreitete Nutzungsszenario offenbart zwei Probleme, für die eine Windows-CA in der Standardkonfiguration keine Lösung parat hat:

- Wenn ein Benutzer berechtigt ist, den Inhalt des Zertifikatsantrags beliebig zu gestalten, sind dieser Gestaltung keine Grenzen gesetzt und das Zertifikat wird wie beantragt ausgestellt.

- Es ist nicht ohne weiteres möglich, die Beantragung solcher beliebig variablen Zertifikate nur auf bestimmte Vorlagen oder nur auf bestimmte Clientanwendungen (beispielsweise das MDM-System) zu beschränken.

Ferner dienen die durch eine Windows-CA veröffentlichten Zertifikatsvorlagen nicht als "harte Einschränkungen", sondern tatsächlich nur als Vorlagen. Erlauben Sie beispielsweise in einer Vorlage das Exportieren des privaten Schlüssels nicht, kann der Antragsteller dieses Merkmal während des Beantragungsprozesses durchaus ändern und sich ein Zertifikat mit exportierbarem privatem Schlüssel ausstellen lassen.

Solche funktionalen Einschränkungen führten dazu, dass Security-Experten die Microsoft-PKI oft als nicht unternehmenstauglich oder grundsätzlich unsicher betrachten. Dabei haben die Entwickler der Windows-PKI durchaus eine Schnittstelle implementiert, die viele dieser Einschränkungen aufhebt. Wenn Sie sich die Architektur der Windows-CA in [2] anschauen, fällt Ihnen bestimmt das "Policy-Modul" auf, das zwischen der Client- (Beantragung) und der Exit-Schnittstelle (Übermittlung des ausgestellten Zertifikats) wirkt.

Dieses Policy-Modul ist extrem mächtig, denn es verarbeitet die gesamte Beantragung des Zertifikats, einschließlich

- der Identität des Antragstellers, dessen Existenz und Berechtigung, den Antrag auf eine bestimmte Art von Zertifikaten zu stellen, und

- des Inhalts des Antrags und der darin enthaltenen Informationen, welche auch durch das Policy-Modul ergänzt und modifiziert werden können.

Am Ende der Verarbeitung durch das Policy-Modul wird der Antrag entweder abgelehnt oder an die Server-Engine zurückgegeben, die dann ohne weitere Prüfungen den vom Policy-Modul erhaltenen Antrag signiert und an die Exit-Schnittstelle ausgibt.

Die Windows-CA kann übrigens nur ein Policy-Modul einbinden – im Gegensatz zu Exit-Modulen, von denen es durchaus mehrere geben kann. Windows liefert ein standardmäßiges Policy-Modul mit, das zwar einige wichtige Prüfungen und Anpassungen der Zertifikatsanträge durchführt, jedoch nicht so weit in die Tiefe geht, dass zusätzliche Plausibilitätsprüfungen oder Ergänzungen möglich sind.

Ordnung schaffen mit Tame My Certs

Die oben beschriebenen sicherheitsrelevanten Einschränkungen führten 2016 dazu, dass der PKI-Experte Uwe Gradenegger, damals Premier Field Engineer bei Microsoft, sich die CA-Architektur und speziell die Möglichkeiten eines Policy-Moduls genau anschaute und beschloss, ein alternatives Policy-Modul zu entwickeln. Dieses sollte dem Beantragungsprozess sowie dem Inhalt der ausgestellten Zertifikate deutlich verbindlichere Grenzen aufzeigen – der Name "Tame My Certs" ist hier Programm. Die Einschränkung, dass sich nur ein Policy-Modul zur gleichen Zeit einbinden lässt, erschwert dies zwar auf den ersten Blick, denn alles, was das standardmäßige Modul bereits durchführt, müsste auch in einem Fremdmodul implementiert werden.

Zum Glück erlaubt die Softwarearchitektur des Policy-Moduls, dass ein Policy-Modul ein anderes transparent aufrufen kann. Dieses Umstands bedient sich Tame My Certs und verwendet bei Eingang eines Zertifikatsantrages als Ertes das standardmäßige Policy-Modul von Microsoft. Wird der Antrag bereits durch dieses abgelehnt, beispielsweise wegen fehlender Berechtigungen, falscher Schlüssellänge oder einer nicht veröffentlichten Zertifikatsvorlage, lehnt Tame My Certs den Antrag gegenüber der Server-Engine ohne weitere Verarbeitung ebenfalls ab. Wird der Antrag hingegen durch das Default-Modul durchgewunken, kann sich Tame My Certs auf seine Aufgaben konzentrieren und zusätzliche Prüfungen und Anpassungen vornehmen.

Sie können Tame My Certs also unbesorgt jederzeit in Ihre Zertifizierungsstellen einbinden – solange Sie keine Konfigurationen des Moduls vornehmen, verändert es nicht das Verhalten der CA. Einen negativen Einfluss auf die Performance der CA müssen Sie ebenfalls nicht fürchten, denn Tame My Certs ist inzwischen seit mehreren Jahren bei Organisationen im Einsatz, die mehrere Tausend Zertifikate pro Tag ausstellen. Das Projekt war einige Jahre lang weltweit das Einzige seiner Art. Inzwischen hat das Expertenteam von PKISolutions LLC ein eigenes Policy-Modul veröffentlicht [3]. Dieses beschränkt sich allerdings auf die Behandlung der neuen SID-Erweiterung, die Microsoft im Rahmen des Mai-2022-Patchtags veröffentlicht hat und deren Verwendung ab 14. November 2023 erzwungen werden soll. Der PKI-Blog von Uwe Gradenegger [4] bietet übrigens viele nützliche Tipps sowohl zur Windows-PKI im Allgemeinen als auch konkret zu Tame My Certs.

Tame My Certs installieren

Tame My Certs ist ein Open-Source-Projekt und wird auf GitHub [5] unter der Apache-2.0-Lizenz gepflegt und bereitgestellt. Sie können es also privat wie kommerziell einsetzen. Der "best effort"-Support durch den Autor erfolgt am besten über GitHub-Issues. Falls Ihre Organisation einen kommerziellen, SLA-gestützten Support für die eingesetzte Software abschließen muss oder möchte, ist dies seit einiger Zeit ebenfalls möglich.

Die kompilierte, 95 KByte kleine DLL ist digital signiert. Falls Sie das Modul selbst kompilieren möchten, beinhaltet das Repository den kompletten Quellcode und die Build Scripts. Sind Sie nur am Betrieb von Tame My Certs interessiert, laden Sie von der "Releases"-Seite die ZIP-Datei für die aktuelle Version herunter und extrahieren Sie den Inhalt.

Um die Software zu installieren und später erfolgreich zu betreiben, müssen Sie zunächst ein lokales Verzeichnis auf Ihrer CA anlegen, in dem Sie die XML-Dateien ablegen werden, die das Verhalten des Moduls steuern. Sorgen Sie unbedingt dafür, dass ausschließlich berechtigte Personen Zugriff auf dieses Verzeichnis haben. Falls Sie einer Active-Directory-Gruppe die Berechtigung erteilt haben, die Zertifizierungsstelle zu verwalten, sollten ausschließlich diese Gruppe und das SYSTEM-Konto Zugriff auf das Konfigurationsverzeichnis von Tame My Certs haben. Sie sollten hier auch mit dem Lesezugriff sparsam sein, denn der Einblick in die XML-Dateien kann einem Angreifer wertvolle Informationen darüber liefern, welche Merkmale einzelne Zertifikatstypen in Ihrer Organisation haben sollen.

Ist der Ordner angelegt, können Sie das mitgelieferte PowerShell-Skript "install.ps1" verwenden, um das Modul zu installieren und in Ihrer CA als das aktive Policy-Modul zu registrieren:

Auch für die Deinstallation des Moduls sollten Sie unbedingt dasselbe Skript, jedoch mit dem Parameter "-Uninstall", verwenden. Der Grund dafür liegt in der Konfiguration des jeweiligen Policy-Moduls, die in der Registry unter dem Schlüssel dieses Moduls gespeichert ist. Diese Einstellungen werden nicht automatisch durch Registrieren oder Entfernen einer Modul-DLL in den Schlüssel der jeweils aktiven Policy kopiert – diese Aufgabe übernimmt das PowerShell-Skript sowohl bei der Installation als auch bei der Deinstallation.

Nach dem Aufspielen von Tame My Certs verhält sich Ihre Zertifizierungsstelle exakt wie vorher. Sie können nun damit beginnen, Ihre veröffentlichten Zertifikatsvorlagen in engere Schranken zu weisen.

Erste Schritte mit Tame My Certs

Die Funktionsweise von Tame My Certs zeigt sich aus administrativer Sicht denkbar einfach:

- Wird ein Zertifikatsantrag zu einer Vorlage eingereicht, sucht Tame My Certs in dem durch "PolicyDirectory" angegebenen Verzeichnis nach einer XML-Datei, deren Name exakt dem Namen der Vorlage entspricht (nicht jedoch ihrem Anzeigenamen).

- Existiert keine solche Datei, wird der Antrag nur durch das Default-Policy-Modul von Microsoft abgearbeitet.

- Ist die Datei vorhanden und lässt das Default-Modul den Antrag durch, prüft Tame My Certs anhand der Regeln in der XML-Datei den Antrag zusätzlich, verändert oder ergänzt diesen und reicht ihn dann zur Signierung ein.

Eine typische Aufgabe, an der Sie den Umgang mit Tame My Certs gut üben können, betrifft Webserver-Zertifikate. Meistens ist sowohl im Subject als auch im SAN (Subject Alternate Name) nicht der Computername des eigentlichen Webservers, sondern ein anwendungsspezifischer FQDN anzugeben – vor allem, wenn die Webanwendung durch mehrere Server bedient wird.

Um dies zu erreichen, erhält die Webserver-Vorlage das Merkmal "Name wird in der Anforderung angegeben". Dies versetzt einen berechtigten Antragssteller in die Lage, Webserver-Zertifikate für beliebige Adressen zu beantragen – Sie können ihn mit Bordmitteln nicht daran hindern, ein Zertifikat für www.it-administrator.de ausstellen zu lassen.

Mit Tame My Certs können Sie Verbindlichkeit und Ordnung in diesen Vorgang bringen. Die eigentliche Zertifikatsvorlage bleibt dabei unverändert, in der dazugehörigen XML-Datei können Sie beispielsweise einen Inhalt platzieren, wie im Listing-Kasten dargestellt.

Diese XML-Datei erzwingt folgende Einschränkungen für die Beantragung eines Webserver-Zertifikats in der Reihenfolge von oben nach unten:

- Signiert durch einen RSA-Schlüssel zwischen 2048 und 4096 Bit Länge.

- Es muss exakt ein (Mandatory=true + MaxOccurrences=1)-Subject-Eintrag vom Typ "Allgemeiner Name" eingereicht werden.

- Dieser Name darf eine Höchstlänge von 64 Zeichen nicht überschreiten.

- Die regulären Ausdrücke (Patterns) schreiben vor, dass der eingereichte Name ein FQDN aus den Domänen "metabpa.org" oder "ita.metabpa.org", nicht jedoch die Domain "ita.metabpa.org" selbst sein muss.

- Im SAN muss ein Eintrag vom Typ "DNS-Name" vorhanden sein, und es darf davon nicht mehr als zehn geben.

- Für jeden eingereichten DNS-Namen gelten dieselben Einschränkungen wie im Subject (siehe oben).

Versucht ein Administrator nun ein Webserver-Zertifikat für einen unzulässigen Namen zu erhalten, wird der Antrag mit der Begründung abgelehnt, dass der Name nicht gültig ist. Dies sind die standardmäßigen Windows-Fehlercodes (in dem Fall "CERT_E_INVALID_NAME"). Die Text-Fehlermeldungen, die der Antragsteller zu sehen bekommt, werden also von der Zertifizierungsstelle und nicht von Tame My Certs generiert. Wenn Sie wissen möchten, welche Regeln genau verletzt wurden, schauen Sie im Anwendungs-Ereignisprotokoll der Zertifizierungsstelle nach Ereignissen aus der Quelle "TameMyCerts".

Falls Sie Ihr neues Regelwerk nicht direkt scharf schalten möchten, können Sie es erst einmal im Audit-Modus starten, indem Sie der XML die folgende Zeile hinzufügen (vorzugsweise am Anfang, unter dem Header):

Damit landen zwar alle relevanten Events im Ereignisprotokoll, der Antrag wird jedoch weder verändert noch bei Regelverletzungen abgelehnt.

Anträge ergänzen

Viele Betreiber hausinterner Webanwendungen haben noch nicht verinnerlicht, dass aktuelle Webbrowser den RFC2818 – immerhin aus dem Jahr 2000 – inzwischen buchstabengetreu umsetzen und dadurch der SAN- und nicht der Subject-Eintrag von Bedeutung ist. Wenn Sie diese Admins mit den zuvor beschriebenen Einschränkungen konfrontieren, wissen sie eventuell gar nicht, was sie falsch gemacht haben.

Sie können den Kollegen jedoch mithilfe von Tame My Certs die Arbeit abnehmen, den DNS-Namen zusätzlich in das SAN-Attribut zu schreiben. Fügen Sie hierfür der XML-Datei einfach die Zeile

hinzu. Dies weist Tame My Certs an, den Subject zu untersuchen und, falls im Common Name ein valider DNS-Name steht, diesen in SAN zu kopieren. Damit das funktioniert, muss jedoch das "dnsName"-Feld im "SubjectAlternativeName"-Abschnitt auf "nicht verbindlich" gestellt werden.

Manchmal erwarten Anwendungen, bestimmte Informationen im Zertifikat vorzufinden. Das können beispielsweise Angaben zu Stadt, Land oder Firma sein. Sie können diese Felder in Ihrer Tame-My-Certs-Richtlinie natürlich für verbindlich erklären und auch per Pattern bestimmte syntaktische Regeln für die eingereichten Werte erzwingen. Häufig sind diese Informationen jedoch bereits im Active-Directory-Objekt des Users oder Computers enthalten, für den das Zertifikat ausgestellt werden soll. Hier leistet Tame My Certs wertvolle Unterstützung.

Auch die Dauerhaftigkeit der Zertifikate lässt sich durch Tame My Certs beeinflussen. Normalerweise liefern die Vorlagen nur eine Vorgabe bezüglich der Laufzeit. Möchten Sie, dass die Zertifikate unabhängig vom Ausstellungsdatum zum Ende des Jahres 2023 nach mitteleuropäischer Zeit ablaufen, fügen Sie Ihrer XML-Datei den Tag hinzu:

Das Active Directory befragen

Die Fähigkeit, auf Active-Directory-Daten zuzugreifen, kommt Tame My Certs sowohl bei der Antragsprüfung als auch bei der Anreicherung des Antrags mit zusätzlichen Informationen zugute. Dazu dient die Direktive "DirectoryServicesMapping". Um bei der Beantragung eines Zertifikats die Existenz des entsprechenden Computer-Objektes zu überprüfen, fügen Sie Ihrer XML-Datei die folgende Klausel hinzu:

Dies führt dazu, dass in der angegebenen OU nach einem Computer-Objekt gesucht wird, dessen AD-Attribut "dnsHostName" mit dem DNS-Namen aus dem Zertifikatsantrag übereinstimmt. Ist dieses Computer-Objekt nicht vorhanden, wird der Antrag abgelehnt. Wenn Sie den "SearchRoot"-Tag weglassen, erfolgt die Suche über den globalen Katalog und daher forestweit. Um beispielsweise das Beantragen eines Authentifizierungszertifikats für einen Administrator zu unterbinden, könnte die Mapping-Klausel wie folgt aussehen:

Bei der Auswertung der Gruppenzugehörigkeit verarbeitet die aktuelle Version jedoch ausschließlich direkte, nicht verschachtelte Gruppenmitgliedschaften.

Um die Daten aus Active-Directory-Attributen in den Zertifikatsantrag zu übernehmen, fügen Sie Ihrem "DirectoryServicesMapping" den Abschnitt "SubjectDistinguishedName" hinzu, wie im Benutzerhandbuch unter [6] ausführlich beschrieben. So können Sie beispielsweise Ihr Mobile-Device-Management-System in die Lage versetzen, valide Benutzerzertifikate mit dem korrekten UPN und DisplayName sowie mit der dazugehörigen SID-Erweiterung zu beantragen, obwohl dem MDM lediglich die E-Mail-Adresse des Smart-phone-Nutzers bekannt ist.

Beantragende Anwendungen einschränken

Ein etwas exotischeres Feature von Tame My Certs ist die Fähigkeit, das Beantragen von Zertifikaten auf bestimmte Prozesse zu beschränken (Whitelist) oder für bestimmte Prozesse zu verbieten (Blacklist). Die Prozesserkennung ist nicht zu 100 Prozent zuverlässig, aber zumindest unterbinden Sie damit das einfache Umgehen der festgelegten Richtlinien. Soll eine bestimmte Vorlage beispielsweise nur durch Autoenrollment bedient werden, fügen Sie der XML-Datei für diese Vorlage die folgende Direktive hinzu:

Sie können auch mehrere Prozessnamen, jeweils in den "string"-Tag eingeschlossen, angeben. Für das Verbieten einzelner Prozesse verwenden Sie die Direktive "DisallowedProcesses". Möchten Sie beispielsweise das Beantragen mit der MMC-Konsole unterbinden, verwenden Sie die folgende Konfiguration:

Sie sollten natürlich nicht beide Direktiven in ein und dieselbe Konfigurationsdatei aufnehmen.

Fazit

Angesichts der heutigen Bedrohungslage ist es fast schon fahrlässig, eine Windows-Zertifizierungsstelle ohne ein zusätzliches Policy-Modul zu betreiben. Mit Tame My Certs erhalten Sie eine sauber programmierte, kostenlose und aktiv unterstützte Möglichkeit, sowohl auf die Prüfung des Zertifikatsantrags als auch auf die Gestaltung des daraufhin ausgestellten Zertifikats verbindlich und regelbasiert Einfluss zu nehmen. Dafür müssen Sie keinen zusätzlichen PKI-Administrator abstellen, sondern lediglich einige XML-Dateien bearbeiten. Das GitHub-Repository des Projekts hält eine ausführliche Anleitung und zahlreiche Beispiele von XML-Konfigurationen bereit.