Springe zum Inhalt


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 Carl Sörqvist näher beschrieben, muss so ein goldenes Zertifikat nicht einmal unbedingt genutzt werden, um es am KDC in ein Kerberos-Ticket umzutauschen; es reicht ggf. auch als TLS-Clientzertifikat, um damit per LDAPS wüste Dinge ins AD zu schreiben.

Und wie in beiden Blogs dargestellt, liegt das Hauptproblem dabei in einer der Schwächen der Microsoft PKI. Eine der besonderen Stärken der AD Certificate Services ist es, dass sie die Namensinformation in auszustellenden Zertifikaten aus dem AD-Benutzer- oder -Computer-Objekt des Zertifikatsinhabers entnehmen kann. Eine der besonderen Schwächen der AD Certificate Services ist es, dass sie, wenn es kein AD-Benutzer- oder -Computer-Objekt des Zertifikatsinhabers gibt, nur noch die Möglichkeit bietet (außer man schreibt sich ein proprietäres ADCS-Policy-Modul, aber das muss ich ein einem künftigen Blogbeitrag auswalzen), die Namensinformation (Subject DN und SAN) aus dem Zertifikatsantrag zu übernehmen (ja, genau, den versucht unser Angreifer passend unterzuschieben). Die  Zertifikatsvorlagen, bei denen "supply the subject name in the request" eingestellt sind, sind also die anfälligen. Das sind typischerweise Templates z. B. für TLS-Serverzertifikate für Linux-Server und andere Nicht-AD-Systeme oder (Achtung, das merken wir uns jetzt bis weiter unten) Client-Zertifikate für Mobilgeräte usw., die per SCEP/NDES bezogen werden sollen.

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:

  1. Beim Abruf des SCEP-Einmalpassworts notieren, für welchen Zertifikatsinhaber es gedacht ist.
  2. 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.

Nachdem mein Blog leider viel zu lange eingeschlafen war, gibt es jetzt einen unvermuteten aktuellen Anlass, die eben so lange gehegten guten Vorsätze in die Tat umzusetzen und es wieder aufleben zu lassen.

Von den meisten Windows Schwachstellen und monatlichen Cumulative Updates sind die Active Directory Certificate Services (a.k.a. Microsoft PKI) allenfalls indirekt betroffen. Das ist bei dem am 18.07.2021 unter dem Namen "PetitPotam" publizierten Angriff nun anders.

Exkurs in die Weiten der Windows-Landschaft

PetitPotam ist ein Angriff auf eine eigentlich altbekannte Schwachstelle im NTLM-Authentifikationsmechanismus von Windows, der einem Angreifer ggf. die Übernahme der kompletten AD Domäne ermöglichen kann.

Viele Schwachstellen in Windows rühren aus dem -vermeintlichen oder echten- Zwang zur Rückwärtskompatibilität mit bestehenden alten bis uralten Systemen und Anwendungen. Der Rückwärtskompatibilität ist geschuldet, dass eingentlich überholte, längst ersetzte Verfahren und Schnittstellen immer noch nicht nur unterstützt werden, sondern standardmäßig aktiviert sind. So auch das NTLM Authentifikationsverfahren, das, wie der Name namelegt, auf das Windows NT der 90er Jahre zurück geht und für das seit der Einführung des Active Directory (für die jüngeren Leser: mit Windows 2000) mit Kerberos eigentlich ein sichererer Ersatz zur Verfügung steht. Aber anscheinend ist es für Entwickler bis heute manchmal bequemer, statt Kerberos noch noch NTLM zu verwenden.

