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

Les étapes suivantes ne doivent jamais être effectuées dans un environnement de production. La démonstration effectuée ici est la suivante pas Il ne s'agit pas d'un guide sur la manière de pénétrer dans les systèmes informatiques, mais plutôt de mettre en évidence le risque de sécurité afin de pouvoir prendre des contre-mesures.

Le service d'enregistrement des périphériques réseau (Network Device Enrollment Service, NDES) offre la possibilité de demander des certificats auprès d'une autorité de certification pour les périphériques qui ne disposent pas d'un identifiant dans Active Directory (par exemple les périphériques réseau tels que les routeurs, les commutateurs, les imprimantes, les clients légers ou les smartphones et tablettes). Pour une description plus détaillée, voir l'article "Principes de base du service d'enregistrement des périphériques réseau (Network Device Enrollment Service, NDES)„ .

Die Ausgangslage

Connaissez-vous TameMyCerts? TameMyCerts est un add-on pour l'autorité de certification Microsoft (Active Directory Certificate Services). Il étend la fonction de l'autorité de certification et permet de Application de la réglementationIl s'agit d'un logiciel de gestion des certificats qui permet d'automatiser l'émission de certificats en toute sécurité. TameMyCerts est unique dans l'écosystème Microsoft, a déjà fait ses preuves dans d'innombrables entreprises du monde entier et est disponible sous une licence libre. Il peut téléchargé via GitHub et être utilisé gratuitement. Une maintenance professionnelle est également proposée.

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.

Le site 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.

L'attaque

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 Événement d'audit über eine Zertifikatausstellung est généré.

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 Événement n° 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.

Contre-mesures

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.
Die standardmäßig von NDES verwendeten Version 1 Zertifikatvorlagen sollten dringend gegen eigene ausgetauscht werden (siehe auch ESC15).
Der beantragbare Zertifikatinhalt sollte durch das TameMyCerts Policy Modul auf der Zertifizierungsstelle strikt definiert und erzwungen 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.
L'extension de certificat "Application Policies sollte auf allen Zertifizierungsstellen deaktiviert werden.
Wenn keine Smartcard Anmeldung eingesetzt wird, sollten die Domänencontroller-Zertifikate auch keine entsprechenden Extended Key Usages beinhalten.
Für die Ereignisse der Autorité de certification und des Service d'enregistrement des périphériques réseau sollte eine Überwachung verdächtiger Ereignisse eingerichtet werden, und eine Alarmierung ausgelöst werden.

Liens complémentaires :

Sources externes

Vulnerability Note VU#971035 – Simple Certificate Enrollment Protocol (SCEP) does not strongly authenticate certificate requests (Université Carnegie Mellon)
Writing Custom Modules (Microsoft)
Exploiter ADCS NDES pour l'escalade des privilèges (Giulio Pierantoni)