Am 10. Juli 2014 habe ich im Beitrag Windows Passwörter – Ein wohlbekanntes Geheimnis? erstmals über Windows Local Security Authority (LSA) geschrieben. In den vergangenen fünf Jahren wurden von Microsoft einige Verbesserungen in diesem Bereich eingeführt. Trotzdem ist es auch im Jahr 2019 noch möglich Zugangsdaten aus dem Arbeitsspeicher zu lesen. In diesem Beitrag fasse ich die Entwicklungen der letzten Jahre zusammen und stelle die Hardeningmöglichkeiten vor.

Der Local Security Authority Subsystem Service (LSASS) ist für die Umsetzung der Sicherheitspolicy, der Verifikation von Benutzern, der Verarbeitung von Passwortwechseln, die Erstellung von Access-Token sowie für die Verwaltung von Smartcards zuständig. Dazu werden verschiedene Sicherheitsmodule, bezeichnet als Security Support Provider (SSP) in den LSASS-Prozess geladen. Zu diesen Sicherheitsmodulen gehören unter anderem Kerberos, NTLM (MSV1), TLS/SSL (Schannel) und Digest (WDigest). Über diese Sicherheitsmodule ist es möglich auf Passwörter im Arbeitsspeicher zuzugreifen.

Vor dem Microsoft Security Advisory 2871997 herrschte eine dunkle Zeit für die Sicherheit der Passwörter im Arbeitsspeicher. Die Passwörter wurden durch die Module Kerberos oder WDigest im Klartext abgelegt. Tools wie Mimikatz oder Windows Credentials Editor (WCE) hatten ein einfaches Spiel diese auszulesen.

Nach der Veröffentlichung des Advisory 2871997 war es möglich das System so zu härten, dass die Passwörter nicht mehr im Klartext abgelegt wurden. Für WDigest kann der Registry-Key UseLogonCredential=dword:00000000 unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest gesetzt werden.

Die Funktion Credential Delegation hat ebenfalls noch Einfluss, ob Passwörter im Klartext aus dem LSASS-Speicher ausgelesen werden können. Durch das Konfigurieren der folgenden Einstellungen kann dies präventiv unterbunden werden:

• Computer Configuration\Administrative Templates\System\Credentials Delegation\Allow delegation default credentials auf Disabled (tspkg)
• Computer Configuration\Administrative Templates\System\Credentials Delegation\Encryption Oracle Remediation auf Enabled: Force Updated Clients

Eine ungenutzte Chance

Mit Windows 8.1 und Windows Server 2012 R2 führte Microsoft die Funktion Additional LSA Protection ein. Dabei kann der LSASS-Prozess als Protected Process Light konfiguriert werden. Dafür muss der Registry-Key RunAsPPL=dword:00000001 unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa gesetzt werden. Danach müssen die Sicherheitsmodule von Microsoft signiert sein und der Zugriff auf den LSASS-Speicher und somit die Zugangsdaten ist für Non-Protected-Prozesse nicht mehr möglich.

Wie im Beitrag Monitoring – Detektieren von Angriffen mittels MITRE ATT&CK aufgezeigt, ist es mit der Hilfe von Mimikatz trotzdem noch möglich auf den LSASS-Prozess zuzugreifen und Zugangsdaten auszulesen. Dafür muss mit Mimikatz ein Treiber geladen werden, der korrekt für den Betrieb im Kernel-Mode signiert wurde. Somit konnte die Hürde für den Zugriff höher gelegt werden. Ein Security Operations Center kann zudem mittels Überwachung von Windows-Event-Logs diesen Angriff erkennen und entsprechend darauf reagieren.

Die Funktion LSA Protection wird nach unseren Beobachtungen bei Assessments überraschenderweise nur wenig genutzt, weder auf Server noch auf Clientsystemen.

Credential Guard

Credential Guard wurde mit Windows 10 und Windows Server 2016 eingeführt. Im Artikel Credential und Device Guard – Wendet sich das Blatt? schloss ich mit dem Fazit, dass vermutlich noch Jahre vergehen, bis Credential Guard verbreitet eingesetzt wird. Durch die erhöhten Voraussetzung für den Betrieb des Virtual Secure Mode (VSM), Lizenz-Anforderungen (Windows Enterprise) und Inkompatibilitäten mit Anwendungen erfolgt die Einführung nur zögerlich. Im Gegensatz zur Funktion LSA Protection treffen wir Credential Guard dennoch vermehrt in der Praxis an.

Durch Credential Guard werden Domänen-Zugangsdaten geschützt. Nicht geschützt verbleiben lokale Konten, Microsoft Accounts sowie PIN-Codes von Smartcards. Für die lokalen Administrationszugänge existieren Lösungen wie Local Administrator Password Solution (LAPS) oder Drittprodukte, damit zumindest die Passwörter des lokalen Administratorenkontos auf allen Systemen unterschiedlich gehalten werden können.

Ein direkter Angriff auf Credential Guard ist auch im November 2019 nicht öffentlich bekannt. Es gibt Umgehungsmöglichkeiten wie das Laden eines Sicherheitsmoduls mit Mimikatz, das die Zugangsdaten aller lokal authentisierten Accounts aufzeichnet. Dies kann jedoch durch die Aktivierung von LSA Protection erschwert werden, da nur von Microsoft signierte SSPs geladen werden dürfen. Oder dieser Schutz zuerst mit Mimikatz entfernt werden muss.

Weitere Hardeningmöglichkeiten

Neben den bereits erwähnten Funktionen LSA Protection und Credential Guard können weitere Sicherheitskomponenten zum Schutz der Zugangsdaten beitragen. Auf den meisten Systemen können Administratoren die Debug-Privilegien (SeDebugPrivilege) entzogen werden. Diese Rechte werden dazu benötigt, um einen Debugger für einen beliebigen Prozess oder den Kernel zu verwenden. Im normalen Betrieb werden diese Rechte selten genutzt. Tools wie Mimikatz benötigen diese Rechte, um mit dem LSASS-Prozess zu interagieren. In den Gruppenrichtlinien kann der lokalen Administratorengruppe unter Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\Debug programs das Recht entzogen werden.

Zusätzlich schützt die Verwendung einer Application-Whitelisting-Lösung vor Malware und die Umsetzung einer umfassenden Monitoring-Lösung hilft möglichen Missbrauch zu detektieren.

Fazit

Die von Microsoft eingeführten Funktionen und Härtungsmassnahmen führen zu einem erhöhten Schutz des LSASS-Prozess. Wenn die aufgeführten Massnahmen auf einem System umgesetzt werden können, wird das Auslesen von Zugangsdaten enorm erschwert. Dies ist insbesondere wichtig, da viele Malware auf Credential Dumping setzen und dabei auch auf Bestandteile von Mimikatz oder WCE zurückgreifen. Durch eine Kombination der aufgeführten Massnahmen können gespeicherten Geheimnisse in der Local Security Authority sicher vor solchen Angriffen aufbewahrt werden.

Ü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

• https://adsecurity.org/?p=1760
• https://attack.mitre.org/techniques/T1003/
• https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2016/2871997
• https://github.com/gentilkiwi/mimikatz
• https://www.ampliasecurity.com/research/windows-credentials-editor/