Blog

Microsoft Security Baseline Review

10.6.2021 | 14 minutes read

Am 18.05.2021 hat Microsoft die Security Baseline für das aktuelle Windows 10 Betriebsystem 21H1 veröffentlicht. Das Release betrifft diesmal nur für Windows 10. Für Server wird es wohl im Spätjahr ein weiteres Update geben. Grund genug einmal die aktuelle Baseline für Windows 10 Clients anzuschauen und zu prüfen, an welchen Stellschrauben Administratoren nochmal selbst Hand anlegen sollte. Dabei beschränke ich mich allerdings auf Themen, die dazu führen können, dass ein potentieller Angreifer einen Client übernimmt oder seine Aktivitäten besser verstecken kann. Einstellungen, die in der Praxis für einen Angreifer keinen nutzen bringen, werden hier nicht berücksichtigt.

Für alle die noch nie etwas für den Security Baselines von Microsoft gehört haben: Die Security Baseline ist Teil des Security Compliance Toolkit von Microsoft und enthält gehärtete oder sicherere Gruppenrichtlinieneinstellungs für das jeweilig aktuelle Windows Release. Die Security Baseline sollte die Basis für die Clientkonfiguration bilden und einen Mindeststandard an Sicherheitseinstellungen im Unternehmen definieren. Ausnahmen sind bei der ein oder anderen Einstellung selbstverständlich möglich. Natürlich möchte ich hier nicht verschweigen, dass die Baseline nur ein kleiner Baustein bei einer sicheren Clientkonfiguration darstellt. Neben der Baseline sind noch viele weitere Dinge zu beachten, die nicht über Gruppenrichtlinien konfiguriert werden können. Aber darauf gehen wir in einem weiteren Blogeintrag einmal genauer ein.

Die Security Baseline von Microsoft umfassen acht Gruppenrichtlinienobjekte und 363 Einstellungen, wobei es auch mal vorkommen kann, dass die Einstellung darin besteht einen Wert leer zu lassen. Von den 363 Einstellungen sind 259 Computereinstellungen, fünf Benutzerinstellungen, 23 Überwachungseinstellungen und 64 Sicherheitseinstellungen. Die Security Baseline kann hier runtergeladen werden. Wenn die “Windows 10 version 21H1 Security Baseline.zip” entpackt wird, bringt sie wie alle Baselines vor ihr fünf Ordner mit.

MSFT Policies

Im Ordner Scripts befindet sich ein Skript mit dem die Gruppenrichtlinien Objekte ins Active Directory (ausreichend Rechte vorrausgesetzt) importiert werden können.

Setup

Um den Sicherheitsgewinn ermitteln zu können, werden die folgenden Richtlinien aus der Baseline auf einen Test-Client angewendet:

MSFT Windows 10 21H1 - BitLocker
MSFT Windows 10 21H1 - Computer
MSFT Windows 10 21H1 - Credential Guard
MSFT Windows 10 21H1 - Defender Antivirus
MSFT Windows 10 21H1 - Domain Security

Weiterhin gibt es einen Referenz-Client, auf dem keinerlei Veränderung an den Standardeinstellungen durchgeführt wurden.

Defizite

In diesem Abschnitt werden wir nun auf gängige Angriffe eingehen und ermitteln gegen welche die Security Baseline von Microsoft einen Schutz bieten und gegen welche Angriffe weitere Maßnahmen implementiert werden müssen.

Netzwerk

Namensauflösung

Die Namensauflösung dient dazu einen menschenlesbaren Hostname in eine IP-Adresse zu übersetzen. Zur Namensauflösung im Netzwerk arbeitet Windows die folgenden Protokolle nacheinander ab:

Prüfen, ob es der eigene Name ist
Durchsuchen vom lokalen Cache
Durchsuchen vom Host File (c:\windows\system32\drivers\etc\hosts)
Anfrage beim DNS Server
Netzwerk broadcasting mit LLMNR und NetBIOS

