Springe zum Inhalt

Autor: hajo

Veröffentlicht am Hinterlasse einen Kommentar zu BOM-biger Crash der Certificate Services

Da ich noch keine Fundstelle zu den folgenden Fehlercodes im Web finden konnte, will ich das hiermit nachholen und das damit verbundene Problem kurz darstellen.

Symptom

Beim versuchten Start der AD Certificate Services stürzt der Dienst gleich wieder ab. Dabei erscheint die Fehlermeldung

The process terminated unexpectedly. 0x42b (WIN32: 1067 ERROR_PROCESS_ABORTED)

Im Application Event-Log findet sich dazu keine Meldung unter der Quelle CertificationAuthority, dafür aber zwei Einträge unter der Quelle Application Error mit der Event-ID 1000 und dem Exception Code 0xc0000005 bzw. 0xc000041d.

Die Ursache

Die Active Directory Certificate Services reagieren sehr empfindlich auf unbekannte oder doppelte Einträge im Multi-String Registry-Wert

HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\<CA-Name>\SubjectTemplate

Dort wird vorgegeben, welche Namens-Elemente (Relative Distinguished Names, RDN) in welcher Reihenfolge im Subject-Namen von ausgestellten Zertifikaten vorkommen dürfen.

Eigentlich sollte bei fehlerhaften Einträgen im SubjectTemplate die CertificationAuthority einen aussagekräftigen Fehler mit Event-ID 19 ins Event-Log schreiben und sich kontrollliert beenden. In der Praxis stürzt certsrv.exe aber ab, wenn dort ein unbekannter oder doppelter Eintrag enthalten ist.

Wer das testen will, kann mit

certutil -setreg ca\subjecttemplate +foobar

dafür sorgen, dass seine CA beim nächsten Start mit den oben beschriebenen Meldungen abstürzt.

Die Lösung ist, mit RegEdit oder certutil -setreg den fehlerhaften oder doppelten Eintrag zu bereinigen bzw. zu entfernen. Dann startet die CA wieder wie gewohnt.

Wie kann es dazu kommen?

In zwei Szenarien habe ich es in der Praxis erlebt, dass dieser Fall unbeabsichtigt auftritt.

Das erste ist die Installation eines Network Device Enrollment Service (NDES) mit dem Microsoft-Installationsassistenten. Dabei werden der SubjectTemplate der CA, die den NDES bedient, die drei Werte DeviceSerialNumber, UnstructuredName und UnstructuredAddress hinzugefügt. Ganz gleich, ob diese bereits vorhanden sind oder nicht. Wer also einen dieser Werte schon vor der NDES-Installation im SubjectTemplate stehen hat, kommt wegen des doppelten Eintrags in den Genuss des Problems.

Das zweite Szenario ist gar nicht so leicht zu erkennen. Wenn man per Copy&Paste in RegEdit einen oder mehrere RDN-Namen zur SubjectTemplate hinzufügt, sollte man darauf achten, aus welcher Quelle sie kopiert werden. Ist die Copy-Vorlage beispielsweise ein Microsoft-Teams-Chat, kann es passieren, dass am Anfang der Zeile ein unsichtbares UTF8-Zeichen, die Byte Order Mark (BOM - das erklärt den Titel dieses kleinen Blogbeitrags) mitkopiert wird. Dieses zusätzliche Zeichen sorgt dann dafür, dass der Eintrag nicht als korrekt erkannt wird und zum Absturz führt, ist aber in der RegEdit-Ansicht nicht zu sehen.

Veröffentlicht am Hinterlasse einen Kommentar zu ESC12 – Shell access to ADCS CA with YubiHSM

Since I assume that the following information is also of interest to non-German-speaking readers, I am writing this post in English as an exception.

Preface

This post is in no way meant to discourage the use of the Yubico YubiHSM2 for CA keys of AD Certificate Services CAs. On the contrary, I recommend using a YubiHSM2 over storing the CA private key in software (i. e. using the Microsoft Software Key Storage Provider) in almost all usage scenarios.

It is merely intended as a warning not to forget hardening of the CA server, in particular limiting network and console access to authorized users, just because the key is stored in a hardware security module.

ESC1 to ESC11