Bei NTLM sind sogenannte Relay-Angriffe möglich. Wenn ein AD-Benutzer oder AD-Computer sich -beispielsweise über die Integrierte Windows-Authentifikation (IWA) eines Browsers, bei der standardmaßig ausgehandelt wird, ob Kerberos oder NTLM verwendet werden soll- per NTLM an einem System des Angreifers anmeldet, kann der sich hinterrücks, ebenfalls per NTLM, mit dem Konto des Opfers an anderen Systemen anmelden. Das Prinzip ist seit ca. 2001 bekannt und z. B. in OWASP Vortragsfolien aus dem Jahr 2008 oder einem Microsoft Advisory aus dem Jahr 2009 beschrieben.

Zurück zur PKI

PetitPotam kann nun u. a. die Certificate Authority Web Enrollment und Certifcate Enrollment Web Service (CES) Features der AD Certificate Services für einen NTLM-Relay-Angriff ausnutzen.

Update: Zur Klarstellung: den CES kann man in bis zu drei Varianten installieren - mit zertifikatsbasierter Authentifikation, mit Kerbreros-Authentifikation und mit Username/Passwort. Betroffen und nachfolgend stets gemeint ist die Variante mit Kerberos-Authentifikation (die in Wirklichkeit standardmäßig nicht nur Kerberos, sondern alternativ Kerberos oder NTLM unterstützt, leider etwas irreführend bezeichnet).

Dabei ist -zumindest im einfachsten Fall für den Angreifer- das Opfer der Computer-Account eines Domain Controllers und die PKI das System auf das hinterrücks zugegriffen wird. Benjamin Delpy, der Autor des bekannten Analyse-Tools (böse Zungen sagen auch: Hackertools) Mimikatz hat das in einem kurzen Video demonstriert:

  1. Der Angreifer installiert auf seinem System (das muss kein Windows System sein, im Beispielvideo ist es ein Linux-Rechner) ein NTLM-Relay-Tool, das die NTLM-Credentials der Gegenseite beispielsweise bei Zugriffen per Enrypted File System (EFS) abgreifen kann. Auch dabei wird nämlich IWA mit NTLM-vs.-Kerberos Negotiaton genutzt. (Gesegnet, wer vollständig weiß, wo überall noch.)
  2. Er versucht, auf ein EFS Share bei einem Domain Controller zuzugreifen. Ob dieser Zugriff erfolgreich ist oder nicht, spielt keine Rolle, solange der Angreifer dabei die NTLM-Credentials des Domain Controllers in die Finger bekommt. (Dass bei einem Zugriffsversuch nicht nur der Client, sondern immer auch der Server sich authentifiziert ist ja gute Praxis. Aber dass der Server bei beliebigen Clients seine Credentials abliefert, darüber sollte man noch einmal nachdenken.)
  3. Hinterrücks holt das NTLM-Relay des Angreifers sich über das Web-Enrollment der CA (alternativ ginge auch der CES, daher ist dieser ebenfalls betroffen) mit den abgegriffenen NTLM-Credentials ein Domain Controller Zertifikat auf den Namen des angegriffenen Domain Controllers. Natürlich für ein Schlüsselpaar, das der Angreifer gerade generiert hat.
  4. Mit diesem erschlichenen Zertifikat besorgt sich der Angreifer beim Kerberos Dienst eines Domain Controllers -im Zweifel dem, der gerade angegriffen wurde- ganz regulär ein Kerberos-Ticket (für Leser, die Kerberosisch sprechen: ein TGT) für den nominellen Zertifikatsinhaber, also den Domain Controller.
  5. Mit diesem Ticket hat der Angreifer die Rechte eines Domain Controllers in der Hand. Et voilà...

Eigentlich halb so schlimm, aber...