Vorallem die letzten beide Protokolle, vorrausgesetzt der Mechanismus kommt soweit, kann ein Angreifer nutzen um seinem Opfer vorzuspielen, dass der “gesuchte” Host der Host des Angreifers ist. Damit wird das Opfer dazu gebracht, eine Verbindung zum Angreifer aufzubauen und er kann beispielsweise mit einem der beiden folgenden Angriffe weitermachen.

Um zu verhindern, dass ein Angreifer einem Opfer eine falsche Identität vormachen kann, sollte vorallem das Broadcasting mittels NetBios und LLMNR deaktiviert werden. Diese entsprechenden Richtlinien sind in der Windows Security Baseline bereits vorhanden.

Hardening Multi-Cast

Abgreifen von Zugangsdaten

Bei diesem Angriff nutzt der Angreifer die Broadcast Protokolle, um seinem Opfer vorzumachen sein System sei das gesuchte Ziel. Im Anschluss versucht das Opfer eine Anmeldung am Zielsystem durchzuführen. Für die Authentifizierung in einem Windows Netzwerk gibt es neben Kerberos zwei weitere Varianten. Bei der ersten Variante, die das Challenge Response Protokoll NTLMv2 verwendet, kann der Angreifer den Handshakes aufzeichnen und anschließend Versuchen das Passwort des Anwenders zu erraten. Bei der zweiten Variante bringt der Angreifer sein Opfer dazu eine Basic-Authentifizierung durchzuführen und zeichnet die Verwendeten Zugangsdaten auf. Letzteres gelingt in der Regeln, wenn das Zielsystem versucht das Angreifer-System als HTTP Proxy zu verwenden.

Die Anmeldung mit NTLM funktioniert in etwa so:

Ein Benutzer fragt den Zugriff auf ein Zielsystem an
Das Zielsystem lehnt die Anfrage zunächst mit der Bitte ab eine Anmeldung durchzuführen. Dazu sendet das Zielsystem eine Challenge zurück.
Der Benutzer signiert die Challenge mit seinem Passwort-Hash und sendet die Antwort zurück.
Das Zielsystem sendet die Challenge zusammen mit der Antwort zum Domain Controller.
Der Domain Controller führt die gleiche Operation wie der Benutzer mit dem Passwort-Hash, den er in der NTDS.dit gespeichert hat und der Challenge durch und sendet Ok oder Nicht-Ok an das System zurück.
Das Zielsystem lässt den Zugriff in Abhängigkeit der Antwort vom DC und den lokalen Zugriffsrechten zu oder auch nicht.

Challenge Resp

In der Praxis werden solche Angriffe mit dem Tool Responder.py oder Inveigh durchgeführt. Hier ein Beispiel für die Aufzeichnung eines Handshakes:

Responder 1

Um in den Besitzt des Klartext-Passworts zu kommen, kann der Angreifer versuchen das Opfer dazu zu bringen eine Anmeldung an einem Fake HTTP Proxy durchzuführen, wenn dieser im Internet surft:

Fake Proxy

Relay Angriffe

Bei Relay-Angreifer versucht der Angreifer sein Computer zwischen sein Opfer und einem Zielsystem zu bringen. In dieser Position kann der Angreifer das NTLM-Protokoll von Windows missbrauchen, um die Anmeldedaten seines Opfers auf das Zielsystem umzuleiten und kann Aktionen im Namen seines Opfers auszuführen. Für diese Art Angriffe stehen Zahlreiche Tools wie Inveigh oder auch Impacket zur verfügung. Alles über Relay-Angriffe findet ihr in diesem überragenden Blogpost.

Das das Challenge-Response verfahren an sich kein Schutz vor Manipulation bietet, kann ein Angreifer wenn er zwischen Benutzer und Zielsystem sitzt, diese zu seinem Vorteil ausnutzen.

Challenge Resp2

Diese Art von Angriff kann mit vielen Netzwerkprotokollen aus der Microsoft Welt, die keinen eigenen Integritätschutz haben, durchgeführt werden. Am Bekanntesten ist hier wohl das sogenannte SMB-Relaying.

