| | 0

Windows 10 Enterprise Serie: Schütze deine Credentials – Credential Guard

>> zur Übersicht und Einleitung der Blogserie “Windows Enterprise Serie”

Credential Guard nutzt (genau wie das Windows 10 Feature Device Guard) eine neue Komponente des Betriebssystems genannt „virtualization based securtiy“. Diese Komponente stellt im Betriebssystem über die Virtualisierungstechnik eine stark gesicherte Ebene bereit.
Auf dieser Ebene werden bei aktiviertem Credential Guard „secrets“ (Passworthashes, Kerberos Tickets) abgelegt. Diese sind isoliert vom Rest des Betriebssystems und somit deutlich besser geschützt als in vergangenen Windows Versionen.

Voraussetzungen:

Hardware:

  • TPM (v1.2) chip – optional (Verschlüsselungschlüssel wird im Chip gespeichert)
  • Prozessor mit Virtualisierungsunterstützung (Intel VT-x oder AMD-V und Second Level Address Translation)

Software:

  • UEFI Version 2.3.1 oder höher
  • Windows 10 Enterprise
  • 64-bit auf Grund der Hyper-V Voraussetzung

Konfiguration

Um Credential Guard zu aktivieren muss folgendes konfiguriert sein:
–    Aktivieren des Hyper-V Feature (Plattform, Verwaltungstools werden nicht benötigt)
–    Aktivieren des isolierter Benutzermodus Feature
–    Enable virtualization based security via GPO (oder via Registry)

  • GPO: Administrative Vorlagen -> System -> Device Guard
    -> Turn-On Virtualization Based Security -> enabled
    –> Platform Security Level -> Secure Boot oder Secure Boot mit DMA Protection (DMA = Direct Memory Access)
    –> Credential Guard Konfiguration -> enabled mit UEFI lock (Credential Guard kann nicht Remote deaktiviert werden)
  • Registry: HKLM\System\CurrentControlSet\Control
    ->Device Guard
    –> DWORD “EnableVirtualizationBasedSecurity“ auf Wert: 1
    –> DWORD “RequirePlatformSecurityFeatures“ auf Wert: 1 für Secure Boot und Wert: 2 für  Secure Boot mit DMA Protection
  • LSA
    -> DWORD „LsaCfgFlags“ auf Wert: 1 um Credential Guard mit UEFI Lock zu aktivieren und Wert: 2 ohne den UEFI Lock

Die Enterprise Images können mit DISM, unattended.xml, Skripten oder anderen Methoden angepasst werden um die Voraussetzungen des Features bereits ab Installation zu erfüllen.
Die Konfiguration kann per GPO oder im Falle der Registry Konfiguration per LogonSkript oder SCCM Compliance Management erfolgen.

Püfen ob Credential Guard aktiviert ist:
–    Check der laufenden Prozesse:

  • Secure System (gehört zum Virtual Secure Mode)
  • Credential guard

–    Check der Systemübersicht “msinfo32.exe”

  • Dort sollten 5 Device Guard Einträge sein

Beschreibung

Die Local Security Authority (LSA) in Betriebssystem ohne Credential Guard gehört zu den Nummer 1 Zielen von Angreifern. Denn sie speichert Passworthashes und Kerberostickets und anderes im Prozessmemory. Das bedeutet, dass ein Angreifer mit lokalen Adminrechten nur den Speicher auslesen muss und die gehashten Informationen abgreifen kann. Man muss diese Informationen nicht einmal umrechnen, denn Authentifizierungsmethoden wir NTLM schicken niemals Klartextpasswörter über das Netz, sondern….richtig mitgedacht…..ausschließlich gehashte. Ich kann also als Angreifer mit dem gehashten Passwort aus dem Speicher des LSA Prozesses einen Anmeldevorgang durchführen.

Kurzer Security Ausflug:

Pass-the-hash attacks are possible if the attacker was able to get the password hash of a user. The authentication protocols like NTLM or LanMan have the problem, that those hashes weren’t salted. Were “salted” means random data, which is added to the hash of the password per authentication.
If a user inputs username and password to authenticate, the password will not be send in clear text to the authentication destination. The OS does an API call to get the hash and authentication is done by username and hash. An attacker just needs username and hash to authenticate on any remote server on which the user has access to.

Pass-the-ticket attacks are somehow the same. An attacker needs to completely compromise a system to extract a user’s Kerberos ticket and authenticate on remote servers with that ticket. Those tickets have a lifetime of 10 hours per default.

The Theory behind

Hier der Prozess ohne aktiviertem Credential Guard:

  1. Eingabe von Domain, Username und Passwort
  2. Der Credential Provider (ehemals GINA) ruft die LogOnUser Funktion auf und übergibt die Daten an die LSA
  3. LSA ruft alle Plugins (NTLM, Kerberos, Digest, etc.) auf um SSO zu gewährleisten
  4. Die Plugins generieren Hashes und Tickets, die für ihre Authentifizierungsmethode gebraucht werden
  5. LSA speichert die Hashes und Tickets im Prozessspeicher
  6. Dann passiert die Authentifizierung des Users

