Von Null auf Enterprise Administrator durch den Registrierungsdienst für Netzwerkgeräte (NDES) – und was dagegen getan werden kann

Nachfolgend möchte ich eine der breiten Öffentlichkeit vielleicht nicht unbedingt bekannte hochgefährliche PKI-Konfiguration vorstellen, die so in Unternehmensnetzwerken wahrscheinlich recht häufig angetroffen werden kann.

Ich zeige auf, wie durch Ausnutzung verschiedener unglücklicher Umstände in der Windows-PKI eine Erhöhung von Rechten, ausgehend von bloßem Netzwerkzugang bis hin zur vollständigen Übernahme des Active Directory möglich ist.

Der initiale Angriffspunkt ist in diesem Beispiel der Registrierungsdienst für Netzwerkgeräte (NDES).

Die nachfolgenden Schritte sollten niemals in einer produktiven Umgebung durchgeführt werden. Bei der hier durchgeführten Demonstration handelt es sich nicht um eine Anleitung zum Einbrechen in Computersysteme, sie soll vielmehr das Sicherheitsrisiko aufzeigen, um Gegenmaßnahmen einleiten zu können.

Der Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES) bietet eine Möglichkeit, Geräten, welche nicht über eine Kennung im Active Directory verfügen (beispielsweise Netzwerkgeräte wie Router, Switches, Drucker, Thin Clients oder Smartphones und Tablets), Zertifikate von einer Zertifizierungsstelle zu beantragen. Für eine detailliertere Beschreibung siehe Artikel "Grundlagen Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)".

Die Ausgangslage

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.

Die Umgebung

Das angegriffene Unternehmen betreibt einen Registrierungsdienst für Netzwerkgeräte (NDES). Dieser ist so konfiguriert, dass Zertifikatanforderungen ohne Passwort verwendet werden können, da laut Aussage der Systembetreiber die Endgeräte nicht mit einem Challenge Passwort umgehen können (oder ihnen dies zu aufwändig ist).

Der NDES Server ist über Port 80 und 443 (mit SSL) aus dem Netzwerk erreichbar. Die URL für die Zertifikatbeantragung lautet:

http://{NDES-Server}/certsrv/mscep

Diese Adresse kann auch mit einem Browser aufgerufen werden.

In der präsentierten HTML-Antwort ist kein Hinweis darauf enthalten, ob der NDES ein Passwort verlangt oder nicht. Versucht man eine Zertifikatbeantragung gegen einen NDES Server, der ein Passwort verlangt, ohne Passwort oder mit dem falschen Passwort, wird das Ereignis Nr. 29 auf dem NDES-Server protokolliert, was einen Alarm auslösen bzw. sollte.

Die durch den NDES beantragten und durch die Zertifizierungsstelle ausgestellten Zertifikate beinhalten das Extended Key Usage für "Client Authentication" da die Endgeräte hiermit eine Anmeldung am Netzwerk durchführen, oder einen VPN-Tunnel etablieren und sich hierbei mit dem Zertifikat authentifizieren.

Die Zertifizierungsstelle ist gemäß der Standardeinstellungen bei ihrer Installation in das NTAuthCertificates Objekt im Active Directory aufgenommen worden.

Die Domänencontroller sind mit entsprechenden Zertifikaten ausgestattet, um unter Anderem LDAP-Verbindungen über SSL zu ermöglichen. Da die Domänencontroller-Zertifikate den Standardeinstellungen entsprechen, ist die Umgebung somit aber auch für Smartcard Anmeldung aktiviert.

Der Angreifer

Der Angreifer hat sich Zugang zum Netzwerk verschafft, beispielsweise durch physischen Zugriff auf einen Netzwerkanschluss, eine Verbindung über Wifi oder durch initiale Infektion eines internen Computers.

Als Software benötigt er lediglich einen regulären Computer und einen regulären Client für das SCEP-Protokoll. Unter Windows können dies beispielweise die integrierte certreq.exe oder das PSCertificateEnrollment PowerShell Modul sein, unter Linux das sscep Paket.

Der Angriff

Aus Gründen der Veranschaulichung wurde das PSCertificateEnrollment PowerShell Modul verwendet. Zur Sicherheit noch einmal der Hinweis, dass dieses Vorgehen mit jedem beliebigen anderen Client für das SCEP Protokoll durchführbar wäre.

Zertifikat beantragen

Der Angreifer beantragt ein Zertifikat über den NDES-Server.

Hierbei gibt er, da weder NDES noch die dahinterlegende Zertifizierungsstelle eine Prüfung der beantragten Identität vornehmen, den Benutzerprinzipalnamen (User Principal Name, UPN) eines administrativen Kontos (hier im Beispiel wird das vordefinierte Administrator-Konto verwendet) an.