SMB-Relay

Im oben gezeigten Bild wird ein SMB-Relay Angriff auf den nicht gehärteten Client durchgeführt. Im Gegensatz zu dem nicht gehärteten Client, schlägt der Versuch ein SMB-Relay Angriff durchzuführen bei dem gehärteten Client fehl. Selbst wenn der “Insecure Guest Access” wieder zugelassen wird, schlägt SMB-Relay fehl, da die Security Baseline mittlerweile die Verwendung von Signaturen für SMB erzwingt. Dadurch sorgt das SMB-Protokoll dafür das eine Manipulation am Handshake auffält.

SMB-Signature enforcement

Allerdings kann Relaying auch teilweise zwischen Protokollen durchgeführt werden. So ist es beispielsweise für einen Angreifer möglich eine HTTP Verbindung entgegenzunehmen und die Authentifizierung auf das LDAP-Protokll und damit auf sein Ziel umzuleiten. Denkbar ist das Szenario wenn der Angreifer es schafft sein System als HTTP Proxy auf einem oder mehrere Systemen im Unternehmen einzutragen. Dann versuchen die Systeme Webseiten über den Proxy, der unter Kontrolle des Angreifer ist, zu erreichen. Hier kann das System vom Angreifer eine Authentifizierung mittels NTLM verlangen und den Handshake für ein anderes Protokoll wie LDAP oder SMB nutzen. Gegen diese Art der Angriffe sind mir, außer zu verhindern, dass ein Angreifer die Namenssuche von Clients manipuliert keine Bordmittel von Windows bekannt.

Relaying HTTP to SMB

Im Bild oben ist zu sehen, wie der gehärtete Client (192.168.1.104) einen Connect Request zur Kali-Maschine durchführt. ntlmrelayx.py wird hier verwendet, um eine Authentifizierung anzufordern und diese im Hintergrund an ein weiteres Zielsystem weiterzuleiten.

Windows Proxy Auto Discovery Protokoll

Das Windows Proxy Auto Discovery Protokoll (kurz: WPAD) wird verwendet, um einen potentiellen Web Proxy im lokalen Netzwerk zu finden. Dafür sucht der Client nach wpad.<domainame>. Zum Glück verwendet Windows seit Juni 2016 dafür nur noch DNS Abfragen und verzichtet auf die Broadcast abfragen. Der Grund dafür waren Schwachstellen im WPAD Protokoll. Die automatische Suche kann dennoch eine Möglichkeit für einen Angreifer sein, um sein System bei Clients im Netzwerk als Proxyserver einzutragen. Dann kann der Angreifer sowohl unverschlüsselten Datenverkehr mitlesen, als auch oben beschriebene NTLM-Relay Angriffe durchführen. Um als Proxy Server auf einem Client eingetragen zu werden, hat ein Angreifer mehrere Möglichkeiten:

Eintrag selber im DNS hinterlegen Das geht in einem Unternehmen dann, wenn das DNS Active Directory integriert ist und ein Computer im Netzwerk bereits übernommen wurde, bzw. der Angreifer im Besitzt valider Zugangsdaten für einen Benutzer ist. Denn in einem Active Directory kann jeder angemeldete Benutzer eigene DNS Einträge im DNS Server hinterlegen. Dafür kann beispielsweise das Tool Powermad verwendet werden. Weiterhin muss der wpad von einem Administrator oder DNS-Administrator aus der globales DNS Blocklist entfernt worden sein. Wo wir auch beim Thema wären, welche Accounts besonders schützenswert sind.
Den DNS Server übernehmen, falls ein Angreifer dann überhaupt noch Interesse an Clients hat.
In einem fremden Netzwerk den DNS-Server selbst bereitstellen, wobei dann wohl ein geeignetes weiteres Ziel fehlen würde.
Mittels Skript auf dem Client den Proxy zu konfigurieren, falls der Benutzer den Konfigurieren kann.

