Nachdem wir uns letzten Monat mit der Optimierung des Patch Managements beschäftigt haben, geht es diesen Monat um das Thema Credential Guard. Da es schon zahlreiche Artikel (Link, Link, Link) zu der Technik als solcher gibt, möchten wir den Fokus auf die Einführung der Technologie in einer bestehenden Infrastruktur setzen.

Wenn man die Dokumentation von Microsoft liest, erkennt man, dass man einfach nur eine Group Policy konfigurieren muss und fertig ist das Rollout. Wieso also dieser Blogpost? Die Begründung liegt in der Art und Weise, wie Credential Guard funktioniert und den Implikationen, die sich daraus ergeben.

Hintergrund

Der ursprüngliche Gedanke im Design von Windows (und bei vielen auch weitaus älteren Betriebssystemen) ist eine Separierung zwischen einem Kernel- und Benutzermodus. Der Windows-Kernel läuft in einem privilegierten Prozessormodus mit vollem Zugriff auf Systemdaten und Hardware, während andere Teile von Windows und alle Applikationen im Benutzermodus mit eingeschränktem Zugriff auf Systemdaten und keinem direkten Zugriff auf Hardware laufen. Innerhalb des Kernel-Modus werden jedoch auch die meisten Gerätetreiber ausgeführt und viele davon stammen von Drittfirmen. Microsoft gibt an, dass in den Telemetriedaten eine Million von eindeutigen Hashes von Treibern zu sehen sind – und das jeden Monat! Credential Guard nutzt „Virtualization Based Security“, um eine eigene geschützte Umgebung mit einem separaten Kernel bereitzustellen, in dem die Anmeldeinformationen gespeichert werden. Um diese Virtualisierung zu ermöglichen, sind einige Voraussetzungen zu erfüllen:

• • Support for Virtualization-based security (required)
  • Secure boot (required)
  • Trusted Platform Module (TPM, preferred – provides binding to hardware) versions 1.2 and 2.0 are supported, either discrete or firmware
  • UEFI lock (preferred – prevents attacker from disabling with a simple registry key change)

 

Die „virtualization-based security“ benötigt:

• • 64-bit CPU
  • CPU virtualization extensions plus extended page tables
  • Windows hypervisor (does not require Hyper-V Windows Feature to be installed)

 

Credential Guard wird auch in VMs unterstützt, dafür sind folgende Voraussetzungen notwendig:

• • The Hyper-V host must have an IOMMU, and run at least Windows Server 2016 or Windows 10 version 1607.
  • The Hyper-V virtual machine must be Generation 2, have an enabled virtual TPM, and be running at least Windows Server 2016 or Windows 10.
  • TPM is not a requirement, but we recommend that you implement TPM.

 

Klingt im Jahr 2021 erstmal nach nichts Besonderem, aber wie verhält sich das in der Praxis?

Hardware

Der Anforderungsliste können wir entnehmen, dass zwei Dinge notwendig sind:

• • Ein 64 Bit Prozessor, welcher virtualization extensions und extended page tables ausführen kann.
  • Ein TPM (min. 1.2) Chip oder ein Prozessor, der das TPM in der Firmware realisiert.

Die virtualization extensions wurden etwa 2006, die extended page tables etwa 2009 eingeführt. Die TPM 1.2 Spezifikation wurde 2011 veröffentlicht. In der Regel unterstützt also die Hardware, die sich im aktuellen Lifecycle befindet, Credential Guard.

Ausnahmen bestätigen leider die Regel. Gerade kürzlich haben wir einen produktiven Windows 3.11 PC bei einem Assessment gefunden. Der läuft sicher nicht auf einer kompatiblen Hardware. Auch kann es sein, dass Client Hardware aus den Consumer Produktlinien im Einsatz ist und deshalb nicht alle benötigten Voraussetzungen erfüllt.

Die gute Nachricht ist: wird Credential Guard per GPO auf einem System aktiviert, welches die Voraussetzungen nicht erfüllt, passiert nichts, außer dass Credential Guard nicht ausgeführt wird. Die schlechte Nachricht: Credential Guard wird nicht ausgeführt. Man wähnt sich womöglich in Sicherheit, ist jedoch nicht geschützt.

BIOS Einstellungen

Es reicht nicht, dass die Hardware die notwendigen Features unterstützt, diese müssen im BIOS auch aktiviert werden. Leider nennt jeder Hersteller die Funktionen ein wenig anders, weshalb wir hier auf die konkrete Nennung der Einstellungen verzichten.

Aktuelle Hardware wird oft schon so ausgeliefert, dass Credential Guard direkt genutzt werden kann. Vor ein paar Jahren war das aber nicht der Fall. Das Problem klingt auf den ersten Blick kleiner als es ist. Zur Veranschaulichung ein reales Szenario:

Ein europaweit tätiges Unternehmen mit ca. 20.000 Clients. Es sind etwa 20 verschiedene Notebook und Desktop Modelle von einem Hersteller im Umlauf. Die Betankungsinfrastruktur wird zentral bereitgestellt, die Geräte werden jedoch regional provisioniert.

Zunächst stellt sich die Frage, ob alle Clients die notwendigen BIOS-Einstellungen gesetzt haben. Schließlich hat vor (bis zu) 3 oder 5 Jahren noch niemand an das Thema Credential Guard gedacht. Glücklicherweise lassen sich die BIOS Einstellungen mittels SCCM zentral auslesen. Ergebnis: Die BIOS Einstellungen sind nicht einheitlich, mehrere Tausend Clients haben nicht die notwendigen Einstellungen aktiviert ☹️.

Wie kann man das Problem lösen? Nun, die meisten Hardwarehersteller bieten Tools an, um zentralisiert BIOS-Einstellungen zu konfigurieren. Der Haken an der Sache ist, dass man dafür das BIOS-Passwort benötigt. Sicherlich kein Problem, die Firma hat ja einen standardisierten Deployment Prozess…

Im Testlabor haben wir festgestellt, dass bei manchen Modellen nur Großschreibung verwendet werden kann. Bei einem Modell konnte man kein @ eingeben. Blöderweise enthält das Standardpasswort sowohl Kleinbuchstaben als auch das @-Zeichen. Schade.

Schlussendlich war ein koordinierter Aufwand mit den regionalen Supportkräften notwendig, um überall die korrekten BIOS Einstellungen zu konfigurieren.

Readiness Tool

Um die bisher beschriebenen Anforderungen zu überprüfen, stellt Microsoft das sogenannte „Windows Defender Device Guard and Windows Defender Credential Guard hardware readiness tool“ zur Verfügung. Bei dem „Tool“ handelt es sich allerdings „nur“ um ein Powershell Skript.

Leider muss das Tool mit Adminrechten ausgeführt werden und benötigt einen Reboot. Das Ergebnis wird dann in einer Textdatei abgespeichert. Es eignet sich daher aus unserer Sicht nur bedingt dafür, die Prüfung großflächig und automatisiert durchzuführen.

Virtualisierung

„Windows hypervisor (does not require Hyper-V Windows Feature to be installed)“.
Jedes Betriebssystem, welches Credential Guard unterstützt, bringt Hyper-V ja mit, kein Problem also.

Wirklich?

Fast. Hyper-V wird zwar immer mitgeliefert, aber was passiert, wenn man andere Virtualisierungslösungen verwenden will, z.B. VMWare Server oder Desktop oder VirtualBox? Mehrere Jahre lang war die gemeinsame Nutzung von Credential Guard und anderen Virtualisierungstechnologien nicht möglich (Windows 10 wurde im Juli 2015 veröffentlicht).

Für VMWare Server ist das seit Erscheinen von vSphere 6.7 möglich (April 2018).

VMWare Desktop unterstützt es erst ab Version 15.5.6 in Verbindung mit Windows 10 20H1 build 19041.264 (Juni 2020).

VirtualBox unterstützt es experimentell seit Version 6.0 (Dezember 2018), auch in der aktuellen Version 6.1 ist das Feature noch experimentell.

Rollout

Bei all den Themen, die hier zusammenwirken, ist es ratsam, das Rollout in Wellen zu gestalten, vor allem, weil wir durchaus auch schon einen Bluescreen bei einer unserer Testmaschinen hatten. Anschließend war es notwendig, den Bitlocker Recovery Key einzugeben. Wäre doch blöd, wenn das beim CIO passiert…

Wir haben nun alles akribisch vorbereitet, Hardware, BIOS und 3rd Party Software getestet und ggf. aktualisiert, endlich verlinken wir die GPO an der ersten OU. Doch wie wissen wir, ob wir alles richtig gemacht haben und Credential Guard auch tatsächlich unsere Anmeldeinformationen schützt?

Out of the Box, gar nicht.

Um diesen Missstand zu beheben, haben wir ein kleines Skript geschrieben, welches die notwendigen Informationen einsammelt und in eine ZIP Datei speichert. Die Vorgehensweise ist natürlich nur für die Pilotphase gedacht. Beim eigentlichen Rollout müssen die Informationen über das jeweilige Systems Management Tool vollautomatisiert eingesammelt werden.

Microsofts Endpoint Configuration Manager bietet beispielsweise die Möglichkeit, von den verwalteten Clients umfangreiche Inventurinformationen einzusammeln. Dabei kann in einem Template konfiguriert werden, welche WMI-Klassen und-Attribute eingesammelt werden können. Registry-Einträge lassen sich indirekt über den WMI Registry Provider in den WMI-Namensraum einblenden und damit auch mittels Inventur vom Client abrufen. Die Inventurinformationen werden in einer SQL Server-Datenbank gespeichert und web-basierte Berichte können mit dem Browser abgerufen werden, um so zentral eine Konfigurationsübersicht zu erhalten.

Das PowerShell-Script und die MOF-Vorlagen für Microsoft Endpoint Configuration Manager haben wir für Euch auf Github zur Verfügung gestellt: https://github.com/teal-technology-consulting/Test-CredentialGuardConfiguration