Damit der Angriff wie beispielhaft von Delpy vorgeführt funktioniert, müssen neben dem aktivierten Web-Enrollment (oder CES) noch weitere Voraussetzungen gegeben sein:

  • Das CA-Zertifikat der CA, bei der das Domain Controller zertifikat erschlichen wurde muss im "NTAuth" Container des Active Directory eingestellt sein. Eine Microsoft Enterprise CA macht das beim Setup ohne Rückfrage automatisch.
    Tatsächlich könnte man überlegen, ob man ein Issuing-CA Zertifikat nach der Installation explizit wieder aus dem NTAuth Container löscht, sofern man als PKI-Betreiber sicher ist, dass sich nie ein Zertifikatsinhaber mit seinem Zertifikat bei AD-integrierten Windows-Diensten anmelden wird. Dies betrifft nicht nur die Kerberos-Anmeldung, sondern bspw. auch den Network Policy Server (NPS), Microsofts Implementierung eines RADIUS-Servers. (Aber dann sollte man sich später nicht wundern, wenn z. B. Smartcard-Logon oder WPA2-Enterprise Anmeldung mit Zertifikat nicht spontan nach den gängigen Anleitungen funktioniert.)
  • Die "Domain Controller" Zertifikatsvorlage muss in der CA aktiviert sein. Alternativ könnte der Angreifer auch die neueren "Domain Controller Authentication" oder "Kerberos Authentication" Zertifikatvorlagen nutzen. Auch hier ist bei Microsoft Enterprise-CAs praktisch immer eine dieser Vorlagen aktiviert, alleine schon, damit das heimische AD auch per LDAPS (LDAP über TLS) angesprochen werden kann.
    Alle drei von Microsoft vordefinierten Templates sind Schema-Version 1 oder 2, so dass auch das seit Jahren nicht mehr aktualisierte Web-Enrollment damit zurecht kommt. Eine selbst erstellte, von "Kerberos Authentication" abgeleitete v3-Zertifikatvorlage könnte über Web-Enrollment nicht mehr angesprochen werden - wohl aber über den CES.

Und selbst wenn im Ausnahmefall eine dieser beiden Voraussetzungen nicht gegeben ist, kann man schwerlich die Hand dafür ins Feuer legen, dass clevere Angreifer nicht doch einen Weg finden, diese Voraussetzungen zu schaffen oder zu umgehen. Daher müssen wir davon ausgehen, dass wir ein Problem haben könnten.

Was tun, sprach Zeus...

Microsoft hat inzwischen auf die PetitPotam-Anfälligkeit der AD Certificate Services reagiert und den Knowledge Base Artikel KB5005413 veröffentlicht. Die darin bevorzugt empfohlene Gegenmaßnahmen, nämlich das Deaktivieren der NTLM Authentifikation auf den Windows Domain Controllern (Hallo Microsoft, wieso habt Ihr das nicht schon längst in der Standardinstallation als Vorgabe getan?) oder vielleicht gleich im ganzen AD (um spontan aufkeimende Bedenken zu zerstreuen: einzelne Ausnahmen für Legacy-Systeme oder -Anwendungen sind möglich), sind sicherlich die sauberste Lösung gegen diesen und ähnliche Angriffe. Aber leider übersteigen sie oft den direkten Zuständigkeitsbereich von PKI-Verantwortlichen.