Die Security Baseline von Microsoft bietet an der Stelle keinen zusätzlichen Schutz. Hier empfehle ich den Administratoren, die WPAD Suche zu deaktivieren, bzw. den WPAD Server fest im System zu hinterlegen. Um die WPAD Suche zu deaktivieren, kann beispielsweise der Windows Service WinHttpAutoProxySvc deaktiviert werden. Alternativ kann die Suche via GPOs deaktiviert werden. Dafür muss ein Registry-Key erzeugt werden mittels Gruppenrichtlinie gesetzt werden.

Block WPAD

Ein weiterer guter Blogeintrag zu dem Thema findet ihr hier.

IPv6

IPv6 wird seit Windows Vista, soweit ich mich erinnere, unterstützt und ist auf den Windows 10 Clients auch standardmäßig aktiviert. Gemäß der Spezifikation ist IPv6 gegenüber IPv4 zu bevorzugen. In den Umgebungen die ich bisher gesehen habe, ist IPv6 auf den Systemen aktiviert aber nicht konfiguriert. Mithilfe von MITM6 kann ein Angreifer für die Administratoren das Ausrollen von IPv6 übernehmen. In dem Fall kann er eigene Adressen, DNS-Server und Gateways auf den Clients konfigurieren. Damit hat der Angreifer weitreichende Kontrolle über den Datenverkehr der anderen Systeme im Netzwerk und kann beispielsweise, die Suche nach dem WPAD Host, sofern nicht schon deaktiviert ausnutzen, um das eigene System als Proxy auf den Clients zu registrieren. Das erlaubt einem Angreifer den Internetverkehr mitzulesen oder auch diverse Relay-Angriffe auszuführen, die bereits oben beschrieben wurden.

Für die Umsetzung muss ein Angreifer zunächst einen geeigneten Zeitpunkt abwarten, wenn die Clients DHCP Abfragen machen. Der Erfahrung nach geschieht das meist morgens, wenn die Clients ins Netzwerk kommen und ihre IP-Adresse abfragen.

IPv6 assignment

Das Tool mitm6 weist hier einem Client eine entsprechende IPv6 Adresse zu und trägt den eigenen Host auch noch praktischerweise als Default Gateway und DNS Server ein.

IPv6 Config

Gegen ein derartiges Vorgehen schützt entweder das Deaktivieren von IPv6 im Netzwerkadapter von Windows oder den DHCP Server so zu konfigurieren, dass er selbst IPv6 Adressen vergibt. Außerhalb des eigenen Netzwerks hat ein Unternehmen allerdings keine Kontrolle über die Konfiguration der Netze, in die sich ein Gerät einwählt. Weitere Informationen zum Absichern von IPv6 auf Windows Clients findet ihr hier und hier.

Eine Möglichkeit zur Absicherung von IPv6 ist die lokale Windows Firewall. Diese Variante hat Dirk-Jan Mollema in seinem Blogpost über NTLM-Relaying erwähnt. Er empfiehlt, und zumindest im Labor funktioniert das auch, folgende Firewall-Regeln zu verwenden:

(Inbound) Core Networking - Dynamic Host Configuration Protocol for IPv6(DHCPV6-In)
(Inbound) Core Networking - Router Advertisement (ICMPv6-In)
(Outbound) Core Networking - Dynamic Host Configuration Protocol for IPv6(DHCPV6-Out)

Zu guter letzt sei noch die Security Baseline vom Center for Internet Security erwähnt. Sie bringt ein eigenes ADM zur Konfiguration von IPv6 mit.

Geräteverschlüsselung