Get-NDESCertificate `
-PrivateKeyExportable `
-ComputerName "ndes.adcslabor.de" `
-Upn "Administrator@intra.adcslabor.de"

Vielleicht ist der Port 80 für die Zertifikatbeantragung auf die konkret zu verwendenden IP-Adressen eingeschränkt, sodass keine Zertifikatbeantragung über HTTP möglich ist. Vielleicht besitzt der Server jedoch ein SSL-Zertifikat und kann über den Port 443 erreicht werden?

Er bekommt von der Zertifizierungsstelle über den NDES-Server ein entsprechendes Zertifikat ausgestellt.

Um seine Spuren bereits hier besser verwischen zu können, könnte der Angreifer auch noch einen vermeintlich legitimen Subject Distinguished Name (DN) angeben, welcher in der Zertifizierungsstellen-Datenbank angezeigt würde. Der Subject Alternative Name, in welchem sich die Identität des Active Directory Kontos befindet, ist nicht in der Zertifizierungsstellen-Datenbank indiziert.

Anmelden als Enterprise Administrator

Der Angreifer kann sich nun mit diesem Zertifikat als Administrator am Netzwerk anmelden, z.B. per Import des Zertifikats in eine Smartcard.

Da die Domänencontroller das "Client Authentication" Extended Key Usage für Smartcard Anmeldungen akzeptieren (in der Standardeinstellung werden die Extended Key Usages sogar überhaupt nicht validiert), ist eine Anmeldung mit dem Zertifikat problemlos möglich.

Bereits jetzt hat der Angreifer vollständige Kontrolle über die Umgebung. Das für die Anmeldung verwendete Zertifikat befindet sich allerdings noch in der Zertifizierungsstellen-Datenbank, wo es (wenn auch nicht leicht) noch entdeckt werden könnte.

Der Angreifer könnte sich daher nun mit der administrativen Identität direkt an der Zertifizierungsstelle anmelden. Dann könnte er sich ein neues Zertifikat direkt durch Verwendung des privaten Schlüssels der Zertifizierungsstelle erstellen.

Da diese Signatur an der Zertifizierungsstellen-Software vorbei erfolgt ist, und direkt auf den Key Storage Provider zugegriffen wurde, ist dieses Zertifikat auch nicht in der Zertifizierungsstellen-Datenbank zu finden. Ebenfalls wird kein Audit-Ereignis über eine Zertifikatausstellung erzeugt.

Letztendlich könnte der Angreifer das ursprünglich über NDES beantragte Zertifikat noch aus der Zertifizierungsstellen-Datenbank löschen.

Sofern Auditing aktiviert ist, würde die Löschung eines Zertifikats aus der Zertifizierungsstellen-Datenbank das Ereignis Nr. 4896 auslösen. Der Angreifer könnte (was jedoch auch wieder ein Ereignis auslösen würde) aber auch noch das Auditprotokoll auf der Zertifizierungsstelle löschen.

Spätestens ab diesem Zeitpunkt wäre der Angreifer in der Lage, sich nahezu unbemerkt im Unternehmens-Netzwerk zu bewegen.

Gegenmaßnahmen

Die Angriffsoberfläche kann durch Einsatz des TameMyCerts Policy Moduls auf der Zertifizierungsstelle drastisch reduziert werden. Beispielsweise kann durch dieses festgelegt werden, welche Zertifikat-Felder beantragt werden dürfen, ebenso kann eine Einschränkung für die auszustellenden Konten vorgenommen werden.

Grundsätzlich sollte es vermieden werden, einen NDES Server ohne Passwort zu betreiben. Vielmehr sollte evaluiert werden, ob es nicht doch möglich ist, (im Zweifelsfall wenigstens täglich) wechselnde Passwörter einzusetzen. Hierbei darf man sich aber nicht in falscher Sicherheit wägen, auch mit Passwort"schutz" ist die Authentisierung über SCEP immer noch sehr oberflächlich.
Sofern möglich, sollten NDES-Server niemals dem gesamten Netzwerk gegenüber exponiert werden. Vielmehr sollte der Zugriff so weit wie möglich eingeschränkt werden.
Es ist sinnvoll, regelmäßig Auswertungen über die von Zertifizierungsstellen, an welche ein NDES Server angebunden ist, ausgestellten Zertifikate anzufertigen und nach Abweichungen zu durchsuchen. Um dies realisieren zu können, muss aber bereits vor Inbetriebnahme des NDES Servers der Regelfall (zulässige Zertifikatinhalte) festgelegt sein.
Zertifizierungsstellen, an welche ein NDES-Server angebunden sind, sollten grundsätzlich aus dem NTAuthCertificates Objekt im Active Directory entfernt werden.
Wenn keine Smartcard Anmeldung eingesetzt wird, sollten die Domänencontroller-Zertifikate auch keine entsprechenden Extended Key Usages beinhalten.
Für die Ereignisse der Zertifizierungsstelle und des Registrierungsdienstes für Netzwerkgeräte sollte eine Überwachung verdächtiger Ereignisse eingerichtet werden, und eine Alarmierung ausgelöst werden.

Weiterführende Links:

Externe Quellen

Vulnerability Note VU#971035 – Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests (Carnegie Mellon University)
Writing Custom Modules (Microsoft)
Exploiting ADCS NDES For Privilege Escalation (Giulio Pierantoni)