Im Hinblick auf die betroffenen CA-Server einer Microsoft ADCS-basierten PKI empfehle ich daher folgendes:

  • Falls in einer Microsoft-basierten PKI auf allen CAs (insbesondere AD-integrierten Enterprise-CAs, aber wir wollen Root-CAs auf stand-alone Windows Servern ja nicht vergessen) weder das Certificate Authority Web Enrollment (bei deutsch lokalisiertem Server 2016/2019: "Zertifizierungsstellen-Webregistrierung") noch der Certifcate Web Enrollment Service ("Zertifikatsregistrierungs-Webdienst") als Rollenfeature installiert sind, ist keine weitere Aktion erforderlich.
    Ob dies auf einem CA-Server der Fall ist, kann man z. B. über folgenden Befehl in einer lokalen PowerShell (auch ohne Administrator-Rechte) nachprüfen:
    Get-WindowsFeature -Name ('ADCS-Web-Enrollment', 'ADCS-Enroll-Web-Svc')
    Bei einem "[X]" in der Ausgabe ist das betreffende Feature installiert, bei "[ ]" nicht.

  • Falls in der PKI das Web Enrollment und/oder der Certifcate Web Enrollment Service als Rollenfeature installiert sind, aber nicht (oder nicht mehr) genutzt werden, kann man das oder die betreffenden Rollenfeatures entfernen.
    Das Entfernen geht z. B. über den Server-Manager, aber alternativ natürlich auch per lokaler PowerShell (in diesem Fall mit Administrator-Rechten):
    Remove-WindowsFeature -Name 'ASCS-Web-Enrollment'
    Remove-WindowsFeature -Name 'ADCS-Enroll-Web-Svc'
    Beim Entfernen des Web Enrollment Features ist noch zu beachten, dass möglicherweise in der betreffenden PKI der IIS einer CA zugleich als (interner) HTTP CRL-Verteilungspunkt fungiert . Typischerweise hat dann eine der in der CRL-DistributionPoint (CDP) Erweiterung aufgeführten URLs ungefähr die Form "http://<CA-Servername_oder_Alias>/CertEnroll/<CRL-Dateiname>.crl".
    In diesem Fall muss nach dem Entfernen des Web Enrollment das lokale Verzeichnis, in dem CRLs und Zertifikate als Dateien abgelegt werden (üblicherweise C:\Windows\System32\CertSrv\CertEnroll), im IIS Manager wieder als virtuelles Verzeichnis mit dem korrekten Pfad-Alias (wie in der CDP-URL angegeben, auf aktuellen Windows-Server Versionen per Default "CertEnroll") der Default Web Site hinzugefügt werden.
    Natürlich (hatte ich schon erwähnt, dass ich PowerShell-Fanboy bin?) geht auch das alternativ per PowerShell (mit Administrator-Rechten):
    New-WebVirtualDirectory -Site 'Default Web Site' -Name 'CertEnroll' -PhysicalPath 'C:\Windows\System32\CertSrv\CertEnroll'
  • Falls eines oder mehrere dieser Rollenfeatures benötigt werden, sollte man -sofern noch nicht geschehen- wie in KB5005413 im ersten Aufzählungspunkt unter den Überschriften "Mitigation/Other Mitigations" beschrieben über die lokale Group Policy des CA-Servers die NTLM Authentifikation auf diesem Server deaktivieren.
    (Ja, das ginge auch per PowerShell, bräuchte aber Zusatzmodule, daher belassen wir es hier beim Klicken.)

Anfang Mai 2019 bekamen Firefox-Anwender weltweit (in ihrer jeweils eingestellten Sprache) die folgende Warnmeldung zu sehen:

Dazu kam es weil Firefox nur solche Add-ons ausführt, die vor der Bereitstellung von ihren Erstellern mit einer Code-Signatur versehen wurden. Nun war am 04.05.2019 das Zertifikat einer Intermediate-CA im Zertifikatspfad der Code-Signing-Zertifikate für Add-on Entwickler abgelaufen und die Code-Signaturen wurden nicht mehr als gültig validiert - ergo wie vorgesehen die betreffenden (d. h. hier: alle) Add-ons nicht mehr geladen.

Der eine Fehler, den man den Entwickern bei Mozilla ankreiden kann, ist es, als Stichpunkt für die Validierung den Zeitpunkt anzusetzen, an dem das betreffende Add-on geladen werden soll, mithin den Startzeitpunkt des Browsers. Jedes Signaturzertifikat wird irgendwann einmal ablaufen. Häufig will man aber auch danach noch das betreffende Dokument, den Code oder was immer sonst signiert wurde, validieren. Daher ist in aller Regel der sinnvolle Stichpunkt, zu dem eine Signatur und das verwendete Signaturzertifikat validiert werden müssen, der Zeitpunkt, zu dem die Signatur angebracht wurde (also die Gretchenfrage: War das Signaturzertifikat zu diesem rückdatierten Stichpunkt bereits abgelaufen oder nicht?). Microsofts Authenticode Code-Signaturverfahren nutzt dazu Timestamps. Auch wer selbst keinen Timestamp-Server betreibt kann das Verfahren einfach nutzen, da bis heute viele kommerzielle Trustcenter sehr freizügig und kostenlos Timestamps erstellen, durch die man gerade angebrachte Signaturen mit den (nicht nur) bei ihnen gekauften Code-Signatur-Zertifikaten dauerhaft machen kann.