Eine große Rolle bei der Sicherheit von Systemen spielt der Manipulationsschutz von Sicherheitsfunktionen des jeweiligen Betriebssystems. Zur Laufzeit kann sich Windows mittlerweile, vorallem gegen normale Anwender ganz gut verteidigen und auch gegen Admins gibt es einige wenige Schutzmechanismen. Wobei es immernoch gilt, dass es keine Sicherheit vor Administratoren gibt. Ein Problem vor dem aber alle Systeme stehen, egal ob Windows, Linux, IOS oder sonst ein System ist, dass es keinen Schutz gibt wenn das Gerät ausgeschaltet ist. Hier hilft nur die Verschlüsselung der Systemfestplatte mit einem ausreichend starken Authentifizierungsverfahren. Bei Windows steht dafür Standardmäßig BitLocker zur Verfügung. Für die Authentifizierung bietet BitLocker zahlreiche Varianten wie:

TPM-only, das heißt das TPM gibt den Entschlüsselungsschlüssel frei
Entschlüsselung durch einen USB-Stick
Verwendung einer PIN, zum Entsperren von BitLocker.

Microsoft hat hier in seiner Security Baseline nur sehr wenige Einstellungen gesetzt. Hier die wichtigsten Punkte an denen ein Unternehmen nocheinmal prüfen sollte.

Pre-Boot Authentifizierung

Die BitLocker Einstellungen von Microsoft erzwingen nach wie vor keine Pre-Boot Authentifizierung. Damit bootet das Gerät nach dem Einschalten bis zum Anmeldebildschirm. Hier sind zwei Dinge zu bedenken. Zum einen werden immer mal wieder im Anmeldebildschirm Schwachstellen bekannt. Erst kürzlich wurde ein Angriff namens Airstrike auf einen gesperrten Rechner bekannt. Dabei ist es unerheblich, ob der Rechner gesperrt oder erst gestartet wurde. Weiterhin gibt es einen, wenn auch etwas aufwändigeren Angriff, auf die Datenübertragen zwischen TPM und CPU. Der Angriff wird LPC Bus Sniffing Attack genannt und erlaubt das Extrahieren des Verschlüsselungsschlüssel, sobald er vom TPM an die CPU gesendet wird. Er wurde zuerst von Pulse Security hier veröffentlicht. Ein Video dazu findet ihr hier.

Als drittes bleiben noch Angriffe auf die Direct Memory Access Schnittstellen an den Laptops. Um Geräte wie externe Grafikkarten verwenden zu können, die einen extrem hohen Datendurchsatz benötigen, wurden Schnittstellen wie Firewire oder auch Thunderbolt etabliert. Diese Schnittstellen erlauben es den Geräten direkt in den RAM vom Computer zu schreiben und lesen. Ein Angreifer kann das nutzen, um im Hauptspeicher nach den BitLocker Schlüsseln zu suchen, die Passwortabfrage von Windows umzuprogrammieren oder auf mannigfaltige andere Art und Weise Windows zu seinen Gunsten zu manipulieren. Wer eine Idee davon haben will, was alles möglich ist dem empfehle ich einen Blick auf pcileech zu werfen.

Die Security Baseline verhindert von den genannten Angriffen nur den Angriff über das Serial Bus Protocol 2 (SBP-2), dass für Firewire verwendet wird, in dem es die Geräteklasse sperrt. Allerdings hatte Sami Laiho schon vor Jahren in einem Blogeintrag darauf hingewiesen, dass die Einstellung nicht ausreichen ist und weitere Geräteklassen geblockt werden sollten.

Disable dangerous devices

Weiterhin empfehle ich darüber nachzudenken, ob eine Pre-Boot Authentifizierung nicht doch für die Anwender zumutbar ist. Diese kann über die entsprechenden GPO Einstellungen erzwungen werden.

Verschlüsselung

Microsoft BitLocker verwendet standardmäßig eine 128-BIT AES Verschlüsselung. Auch wenn technisch derzeit nichts dagegen spricht, so kann hier trotzdem im Sinne der Nachhaltigkeit auf AES-256 gegangen werden.

Computer Configuration ->Administrative Templates -> Windows Components -> BitLocker Drive Encryption -> "Choose drive encryption method and cipher strength (Windows 10 [Version 1511] and later)" = Enabled (XTS-AES 256 Bit)

Anmeldebildschirm

