In Microsoft Windows gibt es zwei Schwachpunkte, die seit Jahren erfolgreich für Angriffe ausgenutzt werden: Ausführen von beliebigem Code und Auslesen von Zugangsdaten aus dem Speicher. Die Gegenmassnahmen von Microsoft haben bisher nicht die erwünschte Wirkung erzielt. Es wurden verschiedene Whitelisting-Ansätze präsentiert, um die Ausführung von Code zu verhindern. Diese können jedoch teilweise umgangen, oder gar von einem Angreifer, der administrative Rechte erlangt hat, deaktiviert werden. Hat ein Angreifer Kontrolle über das Betriebssystem erlangt, kann dieser die vorhandenen Kontrollsysteme manipulieren. Dies ist das schwache Glied in der Kette. Das Auslesen von Klartext-Passwörtern kann mittlerweile durch eine restriktive Konfiguration unterbunden werden.

Es ist aber nach wie vor möglich NTLM-Hashes auszulesen, die für Pass-the-Hash-Angriffe verwendet werden können. Auch hier gilt, dass ein Angreifer mit Kontrolle über das System, eine restriktive Konfiguration manipulieren kann. Mit der Einführung von Windows 10 präsentierte Microsoft die Funktionen Credential Guard und Device Guard, welche diese bestehenden Schwachstellen schliessen sollen. In diesem Beitrag stellen wir diese Funktionen vor und schätzen deren Einfluss auf die Sicherheit des Betriebssystems ein.

Virtual Secure Mode

Die wesentliche Neuerung von Credential Guard und Device Guard ist die Nutzung von Virtualisierungstechniken, um eine Isolation dieser Funktionen vom Betriebssystem zu erreichen und somit diese besser vor einem Angreifer oder Malware schützen zu können. Beide basieren auf der Technologie Virtual Secure Mode (VSM). VSM ist ein geschützter Container, der in einem Hyper-V Hypervisor betrieben wird, und dadurch vom Windows 10 Host und dessen Kernel isoliert ist. Innerhalb dieses Containers kann nur explizit erlaubter Code ausgeführt werden. Dabei wird eine konstante Prüfung der Code-Integrität durchgeführt. Microsoft bezeichnet diese Technologie auch als Virtualization Based Security (VBS).

VSM setzt analog wie der Betrieb einer herkömmlichen virtuellen Maschine auf hardwarebasierte Schutzvorkehrungen. Der Hypervisor nutzt die Virtualisierung-Erweiterungen des Prozessors, um Zugriff auf Daten im Speicher zu schützen und sicherzustellen, dass jede Instanz nur auf eigene Daten zugreifen kann. Der Windows Kernel hat demzufolge keinen direkten Zugriff auf den VSM-Container. Aktuell können drei Funktionen in VSM ausgeführt werden:

1. Local Security Authority (LSA)
2. Code-Integrität-Kontrolle in der Form der Kernel Mode Code Integrity (KMCI)
3. Die Hypervisor eigene Code-Integrität-Kontrolle namens Hypervisor Code Integrity (HVCI)

Anforderungen und Installation

Damit der Virtual Secure Mode genutzt werden kann, muss die Hardware des Geräts die folgenden Punkte erfüllen:

• UEFI (Native Mode) und Secure Boot aktiviert
• Unterstützung für Windows 64 Bit (Enterprise Version)
• Second Layer Address Translation (SLAT) und Virtualization Extensions (Intel VT oder AMD V)
• Trusted Platform Module (TPM) wird empfohlen

Das Windows Feature Hyper-V Hypervisor muss anschliessend installiert werden, die Hyper-V Komponenten werden nicht benötigt. VSM selbst wird über die Group Policy Turn On Virtualization Based Security unter dem Pfad Computer Configuration\Administrative Templates\System\Device Guard verwaltet.

Für die Optionen Virtualization Based Protection of Code Integrity und Credential Guard Configuration kann die Einstellung Enabled with UEFI lock gewählt werden. Diese Massnahme verhindert, dass diese Optionen remote deaktiviert werden können. Um diese zu Deaktivieren, muss die UEFI-Konfiguration lokal am Gerät zurückgesetzt werden.

Nach der Aktivierung des Virtual Secure Mode können Credential Guard und Device Guard eingesetzt werden.

Credential Guard

Die Funktion Credential Guard sichert den Zugriff auf System- und Benutzer-Kennwörter ab, damit im Falle einer Kompromittierung des Systems das Auslesen von Domänen-Zugangsdaten nicht mehr möglich ist. Dazu werden Zugangsdaten, die bisher im Speicher des Prozess Local Security Authority (LSA) abgelegt wurden, in einen virtualisierten und isolierten LSA-Prozess ausgelagert. Der isolierte LSA-Prozess namens LsaIso besteht nur aus einem reduzierten Set von Betriebssystem-Binärdateien, die für den eigentlichen Betrieb benötigt werden. Diese Binärdateien sind allesamt signiert und diese Signaturen werden jeweils vor der Ausführung validiert. Die Zugangsdaten sind für das Betriebssystem nicht mehr direkt erreichbar, der LSA-Prozess fragt diese über Remote Procedure Calls ab. Somit soll sichergestellt werden, dass ein unbefugter Zugriff auf Zugangsdaten nicht möglich ist. Zurzeit können mit Credential Guard NTLM- und Kerberos-Zugangsdaten von Domänen-Accounts geschützt werden. Zu beachten ist, dass lokale Konten und Microsoft Accounts durch Credential Guard nicht geschützt werden.

Das Tool Mimikatz, vorgestellt im Beitrag Windows Passwörter – Ein wohlbekanntes Geheimnis, kann unter anderem Zugangsdaten aus dem Speicher des LSA-Prozesses lesen und ist deshalb ein idealer Testkandidat für Credential Guard. In einer Standardinstallation von Windows 10 ist es möglich den NTLM-Hash eines Benutzers auszulesen:

Nach Aktivierung von Credential Guard kann dieser nicht mehr ausgelesen werden:

Device Guard

Das Ziel der Funktion Device Guard ist die Ausführung von bösartigem Code zu verhindern. Es handelt sich um eine Whitelisting Lösung mit einem signaturbasierten Ansatz. Es soll nur Code ausgeführt werden, der als bewusst gutartig eingestuft wurde. Device Guard blockt das Laden von Treibern, schränkt die Ausführung von Binärdateien (inklusive DLLs) im User Mode, MSI sowie Skripte (PowerShell, Windows Script Host, VBS, JS, WSF und WSC) ein, welche nicht explizit erlaubt wurden. Bei PowerShell werden Skripte grundsätzlich im Constrained Language Mode betrieben; es sei denn, sie wurden explizit zur Ausführung freigegeben.

Der Vorteil von Device Guard gegenüber anderen Lösungen, wie Microsoft AppLocker, ist die Verwendung der Virtualization Based Security und somit der Isolation vom Rest des Betriebssystems. Dadurch ist die Policy vor Manipulationen durch Administratoren oder Malware mit entsprechenden Ausführberechtigungen geschützt.

Device Guard besteht aus den folgenden drei Primärkomponenten:

• Configurable Code Integrity (CCI): Stellt sicher, dass nur vertrauenswürdiger Code nach Start des Boot Loaders ausgeführt wird
• VSM Protected Code Integrity: Die Code-Integrität-Kontrolle für Kernel Mode Code Integrity (KMCI) und Hypervisor Code Integrity (HVCI) wird isoliert im VSM ausgeführt
• Platform und UEFI Secure Boot: stellt sicher, dass Boot Binärdateien und die UEFI Firmware signiert sind und nicht verändert wurden

Für die Implementierung von Device Guard gelten ähnliche Anforderungen für VSM.

Die Erstellung einer Code Integrity Policy sollte auf einem System erfolgen, das alle erforderliche Software für den Betrieb enthält (Golden Image). Über das PowerShell Cmdlet New-CIPolicy wird das System auf installierte Anwendungen untersucht und auf dieser Basis eine Policy generiert. Die Policy liegt im XML-Format vor und wird vor Gebrauch mittels ConvertFrom-CIPolicy in ein Binärformat konvertiert. Der Deploy Guide des Microsoft Mitarbeiters Brian Lich bespricht alle zur Erstellung einer solchen Policy notwendigen Schritte.

Die Device Guard Policy sollte zuerst immer im Audit Mode betrieben werden. Dabei werden Verstösse gegen die Policy zugelassen und nur im Event Log Applications and Services Logs\Microsoft\Windows\CodeIntegrity\Operational aufgezeichnet. Damit kann sichergestellt werden, dass die Policy nicht für den Betrieb notwendige Applikationen blockiert. Falls mehrere Policies erstellt werden, beispielsweise eine Initial Policy sowie weitere Policies, die Spezialfälle behandeln, beispielsweise das Blockieren eines Programms, müssen diese zusammengelegt werden, da nur eine binäre Policy pro Rechner verwendet werden kann. Dazu wird das Cmdlet Merge-CIPolicy eingesetzt. Als zusätzliche Schutzmassnahme kann für die CI Policy selbst eine Signaturprüfung aktiviert werden.

Einschätzung – Wendet sich das Blatt?

Der Einsatz von Virtualisierungstechniken bringt einen neuen Sicherheitslevel für Windows mit sich. Da die sicherheitsrelevanten Funktionen vom Betriebssystem isoliert sind, wird der bisherige Schwachpunkt, dass ein Angreifer mit Kontrolle über das System Schutzmassnahmen aushebeln kann, mitigiert. Dies alleine ist ein grosser Schritt für die Sicherheit eines Systems.

Credential Guard unterbindet die momentan bekannten Angriffe auf den LSA-Prozess und verhindert so bis auf weiteres das Auslesen von Zugangsdaten aus dem Speicher. Sofern die Hardware-Anforderungen erfüllt sind, kann Credential Guard über eine Group Policy aktiviert werden und muss nicht weiter konfiguriert oder angepasst werden. Es ist dementsprechend verhältnismässig einfach diese Funktion einzusetzen. Die Implementation von Credential Guard im Rahmen eines Windows 10 Rollouts wird als realistisch eingeschätzt. Der Aufwand für Angreifer an Domänen-Zugangsdaten zu gelangen wird dadurch zukünftig erhöht. Credential Guard ist ein Schritt in die richtige Richtung, kann aber nicht alle Angriffsformen unterbinden. So sind Angriffe über Phishing, Key Logger, sowie auf Zugangsdaten ausserhalb Credential Guard, oder auch direkt auf die Sitzung von angemeldeten Benutzern weiterhin möglich.

Die Implementation von Device Guard ist im Gegenzug einiges komplexer als Credential Guard. Durch den Einsatz von Signaturen sollte einerseits eine eigene PKI-Umgebung zur Verfügung stehen, damit eigene Code-Signing-Zertifikate eingesetzt werden können. Zudem besteht eine Abhängigkeit zu den Software-Herstellern, dass diese ihre Anwendungen ebenfalls korrekt signieren. Es ist zwar vorgesehen, dass Anwendungen ohne Signatur mit der Aufnahme von Hashes als Ausnahme in die Policy aufgenommen werden können. Bei einer heterogenen Umgebung mit vielen verschiedenen Anwendungen kann dies eine grosse Herausforderung darstellen. Zudem ist die Konfiguration einer wirkungsvollen Code Integrity Policy zurzeit nur über die PowerShell Cmdlets und Bearbeiten der XML-Datei möglich. Das Fehlen einer grafischen Konfigurationsoberfläche könnte einen hemmenden Einfluss auf die Verbreitung von Device Guard haben. Es ist daher davon auszugehen, dass Device Guard nur in wenigen Unternehmen in den kommenden drei bis fünf Jahren eingesetzt wird.

Der Security Researcher Casey Smith hat bereits einige Umgehungsmöglichkeiten einer Standard Code Integrity Policy gefunden. Durch den Einsatz von Debugger, des Tools MSBuild.exe des .NET Frameworks sowie des Tools CSI.exe für C# Scripting konnte eine Policy, generiert analog des Beispiels im Kapitel Device Guard, umgangen werden und es war möglich beliebigen Code auszuführen. Alle diese Bypasses basieren darauf, dass interne und vertrauenswürdige Windows-Tools zur Ausführung von zusätzlichem Code missbraucht werden können. Darauf hat Matt Graeber eine separate Policy als Gegenmassnahme für diese bekannten Bypasses erstellt. Durch die Anpassung von Matt werden diese Tools explizit blockiert, beziehungsweise erst zugelassen, wenn die minimale Versionsnummer 99.0.0.0 erreicht wurde. Das Kopf-an-Kopf-Rennen zwischen Angriff und Verteidigung wird auch mit Device Guard weitergehen.

Fazit

Credential Guard und Device Guard haben das Potential, punktuell die Sicherheitslandschaft zu verändern. Mit diesen beiden Funktionen werden unter Windows neue Sicherheitskontrollen basierend auf Virtualisierungstechniken eingeführt. Ob dieses Potential aber genutzt werden kann, hängt davon ab, ob diese Funktionen auch in der Praxis eingesetzt werden können. Vor allem bei Device Guard werden noch Jahre vergehen, bis eine grossflächige Implementation beobachtet werden kann. Es werden noch einige Jahre vergehen, dabei viele Zeilen von bösartigen Code ausgeführt und sensitive Zugangsdaten unerlaubt ausgelesen werden, bis sich das Blatt wirklich ändert.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• http://subt0×10.blogspot.ch/2016/05/to-disarm-device-guard-bring-debugger.html
• http://subt0×10.blogspot.com
• http://subt0×10.blogspot.com/2016/09/application-whitelisting-bypass-csiexe.html
• http://subt0×10.blogspot.com/2016/09/bypassing-application-whitelisting.html
• http://www.exploit-monday.com/
• https://github.com/gentilkiwi/mimikatz
• https://github.com/mattifestation/DeviceGuardBypassMitigationRules/blob/master/BypassDenyPolicy.xml
• https://technet.microsoft.com/en-us/itpro/windows/keep-secure/deploy-code-integrity-policies-steps
• https://technet.microsoft.com/en-us/itpro/windows/keep-secure/device-guard-deployment-guide
• https://technet.microsoft.com/en-us/itpro/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard
• https://technet.microsoft.com/en-us/library/mt634485.aspx
• https://technet.microsoft.com/en-us/library/mt733073.aspx
• https://technet.microsoft.com/itpro/windows/keep-secure/credential-guard
• https://technet.microsoft.com/library/mt634473.aspx