Security – Uwe Gradenegger

Angriff auf das Active Directory über Microsoft Intune – und wie er mit TameMyCerts eingedämmt werden kann

Dirk-jan Mollema hat jüngst einen Angriff vorgestellt, bei welchem man sich über Intune ein Zertifikat für hochprivilegierte Konten erschleichen kann. Dieses kann dann verwendet werden, um die gesamte Active Directory Umgebung zu kompromittieren.

Der Angriff ist in seinen Grundzügen vergleichbar mit dem, was ich schon im Artikel "Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann" und im Artikel "Angriffsvektor auf den Active Directory Verzeichnisdienst über den Smartcard Logon Mechanismus" beschrieben habe (im Allgemeinen auch auch bekannt als ESC1).

Neu ist jedoch, das Mobile Device Management (MDM) System – in diesem Fall Microsoft Intune – entsprechend auszunutzen.

Nicht neu ist hingegen was mit dem TameMyCerts Policy Modul für die Active Directory Certificate Services dagegen getan werden kann, um Angriffsoberfläche drastisch zu reduzieren.

Die Security Identifier (SID) Zertifikaterweiterung in per Mobile Device Management (MDM) beantragte Zertifikate automatisch eintragen – mit dem TameMyCerts Policy Modul für die Microsoft Active Directory Certificate Services (ADCS)

Nach mehrfachen Verschiebungen hat Microsoft letztendlich entschieden, dass die Änderungen an der Zertifikatausstellung und an der zertifikatbasierten Anmeldung am Active Directory mit dem Patch für Windows Server vom 10. Mai 2022 (KB5014754) nun endgültig in Kraft treten sollen.

Domänencontroller werden zum 25. Februar 2025 daher automatisch in den Full Enforcement Mode gehen, wenn nichts anderes konfiguriert ist. Zum September 2025 ist angekündigt, dass abweichende Einstellungen wegfallen werden und somit keine Alternative mehr zum Full Enforcement bestehen wird.

Dies hat zur Konsequenz, dass für Anmeldungen via PKInit nur noch dann für eine Anmeldung verwendet werden können, wenn sie über die mit dem Patch neu eingeführte Security Identifier (SID) Zertifikaterweiterung verfügen.

Was zunächst klingt, als wäre dies kein großes Problem, kann durchaus zu einem werden, wenn man bedenkt, dass in der heutigen Zeit immer weniger Zertifikat-basierte Anwendungsfälle klassisches Autoenrollment verwenden.

Wie das TameMyCerts Policy Modul für die Active Directory Certificate Services bei diesem Problem helfen kann, wird im nachfolgenden Artikel näher beleuchtet.

Auslesen der Konfiguration der Zertifizierungsstelle durch unprivilegierte Konten unterbinden

Während Penetration Tests und auch für Angreifer, die das Netzwerk nach potentiellen Angriffszielen durchsuchen, sind Einblicke in die Konfiguration der Zertifizierungsstelle hochinteressant.

Nebst eventuellen Fehlkonfigurationen können Angreifer Informationen über das auf der Zertifizierungsstelle verwendete Policy-Modul erlangen.

Smartcard-Anmeldung schlägt fehl mit Fehlermeldung "A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)"

Folgendes Szenario angenommen:

Das Unternehmen möchte Smartcard-Anmeldung einsetzen.
Die Domänencontroller sind mit für Smartcard-Anmeldung verwendbaren Zertifikaten ausgestattet.
Die Benutzer sind mit für Smartcard-Anmeldung verwendbaren Zertifikaten ausgestattet.
Die Anmeldung an der Domäne per Smartcard schlägt mit folgender Fehlermeldung fehl:

A certification chain processed correctly, but one of the CA certificates is not trusted by the policy provider. 0x800b0112 (-2146762478 CERT_E_UNTRUSTEDCA)

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.

Wie das TameMyCerts Policy Modul für Active Directory Certificate Services (ADCS) dabei helfen kann, Szenarien mit Microsoft Intune und anderen Mobile Device Management (MDM) Systemen abzusichern

Unternehmen verwenden Mobile Device Management (MDM) Produkte um mobile Geräte wie Smartphones, Tablet-Computer oder Desktopsysteme über das Internet (Over-the-Air, OTA) zu verwalten, zu konfigurieren und zu aktualisieren.

Gängige Mobile Device Management Produkte sind:

Microsoft Intune
VMware Workspace One (zuvor bekannt unter dem Markennamen AirWatch)
Ivanti MobileIron UEM
Jamf Pro
Baramundi Enterprise Mobility Management
BlackBerry Enterprise Mobility Suite
Sophos Mobile Control
SOTI MobiControl
Samsung Knox
IBM MaaS360

Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle – allein mit Bordmitteln

Im Artikel "Signieren von Zertifikaten unter Umgehung der Zertifizierungsstelle" habe ich beschrieben, wie sich ein Angreifer, der im Besitz administrativer Rechte auf der Zertifizierungsstelle ist, unter Umgehung der Zertifizierungsstellen-Software, also unter direkter Verwendung des privaten Schlüssels der Zertifizierungsstelle, ein Anmeldezertifikat für administrative Konten der Domäne erzeugen kann.

Im vorigen Artikel habe ich das PSCertificateEnrollment Powershell Modul verwendet, um das Vorgehen zu demonstrieren. Microsoft liefert mit certreq und certutil allerdings bereits ab Werk perfekt geeignete Pentesting-Werkzeuge direkt mit dem Betriebssystem mit.

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.

Aktivieren der Basic Authentication für den Registrierungsdienst für Netzwerkgeräte (NDES)

Wird der Registrierungsdienst für Netzwerkgeräte (NDES) neu installiert (Vorzugsweise ohne Enterprise Administrator Berechtigungen), wird zunächst nur die Windows-integrierte Authentisierung für die Administrations-Webseite aktiviert. Mit dieser ist (per NT LAN Manager, NTLM) Protokoll auch eine Authentisierung per Benutzername und Passwort möglich. Nicht alle Client-Anwendungen unterstützen diese jedoch.

Ebenso könnte ein Unternehmen gewillt sein, NTLM wo möglich zu deaktivieren und Kerberos für die Anmeldung zu erzwingen. Mit dem Erzwingen von Kerberos fällt die Möglichkeit weg, sich per Benutzername und Passwort an der Administrations-Seite für den Registrierungsdienst für Netzwerkgeräte anzumelden (da dies mit NTLM-Anmeldedaten erfolgt). Um hier wieder eine Möglichkeit zu schaffen, kann jedoch die Basic Authentication nachgerüstet werden.

Einen Ausweg aus diesem Dilemma kann die Basic Authentisierung sein, deren Einrichtung im folgenden dargelegt werden soll.

Deaktivieren von NTLM und erzwingen von Kerberos an der Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES)

Viele Unternehmen verfolgen die Strategie, das NT LAN Manager (NTLM) Authentisierungsprotokoll in ihren Netzwerken (weitestgehend) abzuschalten.

Auch für die Administrations-Webseite des Registrierungsdienstes für Netzwerkgeräte (NDES) ist dies möglich. Wie genau die Umsetzung erfolgt, und wie sich dadurch eventuell das Anwendungsverhalten ändert soll nachfolgend erläuert werden.

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

Grundlagen: Namenseinschränkungen (Name Constraints)

Namenseinschränkungen sind ein Teil des X.509 Standard und im RFC 5280 beschrieben. Sie sind ein Werkzeug, das im Rahmen der qualifizierten Subordinierung eingesetzt werden kann, um den Gültigkeitsbereich eines Zertifizierungsstellenzertifikats feingranular zu steuern.

Grenzen der Microsoft Active Directory Certificate Services

Die Active Directory Certificate Services bestehen (wenn auch unter anderem Namen) in ihren Grundzügen seit Windows NT 4.0. Die heutzutage verwendete auf Active Directory besierende Architektur wurde mit Windows 2000 Server eingeführt. Die AD CS sind sehr gut in das Windows-Ökosystem integriert und erfreuen sich weiterhin weltweit großer Beliebtheit in Unternehmen und Behörden jeglicher Größenordnung.

Gerne wird auf die vielen Möglichkeiten hingewiesen, welche die Active Directory Certificate Services bieten. Selten wird allerdings darauf verwiesen, was mit ihnen nicht möglich ist. Das Produkt stößt nämlich mittlerweile an vielen Stellen auch an seine Grenzen.

Welche das sind, soll nachfolgend näher ausgeführt werden, um besser entscheiden zu können, ob die AD CS für geplante Vorhaben die richtige Lösung sein können.