Die weitaus größere Blamage ist es, dass das Intermediate-CA Zertifikat überhaupt ohne eine rechtzeitige vorherige Erneuerung ablaufen konnte. Zumal den Mozilla-Leuten das gleiche Malheur bereits drei Jahre zuvor unterlaufen war.


Zum Hintergrund, weswegen abglaufene CA-Zertifikate und besonders CRLs immer wieder vorkommen, muss ich etwas weiter ausholen. Root- und Intermediate-CAs, die nicht wie Issuings-CAs zum Erstellen von Nutzer- oder Geräte-Zertifikaten im Tagesgeschäft permanent erreichbar sein müssen, werden aus guten (Sicherheits-)Gründen in der Regel komplett offline betrieben.

Als Beispiel für die Risiken einer Online-CA sei auf das Debakel des niederländischen Trustcenters DigiNotar im Jahre 2011 hingewiesen. Dort waren Angreifer vom Internet aus über ein internes Management-Netzwerk bis zum aktivierten Hardware-Security-Modul (HSM) einer CA vorgedrungen. Und ein einmal aktiviertes HSM ist im wesentlichen ein Frankierautomat, der brav alles abstempelt, was man ihm vorlegt. In diesem Fall stempelte es handgefertigte Zertifikatsrümpfe der Angreifer zu öffentlich gültigen Zertifikaten. (Mein Allzeit-Favorit ist übrigens das Wildcard-Zertifikat für *.*.com .)

Der Pferdefuß von „komplett offline und nur physisch erreichbar“ ist nun aber leider „nur physisch erreichbar per manuellem Zugriff der Bediener“. Das heißt, der Mensch und seine Zeitplanung sind ein unabdingbares Element des Erneuerungsprozesses. Übliches Vorgehen sind Wiedervorlage-Termine im Kalender und einige Wochen Karenzzeit vor dem endgültigen Ablauf, für den Fall, dass beim eigentlich vorgesehenen Termin etwas dazwischen kommt. Manchmal kommt dann eben bis nach dem Ende der Karenzzeit etwas dazwischen...


Ist das Mozilla-Malheur nun - getreu dem Motto „Wenn selbst denen das passiert ...“ eine Absolution für uns alle, denen schon einmal unbemerkt ein Server- oder CA-Zertifikat oder eine CRL abgelaufen ist? Oder eher ein Ansporn, einfach besser aufzupassen als „die“?

Meiner Meinung nach weder noch. Die richtige Konsequenz aus derlei Fällen ist einerseits, die Erneuerung von Zertifikaten und CRL zu automatisieren, wo immer das möglich ist, sprich: bei online betriebenen Issuing-CAs. Andererseits sollte man den Gültigkeitsstatus von Zertifikaten und CRLs aktiv überwachen und dabei bereits beim Beginn einer Karenzfrist, die noch Zeit zur Reaktion lässt, zu alarmieren. Damit können dann auch die wohlweislich manuellen Erneuerngsprozesse bei einer offline betriebenen CA nicht so leicht im anderen Tagesgeschäft des Bedienpersonals untergehen.

Also Automatisierung und Alarmierung anstatt Absolution.
(Ja, eigentlich: Monitoring und Alerting, aber das würde mir die Alliteration kaputt machen.)

... wo sind sie geblieben?