Um das Risiko zusätzlicher Schwachstellen für gesperrte Computer zu minimieren und auch zukünftig Angriffe, wie den oben genannten Airstrike-Angriff zuvor zukommen, sollte im Sperrbildschirm nur möglichst wenig angezeigt werden. Hier sind vorallem zwei Button zu nennen. Der Knopf NetworkUI, mit der auch im gesperrten Bildschirm ein Netzwerk ausgewählt werden kann, und der “Ease of Access” Button. Beide Köpfe werden in der Security Baseline von Microsoft nicht berücksichtigt.

Der Network UI Button kann mithilfe von Gruppenrichtlinien ausgeblendet werden.

Computer Configuration -> Administrative Templates -> System -> Logon -> "Do not display network selection UI" = Enable

Um den “Ease of Access” Button auszublenden (bitte nur für Mitarbeiter machen, die das wirklich nicht brauchen), muss die Windows Registry editiert werden. Alle Infos dazu findet ihr hier.

Protokollierung

Beim Thema Protokollierung sind die Empfehlungen von Microsoft nahezu mit den Empfehlungen vom BSI, CIS oder anderen vergleichbar. Wenige Unterschiede gibt es dennoch. So protokolliert, die Security Baseline von Microsoft den Zugriff auf die Registry nicht. Da Angreifer oder auch Pentester immer mal wieder den ein oder anderen sensiblen Reg-Key setzen um einen Vorteil zu erhalten, sollte die Richtlinie zusammen mit den entsprechenden SACL einträgen definiert werden. Ein Beispiel für einen Reg-Key der im Unternehmen überwacht werden sollte ist HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\WDigest mit dem Wert UseLogonCredential. Wenn dieser Wert gesetzt wird, speichert die LSASS wieder die Anmeldedaten vom Benutzer im Klartext.

Um die Änderung in einem Netzwerk zu erkennen, muss das entsprechende Audit Protokoll über GPOs aktiviert werden. Weiterhin müssen im Nachgang noch die benötigten System Access Control List auf den sensiblen Regestry Keys gesetzt werden. Weitere Informationen über das Windows Event Log findet ihr u.a. in folgendem Cheat Sheet.

Eine weitere Auffälligkeit ist, dass die Baseline von Microsoft zwar die Process Erstellung (Event 4688) aufzeichnet, nicht aber das aufrufende Kommando speichert. Um das Kommando zusätzlich zu erhalten, muss zur Baseline von Microsoft noch die Policy Computer Configuration -> Administrative Templates -> System -> Audit Process Creation -> "Include command line in process creation events" = Enabled gesetzt werden.

Include Commandline

Positive ist, dass die Security Baseline den Speicherplatz für Eventlogs erhöht. Ob dies für die eigene Umgebung ausreichend ist, sollte im Einzelfall nochmal geprüft werden. Die entsprechenden Einträge sind unter Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. zu finden.

Weiterhin sei angemerkt, dass andere Themen wie Sysmon und Co in der Baseline aufgrund der Einschränkung auf GPOs nicht berücksichtigt werden.

Fazit

Die Security Baselines werden von Release zu Release besser. Trotzdem sollten Administratoren an der ein oder anderen Stelle nochmal Hand anlegen. Weiterhin zeigt die Erfahrung, dass die meisten Sicherheitsrisiken die auf einem Client existieren nicht über GPOs behoben werden können. Daher bilden die Security Baseline eine gute Basis, sollten aber nicht für sich alleine verwendet werden. Stattdessen ist ein individueller Blick auf die Clients notwendig, damit auch andere Sicherheitslücken abseits von GPO-Einstellungen gefunden und behoben werden können.

Wie immer gilt falls ihr Fragen, Anmerkungen oder Verbesserungsvorschläge zu dem Artikel habt, schreibt eine Mail an info@hackmich.net.

Weitere Hardening Guideline

Hier noch eine Zusammenstellung weitere Hardening Guidelines in deutscher und englischer Sprache: