TL;DR Wer NDES einsetzt, sollte ein Auge darauf haben, welche Zertifikate darüber bezogen werden können und tatsächlich bezogen werden, damit er nicht den Nachschlüssel zu seinem Active Directory verliert.
Und nicht ganz vertrauenswürdige Trusted Root Zertifikate sollte man sich aus diesem Grunde auch nicht unterschieben lassen, zumindest nicht auf Domain Controllern.
Im letzten Abschnitt gibt es Empfehlungen für Schutzmaßnahmen.
Gerade bin ich von einer längeren Reise zurückgekommen. Einer virtuellen Reise in die Weiten der Windows- und AD-Landschaft, die ich als Folge meines vorigen Blog-Artikels zu PetitPotam angetreten habe. Hier der Reisebericht:
Und was ist mit NDES?
Neben dem Certificate Authority Web Enrollment und dem Certifcate Enrollment Web Service (CES), die Microsoft in seinem Advisory zu PetitPotam erwähnt, gibt es noch ein drittes Rollenfeature des AD Certificate Service, das es ebenfalls erlaubt, Zertifikate zu beantragen und zu beziehen, ebenfalls als Web-Anwendung unter dem IIS implementiert ist und ebenfalls per NTLM-Authentifikation angesprochen werden kann: der Network Device Enrollment Service (NDES), Microsofts Implementierung des SCEP Protokolls.
Da drängt sich natürlich die Frage auf: Ist NDES eventuell ebenfalls anfällig gegen einen NTLM-Relay Angriff?
Der NDES besteht aus zwei Web-Schnittstellen.
- mscep ist die eigentliche SCEP-Anwendung, über die Clients -beispielsweise ein von einem MDM gemanagtes iPhone- sich ihre Zertifikate besorgen können.
Über einen Registry-Key können bis zu drei verschiedene Zertifikatsvorlagen konfiguriert werden, nach denen Zertifikate per SCEP bezogen werden können. In der Praxis ist meist für alle drei derselbe Template-Name eingetragen.
Zur Nutzung des SCEP-interfaces muss sich der Client nicht auf HTTP-Ebene authentisieren. NTLM ist hier also nicht im Spiel. Stattdessen muss der SCEP-Client seinem Zertifikatsantrag ein Einmalpasswort beifügen (man kann auch einstellen, dass das SCEP-Passwort wiederverwendet wird, aber das wird ja wohl niemand machen, oder?). - mscep_admin ist die Web-Schnittstelle über die entweder berechtigte Administratoren per Browser oder technische Konten -z. B. unseres oben erwähnten MDM- die SECP-Einmalpasswörter abrufen können, um sie zusammen mit den notwendigen weiteren Konfigurationsdaten an die einzelnen SCEP-Clients weiter zu reichen (unser MDM macht das natürlich über seine Schnittstelle zur Verwaltung der gemanagten iPhones und Galaxys und belästigt damit nicht die Besitzer dieser Geräte).
mscep_admin erfordert eine IWA Windows-Anmeldung, ist also potenziell anfällig für NTLM-Relay-Angriffe. Allerdings kann sich nur erfolgreich anmelden, wer auch "Enroll"-Rechte für die in der Registry konfigurierten Zertifikatsvorlagen besitzt. Und das sind in der Regel nicht Domain Controller (hey, wer würde das schon einstellen?), sondern standardmäßig Domänen- und Organisations-Administratoren sowie meist dedizierte Administratoren für den NDES und/oder technische User-Konten (hatte ich schon MDM gesagt?). Gegen die lässt sich ein NTLM-Relay-Angriff nicht so leicht triggern, wie bei PetitPotam durch eine vorgebliche EFS-Anfrage an einen Domain Controller. Aber der Angreifer könnte sie z. B. mit ihrem IWA-aktivierten Browser auf eine eigene Webseite locken und dann hinterrücks mit deren Rechten vom mscep_admin ein Einmalpasswort zum späteren Umtausch in ein Zertifikat besorgen.
Zwischenstand der Reise: Ein erfolgreicher Angriff scheint nicht ganz so einfach, aber auch nicht ausgeschlossen. Schauen wir also, wie ein Zertifikat aussehen muss, damit es für den Bezug eines Kerberos-Tickets genutzt werden kann.
Kerberos Variationen
Das Kerberos PKINIT Verfahren, mit dem man sich zertifikatsbasiert an einem Domain Controller -genauer, an dessen Kerberos Key Distribution Center (KDC) Dienst- anmelden kann, um ein Kerberos-Ticket zu bekommen, wurde von Microsoft ursprünglich implementiert, um ein AD-Login mit Smartcard-Zertifikaten zu ermöglichen. Daher ist es ein verbreitetes Missverständnis, dass es nur mit Zertifikaten genutzt werden kann, deren Private Key unauslesbar auf einer Smartcard gespeichert ist.
Aber letztlich sieht der Domain Controller dem Zertifikat nicht an, wo dessen zugehöriger Private Key abgelegt ist; neuere Mechanismen wie Key Attestation kommen hier nicht zum Einsatz. So kann man also auch erfolgreich mit Software-Zertifikaten und -Schlüsseln (oder solchen im TPM oder in einem anderen Hardware-Modul) ein Kerberos-Ticket beantragen, wenn der Client das denn unterstützt. Microsoft selbst nutzt das unter der Motorhaube von Windows Hello for Business für die AD-Anmeldung, nachdem sich der Anwender lokal am Arbeitsplatzrechner per Fingerabdruck, Gesichtserkennung oder PIN ausgewiesen hat. Für Pentests bietet sich das mimikatz-Schwestertool kekeo an (für "unbestellte Pentests" gibt es Alternativen, die nicht so leicht vom Windows Defender oder anderer Antivirus-Software erkannt werden).
Kerberos Eskalationen
Das Ziel eines Angreifers auf unserer Reise ist es, ein Zertifikat (samt Zugriff auf dessen privaten Schlüssel, aber das wissen meine Leser sicher) zu erlangen, mit dem er sich gegenüber dem KDC als Domänen- oder Organisations-Administrator oder mit dem Computerkonto eines Domain Controllers anmelden kann (dann stünde das Active Directory offen, in der Praxis reicht es vielleicht, als Zwischenschritt ein Konto zu kapern, das auf einem wichtigen Server lokale Administrationsrechte hat). Christoph Falta hat das einem sehr lesenswerten Beitrag, in dem er ein schönes Praxis-Szenario ausmalt, wie es ungewollt so weit kommen kann, "Golden Certificate" getauft. Und wie in einem Blogbeitrag von
Wie muss nun so ein goldenes Zertifikat aussehen? Seit Windows 2000 sollten Zertifikate zum Smartcard-Logon die folgenden beiden Bedingungen erfüllen:
- In der SubjectAltNames (SAN) Erweiterung sollte der Windows-UPN des Benutzerkontos bzw. der DNS-Name des Computerkontos stehen.
- In der ExtendedKeyUsage (EKU) Erweiterung (ich verstehe bis heute nicht recht, wieso Microsoft die EKU "Enhanced"KeyUsage nennt und zudem in einer eigenen Zertifikatserweiterung ApplicationPolicies spiegelt) sollte die OID SmartcardLogon (1.3.6.1.4.1.311.20.2.2) enthalten sein.
Aber so, wie Juristen "grundsätzlich" sagen und dabei meinen "mit den Ausnahmen können wir unseren Lebensunterhalt verdienen", sagt Microsoft "sollte" und meint "auf Drängen wichtiger Kunden können wir Alternativen dazu implementieren". In unserem Fall gab es wohl Microsoft-Kunden, die schon in großer Zahl Smartcards und Zertifikate verteilt hatten, die diese Bedingungen nicht erfüllten (wenn ich wetten müsste: die Common Access Cards des US-Militärs oder deren Nachfolger PIV). Und für die hat Microsoft die Option implementiert, dass nicht der UPN bzw. DNS-Name in einem speziell dafür auszustellenden Zertifikat angegeben werden müssen, sondern auf der anderen Seite des Anmeldeprozesses die Beschreibung eines oder mehrerer ggf. vorhandener Zertifikate als Post-It Notiz an das Benutzer- bzw. Computer-Objekt im AD geklebt werden kann. Das nennt Microsoft "Explicit Mapping" und hat es z. B. hier oder hier genauer beschrieben (und im Detail widersprüchlich, ich tippe die erstere Fundstelle hat recht). Für Explicit Mapping gibt es die folgenden Alternativen:
- Issuer und Subject Distinguished Name (DN) des Zertifikats (*)
- Subject DN des Zertifikats
- Issuer DN und Seriennummer des Zertifikats (*)
- SubjectKeyIdentifier (SKI) Erweiterung des Zertifikats (*)
- Public Key Hashwert (SHA-1, aber das ist an dieser Stelle relativ unktitisch) (*)
- E-Mail-Adresse (RFC822Name) im SAN des Zertifikats
Die Stelle, an der das Post-It angeklebt wird, ist das AD-Attribut altSecurityIdentities. Per Default ist dieses Attribut leer und bleibt das in aller Regel auch. Aber es ist zumindest bei einem AD Security-Audit wert, einmal aufzulisten, ob und an welchen Konten welche Zertifikats-Post-Its kleben. Und natürlich sind Schreibrechte auf dieses Attribut sicherheitskritisch.
Mit Windows Server 2016 hat Microsoft dann übrigens noch eine Methode per Public-Key-Pinning eingeführt, damit Nutzer von Windows Hello For Business nicht unbedingt eine PKI aufbauen müssen: Im AD-Attribut msDS-KeyMaterial kann der Public Key des Users bzw. Computers eingestellt werden; wird die genutzt, dann entfällt auch die lästige Zertifikatsvalidierung. Natürlich ist der Schreibzugriff auf msDS-KeyMaterial genau so kritisch wie der auf altSecurityIdentities.
Was jetzt kommt, wird sicher (hoffentlich?) die meisten Leser meines Blogs schockieren:
Ich bin bei technischen Aussagen in meinen Blog-Artikeln nicht immer ganz vollständig. Die im vorigen Artikel genannte Rückversicherung über den NTAuth-Container (d. h. die Issuing-CA des Authentifikationszertifikats muss explizit darin aufgeführt sein) gilt nicht für die oben mit "(*)" gekennzeichneten Fälle. Das heißt in diesen Varianten sind gültige Zertifikate unter irgendeiner der vertrauenswürdigen Root-CAs für ein Kerberos-Ticket gut. Wie ich früher beschrieben habe sind es alleine ca. 400 öffentliche Roots, die Microsoft ausliefert. Zudem gibt es diverse Wege, sich weitere Trusted Roots einzufangen.
Das ist beim Public Key Hashwert unkritisch, da der reguläre Public Key angegeben ist, zu dem einem Angreifer der Private Key fehlt. Bleiben die drei Fälle mit Issuer DN oder SKI.
Beim SKI ist es ein landläufiges Missverständnis, dass diese Erweiterung den SHA-1 Hashwert des Public Keys enthalten muss. PKIX sagt nur "SHOULD be derived from the public key or a method that generates unique values" und schlägt den SHA-1 Hash als "common method for generating key identifiers" vor. Eine CA könnte stattdessen auch "Anton", "Berta", "Cäsar", ... als SKIs einsetzen, solange es eindeutig bleibt. Und eine vom Angreifer kontrollierte CA kann den SHA-1 Hash des Public Keys in einem fremden, regulären Zertifikat als SKI einsetzen (Bingo).
Und natürlich kann eine vom Angreifer kontrollierte Root-CA ein Issuing-CA-Zertifikat für eine (ich muss nicht wirklich erwähnen: ebenfalls von ihm kontrollierte Issuing-CA) erstellen, das nicht rein zufällig denselben Issuer DN verwendet, wie er ggf. für ein reguläres Zertifikat in der Issuer DN/Subject DN oder der Issuer DN/SerialNumber Variante des Explicit Mapping konfiguriert ist.
Glücklicherweise wird Explicit Mapping ohnehin sehr selten konfiguriert (alleine schon weil kaum jemand es kennt, in diesem Fall ist Unwissen ein Schutz) und speziell die SKI-Variante ist mir noch nie in freier Wildbahn begegnet. Aber bei Security-Audits würde ich schon danach suchen...
Und was jetzt kommt, wird sicher die meisten Leser meines Blogs ebenfalls schockieren:
Microsoft ist bei seiner technischen Dokumentation nicht immer vollständig und korrekt. So wird zum Beispiel an dieser Stelle über das Client-Zertifikat für Kerberos PKINIT gesagt: "If an EKU is present, it must contain the smart card sign-in EKU." (d. h. Microsofts Smartcard Logon OID). Aber wie Jean Marsault in einem ebenfalls sehr lesenswerten Blogartikel schreibt und der der Autor dieses Blogs nachgeprüft hat, reicht auch eine der folgenden EKU OIDs:
- Any Purpose,
- Kerberos KDC Client Authentication oder
- (Trommelwirbel!) Client Authentication
Und was ist jetzt mit NDES?
Damit sind wir wieder beim NDES, denn NDES verwendet stets anfällige Zertifikatsvorlagen. Und zwar in den meisten Fällen solche, die eine Client Authentication EKU enthalten. Beispielweise, damit sich die MDM-gemangten iPhones mit diesem Zertifikat per WPA2/3 Enterprise am Unternehmens-WLAN anmelden können.
Ein per NDES bezogenes Zertifikat mit dem UPN administrator@ad-domain.local ist also potenziell ein goldenes.
Und beim NDES hat Microsoft hat eine Leiche im Keller, vor der 2012 sogar in einer CERT Vulnerability Note gewarnt wurde: Einige andere CA-Produkte generieren individuelle SCEP-Passwörter für bereits vor-registrierte Zertifikatsinhaber und mit einem solchen SCEP-Einmalpasswort kann dann auch nur ein Zertifikat für diesen Inhaber abgerufen werden. Anders beim NDES in Standardinstallation, da ist das SCEP-Einmalpasswort ein Gutschein für ein Zertifikat mit frei gewähltem Inhabernamen (nochmal Trommelwirbel!).
Der Grund, warum die erwähnte CERT Vulnerability Note in der aktuellen Fassung freundlicher mit dem NDES umspringt, ist, dass NDES seit Windows Server 2012 R2 die Schnittstelle für ein NDES Policy Modul anbietet. Ein solches NDES Policy Modul darf dann:
- Beim Abruf des SCEP-Einmalpassworts notieren, für welchen Zertifikatsinhaber es gedacht ist.
- Beim Eingang des Zertifikatsrequests (CSR) vom SCEP-Client nachprüfen, dass Einmalpasswort und der im CSR gewünschte Inhaber zusammenpassen und ggf. die Ausstellung des Zertifikats blockieren.
Leider liefert Microsoft kein NDES Policy Modul mit dem AD Certificate Serivce (anders als z. B. das Default ADCS Policy Modul), sondern es muss mit dem jeweiligen MDM mitgeliefert werden (oder auch nicht). Nur durch die Integration mit dem MDM kann es auch in Schritt 1 wissen, für welches Gerät das Zertifikat gedacht ist.
Allerdings könnte ein generisches NDES Policy Modul in Schritt 2 sicherstellen, das zumindest kein in einer entsprechenden Blacklist konfigurierter Name eines kritischen Users oder Computers enthalten ist.
[Werbe-Einblendung: Hat jemand Lust ein solches NDES Policy Modul als Bachelor-Arbeit o. ä. zu implementieren? Ich wüsste da einen Betreuer ;-)]
Der Gutschein für ein goldenes Zertifikat ist also ein SCEP-Einmalpasswort eines NDES, der ohne geeignetes (ja, man könnte das auch zu lax implementieren) Policy-Modul läuft, Zertifikate mit EKU Client Authentication ausstellt und dessen CA im NTAuth Container gelistet ist. Diese Vorbedingungen anzutreffen, ist leider gar nicht so unwahrscheinlich. Und um ein solches (ah, ich kreiere jetzt auch einmal ein neues Buzzword:) "Golden SCEP-Challenge" zu bekommen, gibt es sehr unterschiedliche Wege:
- Wie am Anfang der Reise beschrieben, könnte man einen PetitPotam-ähnlichen NTLM-Relay Angriff gegen einen am mscep_admin Interface berechtigten Benutzer versuchen (aber das ist eigentlich viel zu kompliziert).
- Der Angreifer kompromittiert den MDM-Administrator (oft ist der nicht zugleich schon AD-Administrator) und damit den technischen Account, der Zugriffsrechte auf mscep_admin hat.
- Der Angreifer ist Besitzer eines MDM-gemanagten, am besten gerooteten, BYOD-Geräts und hinreichend technikaffin, um einige allfällige Tricks auf Lager zu haben (habe ich gerade ein 'Burp' gehört?).
- (Es gibt weitere mögliche Wege, aber hier mache ich das jetzt wie der stereotype Mathemaktik-Professor und überlasse das als Übungsaufgabe dem Leser. Der Blogartikel ist eh' schon viel zu lang geworden.)
Damit ist meine Reise an einem Ziel angekommen, das ich zu Beginn nicht ganz so erwartet hatte.
Empfehlungen
Man sollte im Hinblick auf all diese Attacken-Varianten:
- Sich im Klaren sein, dass CA-Administratoren und Certificate Manager der PKI praktisch betrachtet auch Organisations- und Domain-Administratoren sind.
(Also, wie Jean Marsault sehr richtig schreibt, mitsamt der ganzen PKI ins Tier-0 im ESAE Modell gehören.) - Den Inhalt des NTAuth Containers prüfen und nicht benötigte Issuing-Zertifikate darin löschen. Das geht am einfachsten mit der MMC PKIView.msc, die als Teil der Aministrationstools einer Enterprise-CA installiert wird.
Vermutlich ist es eine gute Idee, dies regelmäßig zu tun, da gerüchteweise eine einmal daraus gelöschte, aber weiter aktive Enterprise-CA sich u. U. selbst wieder hinzufügt, z. B. wenn sie manuell von einem Organisations-Administrator gestartet wird. - Zertifikatstemplates mit "supply the subject name in the request" sparsam verwenden, von der Genehmigung durch einen Certificate Manager oder Enrollment Agent abhängig machen, der prüft, dass keine kritischen Namen von Servern oder Benutzern im Zertifikatsantrag stehen, eher das Zertifikat freigegeben wird. (Außer vielleicht, alle Antragsberechtigten sind ohnehin schon AD-Administratoren oder könnten das Passwort dazu auf Zuruf vom Kollegen am anderen Ende des Großraumbüros bekommen.)
- Änderungen an Zertifikatstemplates und ausgestellte Zertifikate, besonders solche nach anfälligen Templates, protokollieren und regelmäßig prüfen (und natürlich auffällige Zertifikate unverzüglich sperren etc.).
Speziell für letzteres kann man sich das Leben vereinfachen, indem man das SMTP-Exit-Modulder AD Certificate Services (ohje, das schreit nach noch einem künftigen Blog-Beitrag) nutzt und ggf. so anpasst, dass Subject und SAN-Inhalt des ausgestellten Zertifikats in der Benachrichtigungsmail an den CA-Administrator enthalten sind. - Bei AD-Audits (oder einfach, wenn man sich unsicher ist und die Zeit dafür findet) für sicherheitskritische Benutzer und Computer die Belegung der Attribute altSecurityIdentities und msDS-KeyMaterial und die Schreibrechte darauf prüfen.
Update: Dabei kann z. B. ldifde helfen und normalerweise sollte das reine Lesen jedem am AD angemeldeten Benutzer möglich sein (ja, im Zweifel auch Angreifern):
ldifde -f check.ldif -r "(|(altSecurityIdentities=*)(msDS-KeyMaterial=*))" -l "altSecurityIdentiti
es,msDS-KeyMaterial" - Regelmäßig auf allen Domain Crontroller prüfen, welche Trusted Root CA installiert sind, die nicht über das Microsoft Root Program kamen, und ggf. nachhaken. Das geht z. B. mit einem Tool aus der Sysinternals Suite per
sigcheck64 -tv Root
Besonders wichtig ist dies, wenn Explicit Mapping tatsächlich genutzt wird, d. h. altSecurityIdentities nicht bei allen kritischen Benutzern und Computern leer ist. - NDES, wenn überhaupt, möglichst mit einem NDES Policy Modul betreiben, das auch sicher stellen kann, dass keine Namen sicherheitskritischer Benutzer oder Computer (vulgo: Domain-Administratoren und Domain Computer und derlei weiteres) in den eingereichten Zertifikatsanträgen enthalten sind.
- NDES, wenn technisch möglich, an einer dedizierten Issuing-CA betreiben, deren Zertifikat nicht in NTAuth enthalten ist (dafür sollte wahrscheinlich der RADIUS Server für WLAN oder NAC nicht NPS heißen, sondern FreeRadius, Cisco ISE oder dergleichen).
In den drei zitierten Blog-Artikeln sind einige weitere mögliche Schutzmaßnahmen aufgeführt.