Wenn man den Zertifikatsspeicher eines neu installierten Windows-Rechners anschaut, dann wird man feststellen, dass nur noch ein gutes Dutzend Root-CA-Zertifikate (microsoftisch-deutsch: "vertrauenswürdige Stammzertifikate") enthalten sind.
Das geht übrigens seit Windows 8 sehr schnell über den folgenden Kommandozeilen-Aufruf:

certlm.msc

Und das, obwohl Stand heute Hunderte öffentlicher Trustcenter mit ca. 391 Root-Zertifikaten am Microsoft Trusted Root Certificate Programm teilnehmen.

Der Nebel lichtet sich ein wenig, wenn man den Rechner eine Weile in Betrieb hat und feststellt, dass nach dem Besuch von Webseiten, Installation von signierten Programmen usw. unvermutet weitere Root-CAs im Store auftauchen.

Es gibt also einen in Windows eingebauten Nachlade-Mechanismus für Root-Zertifikate. Warum Microsoft nicht gleich alle Root-Zertifikate installiert, darüber kann man trefflich spekulieren. Neben der überschaubareren Optik, die dem Betrachter ein besseres Gefühl suggeriert, wem er da eigentlich alles vertraut, könnte es daran liegen, dass einige Komponenten des Betriebssystems vielleicht mit soooo vielen Root-Zertifikaten gar nicht zurecht kommen.

Der Nachlade-Mechanismus funktioniert grob wie folgt:

  • Wenn ein Zertifikat (bspw. das Serverzertifikat einer Webseite) validiert wird, versucht Windows, eine Zertifikatskette bis zu einer vertrauenswürdigen Root zu finden.
  • Falls die Zertifikatskette bis zu einem der installierten Root-Zertifikate geschlossen werden kann, dann wird sie nach Gültigkeit und Sperrstatus validiert.
  • Falls nicht, dann wird geprüft, ob der Hashwert des Issuer-Namens im letzten Zertifikat, zu dem kein vertrauenswürdiger Aussteller mehr im lokalen Store gefunden werden kann, in einer Liste hinterlegter Hashwerte von Issuern aus dem Root Certificate Program auftaucht.
  • Wenn ja, dann wird das betreffende Root-Zertifikat von einem Server aus dem Window Update System nachgeladen. (Notabene: Obwohl Windows Update Server mit verwendet werden, ist der Mechanismus selbst davon unabhängig, ob Windows Update aktiviert ist oder nicht.)

Aus Sicherheitssicht ist dieses Nachladen von Root-Zertifikaten wenig bedenklich, weil alle Trustcenter, deren Root-CAs am Programm teilnehmen gleichermaßen streng geprüft wurden. Allenfalls einem unbedarften Anwender, der unter diesen Trustcentern eine eigene Auswahl treffen will, spuckt Microsoft damit in die Suppe.

Es gibt jedoch einen (seltenen) Fall, in dem dieser Mechanismus versagt: Wenn in einem Firmen-Netzwerk - oder künftig vielleicht verstärkt in einem Industrie-4.0 OT-Netzwerk?! - die Firewall so dicht ist, dass sie den Windows-Clients jegliche Kommunikation mit Servern im Internet verwehrt.
Damit die Administratoren solcher Systeme einen eigenen, internen Download-Server für die Root-Zertifikate aufsetzen können, dessen Adresse sie dann - wie sollte es anders sein - per Group Policy intern verteilen, gibt es einen Weg, um alle Root-Zertifikate von Windows Update manuell herunterzuladen.
Das kommt natürlich auch all denen entgegen, die ähnlich neugierig sind wie ich:

certutil -syncWithWU <Directory>

In dem angegebenen Directory finden sich nach erfolgreichem Abschluss des Kommandos nicht nur alle für Microsoft Windows gültigen Root-Zertifikate, sondern auch eine Certificate-Store-Datei mit all jenen Zertifikaten, denen Windows auf gar keinen Fall vertraut. Aber das ist wahrscheinlich ein Thema für einen anderen Blogbeitrag...