Various privilege escalation (vulgo attack) methods to obtain certificates that can be abused to obtain Kerberos tickets for high-privileged user or computer accounts (a.k.a. Golden Certificates) have been published before. In their important whitepaper "Certified Pre-Owned" the SpecterOps team numbered several potential ways by which attackers can obtain Golden Certificates from ESC1 to ESC8. Later-on Oliver Lyak described ESC9 and ESC10 and Sylvain Heiniger of Compass Security added ESC11.

In this tradition, I take the liberty of naming the following attack vector ESC12.

Peculiarities of the YubiHSM Key Storage Provider

Yubico's YubiHSM2 is arguably the most affordable FIPS-140 certified hardware security module and as such a good alterative to storing CA keys in software. It is a USB device in the same form factor as the smallest of the popular YubiKeys. It is either directly connected to a USB port of the CA server or (most often if the CA server is a virtual machine) via a USB device server (a.k.a. "dongle server") and corresponding client software that pretends it to be a locally connected USB device.

The way to access a YubiHSM2 from the AD Certificate Services as well as from other Windows CNG compatible applications is to use the YubiHSM Key Storage Provider.

In order to generate and use keys in the YubiHSM, the Key Storage Provider must use an authentication key (sometimes dubbed "password"). This key/password is stored in the registry under

HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword

in cleartext (!).

Furthermore, the YubiHSM Key Storage Provider does not check under which user account processes calling it via CNG are running.

Abusing shell access to the CA server