Diese Daten liegen von allen aktuell und kurzfristig zuvor angemeldeten Benutzern im Speicher und können ausgelesen werden

Hacking myself:

Um das bei Kunden vorführen zu können oder einfach mal zu testen, habe ich den Weg zu den LSA Secrets beschrieben:

  1. Besorg dir Sysinternals ProcDump direct von Microsoft
    https://technet.microsoft.com/en-us/sysinternals/dd996900.aspx
  2. Um die LSA Daten in Klartext umzuwandeln benutzen wir mimikatz (Die Binaries laden und nicht die Quellen) http://blog.gentilkiwi.com/mimikatz
    Keines dieser Tools muss installiert werden und kann damit fast überall „geräuschlos“ benutzt werden. ProcDump hinterlässt lediglich einen Registry Key
  3. Öffne eine administrative Shell (Ich nehme hier PowerShell), navigiere in das procdump.exe Verzeichnis gib folgenden Befehl ein:
    Code: procdump.exe –accepteula –ma lsass.exe [filename]
    Das erzeugt eine aktuelle Dump Datei vom LSA-Prozessspeicher
  4. Navigiere zur mimikatz.exe und tippe den Befehl ein:
    Code:
    .\mimikatz.exe  (hiernach kommt man in eine mimikatz-eigene Shell)
    sekurlsa::minidump [filename]
    sekurlsa::tspkg
  5. Wir tippen ein
    Code: sekurlsa::credman
    Äh ok. Über das Auslesen vom CredentialManager bekomme ich nun auch noch meine Domain Credentials geliefert. Was will ich mehr?

Das war überraschend einfach. Natürlich braucht man dafür administrative Rechte, aber die bekomme ich ganz leicht mit physikalischem Zugriff zur Maschine und einer Linux Boot CD oder dem Reparaturmodus

Der Vorteil von Credential Guard:

Es gibt mit aktiviertem Credential Guard eine weitere Komponente, die sich “isolated LSA environment” (LSAiso) nennt. Die LSAiso läuft in der Virtualisierungsschicht des Betriebssystems und dient dazu die Hashes und Tickets von der LSA entgegen zu nehmen und zu speichern.
LSAiso ist wie ein kleiner Container mit sehr wenig Code, ohne Treiber und alles innerhalb der Virtualisierungsschicht. Die Binaries sind mit Signaturen geschützt und werden bei jedem Aufruf neu überprüft um die Integrität zu gewährleisten.
Die LSA kann mit der LSAiso nur über Prozeduraufrufe kommunizieren. Außerdem hat ausser der LSA nichts vom Betriebssystem Berechtigung auf die LSAiso zuzugreifen.

Mit aktiviertem Credential Guard wird also ein weiterer Schritt zum Authentifizierungsprozess hinzugefügt, bei dem die LSA die Hashes und Tickets nicht mehr im Prozessspeicher ablegt sondern an die LSAiso übergibt.

Fazit

Jawoll das ist doch ein nettes Feature, aber wie sieht mein persönliches Fazit dazu aus?

Wenn man sieht wie einfach es ist, die Credentials angemeldeter Nutzer aus dem Speicher zu ziehen, so ist Credential Guard sicherlich eine Methode das Ganze um Längen sicherer zu machen.
Es ist leicht zu aktivieren, hat überschaubare Voraussetzungen und braucht keinen großen Managementaufwand. Denn wir alle wissen, dass erhöhte Sicherheit meist mit mehr Aufwand einhergeht, der wiederum die Sicherheit drückt, weil User beginnen Umwege zu finden.
Dies ist hier nicht so. Der User merkt davon nichts und es gibt auch keinerlei Umstellung für ihn.

Allerdings gibt es dabei auch ein paar Dinge zu beachten:

  • nicht supported sind alte Versionen wie NTLMv1, MS-Chapv2 und schwache Kerberos Verschlüsselung wie DES; Sie werden außerhalb Credential Guard über den klassischen Weg abgewickelt.
  • Passwörter, die außerhalb der Standardprozesse von Windows gemanaged werden (Applikationsintern zum Beispiel) sind natürlich auch nicht supported
  • Wie bei jeder neuen Lösung gibt es auch das Problem der Abwärtskompatibilität. Software von Drittanbietern, die als Security Support Provider sich über das Interface mit dranhängen müssen nach bestimmten Standards handeln. Das Abfragen von Hashes direkt von der LSA ist nicht mehr vom Credential Guard erlaubt. Daher müssen diese Anbieter getestet werden bevor man in das unternehmensweite Deployment von Credential Guard geht.