It is always a good idea to limit access to a Windows server running a CA instance to PKI administrators and comparable administrators.
[With "comparable" I mean in particular AD domain admins who might place themselves in the security group of PKI administrators or reset a PKI administrator's password for impersonation and enterprise admins who might modify certificate templates in the AD Global Catalog to be vulnerable to ESC1 ff. attacks.]

For CAs using a YubiHSM this kind of hardening of system access is essential.

An attacker who can access the CA server as a regular non-privileged user can use two ways to access the CA's private key in the HSM.

Redirect USB device server

If the YubiHSM is connected to the CA server via a USB device server and the attacker has sufficient administrative access to this USB device server, he might abuse that to connect the YubiHSM to a machine under his control.

With local or network (or, heaven forbid, remote registry) access to the CA server, he can read the cleartext AuthKeysetPassword and configure this key/password in the registry of his own server to access the CA key. Note that restricting read access to HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword might prevent this.

The drawback of this way of attack is that - for most of the USB device servers that I know - either the USB HSM cannot be connected to another system as long as it is connected to the CA server or that the connection to the regular CA server is lost. In the latter case, the CA will stop working (i.e. fail to issue new certificates or CRLs), which should hopefully be detectable by some form of service monitoring.

Forge your own certificate

Another way of abusing local or network CA server access that does not require abuse of a USB device server and should be harder to detect is to access the CA key directly on the CA server as non-privileged user.

Assume the attacker is logged into the CA server as a non-privileged user. Then he can obtain the CA certificate as a certificate file (easy, it is public at least throughout the whole AD) and import it in his user profile certificate store on the CA server as his own via

certutil -addstore -user my <CA certificate file>
Next he must associate the certificate with its private key in the YubiHSM2:
certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my <CA Common Name>
After that, the attacker can access the CA certificate and its private key as his own and bring the many options of
certutil -sign ...

to a creative use to forge his own certificate.

As an added bonus, this new forged certificate is not seen in the regular CA's database, its event log entries or the mails sent by the SMTP exit module. If the serial number of the base certificate modified using the "certutil -sign" command is set to an arbitrary new value, it cannot even be revoked by the CA - at least not until it is found in the wild and imported into the CA database.

What about other types of HSM?

Some other types of HSM (or more precisely: the associated Key Storage Provider, which is aware of its calling user account) are not susceptible to the latter type of attack.
However, since I am not familiar with all HSM brands on the market (let alone have access to test equipment), it seems not entirely unlikely to me that some HSM types are also susceptible to this.

Veröffentlicht am Hinterlasse einen Kommentar zu In 90 Tagen um die Welt…

... beziehungsweise wie bei Jules Verne in 80 Tagen, plus 10 Tage Karenzzeit.

Oberhaus und Unterhaus

Schon 2017 bei der Abstimmung im CA/Browser-Forum (oder wie ich gerne sage: "im Kartell"), als es darum ging, die maximale Gültigkeitsdauer öffentlich anerkannter TLS-Serverzertifikate von 39 Monaten (drei Jahre plus drei Monate Karenz) auf 398 Tage (ein Schaltjahr plus ein aufgerundeter Monat Karenz) herunter zu setzen, haben die Browser-Hersteller ("das Oberhaus") letztlich die Nein-Stimmen der Trust-Center-Betreiber ("das Unterhaus") nicht auf sich beruhen lassen, sondern über den Zwischenschritt von 825 Tagen (zwei Jahre plus gute drei Monate Karenz) die 398 Tage in ihren Browsern implementiert und im August 2020 unter dem Stichwort "Browser-Alignment" vom Kart... äh... CA/-Browser-Forum absegnen lassen.

Von Let's Encrypt lernen

Am 03.03.2023 ist das Chromium-Projekt von Google nun erneut vorgeprescht und schlägt eine weitere drastische Verringerung der Zertifikatsgültigkeiten vor (man könnte auch sagen "fordert", denn es wird mit der Keule gewunken, das einfach im Chrome-Root-Programm zu verankern, anstatt es über die Baseline-Requirements des CA/Browser-Forums einzustielen):

Root-CA-Zertifikate sollen nur noch maximal sieben Jahre genutzt werden (selbst wenn die Zertifikate nominell länger gültig sind) und CA-Zertifikate untergeordneter CAs nur noch drei Jahre gültig sein. Vor allem aber sollen öffentlich gültige TLS-Sever-Zertifikate nur noch maximal 90 Tage gültig sein, wie dies bei Let's Encrypt schon lange die Praxis ist.

Zusätzlich wird verlangt, dass PKI-Hierarchien unter öffentlich gültigen Root-CAs nur noch einen Typ von Endzertifikaten ausstellen - d. h. für den Browser: nur TLS-Server-Zertifikate und nicht bspw. Code-Signing-Zertifikate unter derselben Root-CA.

Warum nur, warum

Mit den Einschränkungen für die Nutzungszeit von CA-Zertifikaten will man erreichen dass ca. alle fünf Jahre die CAs auf den Stand der Technik gebracht werden. Und damit auch für den Fall vorbeugen, dass doch der ominöse Quanten-Computer gebaut werden kann, der den Shor-Algorithmus ausführen und 4096-Bit-RSA und mehr brechen kann, so dass "das Web" auf Post-Quanten-Kryptoalgorithmen wechseln muss. (Was letzteres betrifft stehen meine zwei Kasten Bier bei der Wette darauf, dass die Menschheit vorher wirtschaftlich nutzbare Kernfusions-Kraftwerke haben wird.)

Dagegen ist wenig einzuwenden: Über den Online-Update von Chrome kann Google regelmäßig neue Root-Zertifikate der teilnehmenden Trust-Center ausspielen. Und wer Browser ohne Online-Update im Internet nutzt, dem ist ohnehin nicht mehr recht zu helfen.

Interessanter ist die Funktionstrennung für die PKI-Hierarchien. Hier ist ein Ziel, dass bspw. eine kompromittierte Code-Signing-CA nicht zugleich das Fälschen von TLS-Serverzertifikaten erlaubt. Leider hätte auch das 2011/2012 nicht gegen die Comodo- und DigiNotar-Hacks  geholfen - dort haben die Angreifer einfach Zugang zu allen CAs des betreffenden Betreibers bekommen. Wenn ein Einbrecher einmal die Mauer von der Straße aufs Grundstück überklommen hat, ist es über den Jägerzaun zum Nachbargarten meist nur ein Katzensprung.
Allenfalls können damit unerwünschte und unbemerkte Quer-Wirkungen zwischen gänzlich unterschiedlichen Registrierungsprozessen innerhalb einer CA vermieden werden.

Noch mehr von Let's Encrypt lernen

Und die Verringerung der Laufzeit von Serverzertifikaten auf die (für diesen Blogbeitrag) namensgebenden 90 Tage schließlich soll zwei Ziele befördern.

Einerseits sollen die Server-Betreiber mit mehr oder weniger sanftem Druck dazu gedrängt werden, anstatt der herkömmlichen, "barocken, zeitaufwändigen und fehleranfälligen" manuellen Zertifikatsbeantragung automatisierte Protokolle, namentlich das von Let's Encrypt eingeführte ACME zu verwenden.

Dem Ansatz folge ich seit längerer Zeit auch. Das hauptsächliche verbleibende Problem bei ACME ist, dass es für Plattformen abseits der etablierten Betriebssysteme und Webserver, d. h. für Systeme wie Hypervisor, Appliances, Lights-Out-Schnittstellen usw., oft keine verfügbaren ACME-Clients gibt. Da derartige Systeme aber (aus Gründen 😉 ) selten über Internet erreichbar sind, ist dieser Nachteil für öffentlich gültige Zertifikate weniger relevant. ACME ist der Weg.

Allein als kommerzieller Trust-Center-Betreiber müsste man sich die Frage stellen, warum die Kunden dann weiterhin TLS-Serverzertifikate kaufen wollen, anstatt sie kostenlos von Let's Encrypt & Co. zu beziehen.

Der andere Grund für 90 Tage Gültigkeit ist das mangelnde Vertrauen in die etablierten Sperrmechanismen und die Hoffnung, dass sperrens-würdige Zertifikate dann zumindest schnell ablaufen.

Diesen Punkt sehe ich nicht ganz so gewichtig. Zum einen gibt es mit OCSP-Stapling seit Jahren einen probaten Sperr-/Prüfmechanismus, den die Browser-Hersteller implementieren und promoten können. Zum anderen muss man sich fragen, wie viele der System-Administratoren, die keine Zeit dafür haben, einen Sperrantrag für das Zertifikat ihres nicht mehr benötigten und/oder möglicherweise kompromittierten Servers zu stellen, stattdessen die Zeit finden, den Automatismus, der alle 80 Tage ein neues Zertifikat holt, zu unterbrechen.

1

Veröffentlicht am 1 Kommentar zu Nilpferde, NDES und goldene Zertifikate als Schlüssel zum AD

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.

Veröffentlicht am Hinterlasse einen Kommentar zu Kleines Nilpferd trampelt über Microsofts PKI-Webdienste

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

Veröffentlicht am Hinterlasse einen Kommentar zu Das Kartell

Im einen oder anderen kommenden Blog-Beitrag werde ich nicht umhin kommen, das CA/Browser-Forum zu erwähnen. Daher sollte ich wohl zunächst ein paar Worte darüber sagen.

In den Urzeiten des World Wide Web, als HTTPS noch eine neue Technologie war, wurde es von den Browsern (die damals Netscape Navigator oder Internet Explorer 3 hießen) recht hemdsärmelig gehandhabt, wessen Serverzertifikate dabei akzeptiert wurden. Erst gab es nur das eine öffentliche Trustcenter, dessen Root-Zertifikat mit ausgeliefert wurde. Dann war man froh, dass sich ein Mitbewerber fand, um keinen Ärger mit den Anti-Kartell-Behörden zu riskieren. Im Detail festgelegte und auditierte Voraussetzungen, um mitspielen und an Zertifikaten mitverdienen zu können, gab es nicht wirklich.

Das änderte sich im Laufe der Zeit, als immer mehr Aspiranten sich meldeten, und so fand sich 2005 das CA/Browser-Forum (oder kurz: CABForum) zusammen. Wer mich schon einmal zu diesem Themenbereich referieren gehört hat, weiß, dass ich meist einfach "das Kartell" sage - ein informeller Zusammenschluss (laut Satzung "voluntary gathering") marktbeherrschender Unternehmen mit dem Zweck, Spielregeln für diesen Markt festzulegen und durchzusetzen.

Mitglieder sind auf der einen Seite die führenden und einige noch nicht oder nicht mehr so führenden Betriebssystem- und Browser-Hersteller: Apple (macOS, iOS, Safari), Google (Android, Chrome), Microsoft (Windows, Internet Explorer, Edge), Mozilla Foundation (Firefox), Opera und ein chinesischer Browser-Hersteller. Auf der anderen Seite sind ca. 70 bis 80 öffentliche Trustcenter dort vertreten, deren Zusammensetzung gelegentlich aufgrund von Marktbewegungen etwas variiert.

Interessanterweise stimmen diese beiden Teilnehmergruppen bei den allfälligen Änderungen der Spielregeln (insbesondere der Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates) getrennt ab. Aus aktuellem politischen Anlass könnte man das ein Bisschen mit den Rollen des Europäischen Rats und des Europaparlaments vergleichen - nur das beim Kartell wohl noch deutlicher ist, wer im Endeffekt das Sagen hat.

Und ehe das jetzt so klingt, als wäre ich ein ausgemachter Kritiker des CA/Browser-Forums: Wir haben dem Kartell einige wirklich gute Dinge zu verdanken, z. B. den Umstieg von SHA-1 auf SHA-2 als Hashalgorithmus, Certificate Transparency und generell ein strengeres Regime der Aufsicht über die öffentlichen Trustcenter.

Veröffentlicht am Hinterlasse einen Kommentar zu Rechtzeitig, frühzeitig, vorzeitig

Nachdem ich im vorigen Beitrag mehmals das Wort „Karenz“ benutzt habe, möchte ich noch eine Bemerkung hinterherschicken:

Zertifikate, die vor dem Ablauf stehen (und tun sie das nicht alle?), aber weiterhin benötigt werden, müssen rechtzeitig erneuert werden, um Betriebsstörungen zu vermeiden. Häufig –sicherlich auch motiviert durch das klassische Gebührenmodell öffentlicher Trustcenter, bei dem jedes TLS-Serverzertifikat einzeln berechnet wurde– wird „rechtzeitig“ interpretiert als „so kurz wie vertretbar von dem Ablauftermin“.

Zuverlässiger ist es allerdings, so frühzeitig zu erneuern, dass ein umbeabsichtigter Ablauf mit hoher Sicherheit vermieden wird. Also längere Karenzzeiten einplanen, die man vielleicht eher in Monaten zählt als in Wochen. Zumal die Serverzertifikate einer internen PKI in der Regel gar nicht separat berechnet werden und auch viele kommerzielle Trustcenter inzwischen einen Zeitraum für die Versorgung mit Zertifikaten und nicht ein einzelnes Zertifikat als Abrechnungsgrundlage anbieten.

Und letztlich verbieten weder PKI-Standards noch Best-Practice-Anforderungen, Zertifikate lange vor ihrem Ablauftermin - man könnte also sagen vorzeitig - zu erneuern. Wer in puncto Verfügbarkeit auf der sicheren Seite bleiben will, sollte das Zertifikat seines Servers während des jährlichen geplanten Wartungsfensters erneuern, selbst wenn das vorhandene Serverzertifikat noch über ein Jahr gültig wäre.
Natürlich sollte man das nicht länger benötigte, vorherige Zertifikat anschließend sperren. Genau für diesen Fall sieht X.509 seit über 20 Jahren den Sperrgrund superseded vor.

Merke: PKI ist eines der wenigen(?) Themen, bei denen die Vokabel „vorzeitig“ positiv besetzt sein sollte.

Veröffentlicht am Hinterlasse einen Kommentar zu Absolution oder Ansporn?

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

Veröffentlicht am Hinterlasse einen Kommentar zu Sag mir wo die Wurzeln sind, …

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

Veröffentlicht am Hinterlasse einen Kommentar zu Wie schreibt man eigentlich „Public Key Infrastruktur“?

Diese Frage ist ja nicht so ganz unwichtig für ein Blog, das sich diesem Thema widmen will.

Laut Duden Regel 42 (welche Nummer auch sonst??) werden Aneinanderreihungen und Zusammensetzungen mit Wortgruppen aus Fremdwörtern mit Bindestrich geschrieben. Korrekt hieße es also "Public-Key-Infrastruktur".
Das sieht aber je nach Auge des Betrachters nicht nur ungewohnt bis hässlich aus, diese Schreibweise hat sich auch so im deutschen Sprachraum
nie wirklich eingebürgert.

Also will ich es in diesem kleinen Blog so halten, wie es auch das Bundesamt für Sicherheit in der Informationstechnik höchstoffiziell unter dem Bundesadler und dem schwarz-rot-goldenen Säulenelement tut und die übliche getrennte Schreibweise "Public Key Infrastruktur" verwenden.