Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03305.jsonl.gz/291

Network Time Security
Michael Schneider
Darum sollte das Sicherheitsrisiko NTLM deaktiviert werden
Angreifer versuchen eine NLTM-Authentisierung eines Benutzers oder Maschine zu erzwingen, um diese für ihre Zwecke zu missbrauchen. Diese Technik wird als Coerced Authentication oder Forced Authentication bezeichnet. Der Missbrauch kann über direkte Anfragen oder indirekt über Machine-in-the-Middle-Angriffe (MitM) sowie ARP oder Multicast Poisoning bewerkstelligt werden. Das Tool Responder von Laurent Gaffie ist für die letztere Angriffstechnik ein beliebtes und zuverlässiges Werkzeug für Angreifer. Angreifer können die erzwungene NTLM-Authentisierung nutzen, um Zugangsdaten aus Challenge-Response-Hashes zu errechnen, oder diese an ein anderes System weiterzuleiten. Eine Übersicht über NTLM-Relay-Angriffe zeigt das Mindmap von Charlie Bromberg und diese werden unter der Seite NTLM-Relay-Angriffe dokumentiert.
NTLM stellt ein Sicherheitsrisiko in einer IT-Infrastruktur dar und sollte deaktiviert werden.
Das Protokoll NTLM ist eine Challenge-Response-Authentisierung und verwendet dazu verschiedene Protokolle. Der Begriff NTLM sollte nicht mit der Hashfunktion von Windows verwechselt werden. Windows speichert den Hash von Passwörtern lokal in der SAM Datenbank und auf Domain Controllern in der Datei ntds.dit und verwendet die Hashfunktion NTHash, welche den Algorithmus
MD4(UTF-16-LE(password)) nutzt. Der NTHash wird fälschlicherweise oft als NTLM bezeichnet.
NTLM setzt die folgenden Protokolle ein:
Die Funktionsweise der Protokolle werden im Artikel The NTLM Authentication Protocol and Security Support Provider ausführlich erklärt. NTLMv2 wird ab Windows NT 4.0 SP4 unterstützt. Seit Windows 2000 wird in einer Active-Directory-Infrastruktur das Protokoll Kerberos als primäre und bevorzugte Authentisierungsmethode eingesetzt. Aus Kompatibilitätsgründen ist NTLM jedoch in Windows 10 und Windows Server 2019 standardmässig aktiv. NTLM wird dann zur Authentisierung genutzt, wenn keine AD-Infrastruktur vorhanden ist, eine Authentisierung mit Systemen ausserhalb der Domäne stattfindet, Systeme über die IP-Adresse anstelle von Hostnamen oder DNS adressiert werden oder kein Domain Controller mittels Kerberos erreichbar ist.
Die Abwärtskompatibilität und der Fallback-Einsatz erschwert es NTLM zu deaktivieren. Es kann daher zu Ausfällen kommen, wenn NTLM ohne jegliche Vorabklärung auf allen Systemen deaktiviert wird. Der “Microsoft Veteran” und Principal Program Manager im Bereich Windows Server Engineering Ned Pyle schrieb bereits 2009 im TechNet-Artikel NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7, dass das Blocken von NTLM nicht einfach sei und dazu eine Analyse und längere Vorbereitung notwendig ist.
Es gibt drei Gruppenrichtlinien unter dem Pfad
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, und die empfohlene Einstellung um eine Analyse durchzuführen lautet:
|Einstellung||Wert|
|Network security: Restrict NTLM: Audit Incoming NTLM Traffic||Enable auditing for all accounts|
|Network security: Restrict NTLM: Audit NTLM authentication in this domain||Enable all|
|Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers||Audit all|
Die Richtlinie Audit NTLM authentication in this domain sollte nur auf Domain Controllern angewandt werden, die beiden Andern können auf allen Systemen appliziert werden. Die NTLM-Audit-Ereignisse werden in dem Event Log
Applications And Services Logs\Microsoft\Windows\NTLM\Operational protokolliert.
Alle Ereignisse werden idealerweise in einer zentralen Log-/Monitoring-Infrastruktur gesammelt und ausgewertet. Bei Splunk kann beispielsweise die SplunkForwarder-Konfiguration in
inputs.conf um den folgenden Eintrag erweitert werden:
[WinEvent Log://Microsoft-Windows-NTLM/Operational] checkpointInterval = 5 current_only = 0 disabled = 0 start_from = oldest
Das Ziel ist es zu identifizieren, welche Systeme NTLM zur Authentisierung nutzen. NTLM wird in verschiedenen Protokollen wie HTTP oder SMB eingesetzt. Mit dem folgenden Splunk Query kann eine Liste von IP-Adressen von Zielservern generiert werden:
source="winEvent Log*" "LogName=Microsoft-Windows-NTLM/Operational" | rex field=_raw "(?i)target\sserver:\s(?<IP>.*)" | dedup IP | table IP
Diese Liste dient als Startpunkt für die Analyse, welche Systeme und Applikationen NTLM einsetzen. Dazu werden die Logdaten von Clients und Server korreliert. In Ereignissen mit der Event ID
8003 werden auf Server die durchgeführte Authentisierung protokolliert, daraus kann der Benutzer, Domain und die Workstation ausgelesen werden. Gleichzeitig wird auf dem Client unter der Event ID
8001 die ausgehende Verbindung aufgezeichnet. Daraus kann im Falle von Applikationen, die nicht über das SMB-Protokoll kommunizieren, das Zielsystem (Target server) und der Prozess (Name of client process) ausgelesen werden.
Im folgende Beispiel greift der Benutzer jdoe auf eine Webapplikation mit aktivierter Windows Authentication per IP-Adresse zu:
Message=NTLM client blocked audit: Audit outgoing NTLM authentication traffic that would be blocked. Target server: HTTP/<ip-pii> Supplied user: jdoe Supplied domain: TEST PID of client process: 5780 Name of client process: C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe LUID of client process: 0xBE4B5 User identity of client process: jdoe Domain name of user identity of client process: TEST
Der Client
client01 baut eine Verbindung über die URL
https://<ip-pii> zum Webserver
web01 auf. Für den Zugriff ist eine Authentisierung notwendig und da die IP-Adresse verwendet wird, einigen sich Webserver und Browser auf das Protokoll NTLM. Der Benutzer gibt seine Domain-Zugangsdaten ein, der Webserver nimmt diese entgegen und validiert die Zugangsdaten mit der Hilfe eines Domain Controllers. Anhand der Analyse der Logs ist bekannt, dass auf dem Client eine ausgehende NTLM-Verbindung zu
<ip-pii> aufgebaut wird (Event ID
8001), auf dem Webserver die NTLM-Verbindung eingeht (Event ID
8002) und dieser die Prüfung der Zugangsdaten an einen DC weiterleitet (Event ID
8004).
Die Auditphase sollte über mehrere Monate fortgeführt werden. Innerhalb dieser Phase können bereits Logdaten analysiert und mögliche Fehlkonfigurationen behoben werden. Ein Beispiel für eine Fehlkonfiguration ist, dass der Zugriff über eine IP-Adresse anstelle des NetBIOS-Servernamen oder des vollqualifizierten Domänennamens (Fully qualified domain name, kurz FQDN) konfiguriert wurde.
Wenn die Anwendung oder der Dienst nur NTLM unterstützt, muss dies als Ausnahme erfasst werden. Das Ziel ist es jedoch so wenig Ausnahmen wie möglich zu haben.
Zum Abschluss der Auditphase sollte eine Ausnahmeliste vorliegen, die alle Systeme enthält, die eingehende NTLM-Verbindungen erhalten und von welchen Systemen der Zugriff möglich sein muss. Die Vollständigkeit der Liste ist essentiell für den Betrieb der Infrastruktur. Sobald NTLM blockiert wird, und ein System befindet sich nicht auf der Liste, wird diese Anwendung nicht mehr funktionieren.
Wenn NTLM geblockt wird, ist es auf einem System nicht vollständig deaktiviert, da der lokale Anmeldungsprozess weiterhin NTLM verwendet. Auch wenn NTLM blockiert wird, bleibt die Anmeldung mit einem lokalen Konto möglich.
Es gibt drei Gruppenrichtlinien für das Blocken von NTLM unter dem Pfad
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options, und die Einstellungen um NTLM vollständig zu blockieren lauten:
|Einstellung||Wert|
|Network security: Restrict NTLM: Incoming NTLM traffic||Deny all accounts|
|Network security: Restrict NTLM: NTLM authentication in this domain||Deny all|
|Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers||Deny all|
Die Einstellungen Incoming NTLM traffic und Outgoing NTLM traffic to remote servers können auf allen Systemen konfiguriert werden. Die Einstellung NTLM authentication in this domain ist für Domain Controller relevant.
Falls Ausnahmen für die Blockierung notwendig sind, stehen die Einstellungen unter dem Pfad
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options zur Verfügung:
Mit der Einstellung Add remote server exceptions for NTLM authentication wird definiert, auf welche Systeme ein Client sich weiterhin über NTLM authentisieren kann. Als gültige Werte werden der NetBIOS-Servername, FQDN und IP-Adressen akzeptiert. Die Liste der Systeme, die weiterhin NTLM-Anfragen entgegen nehmen und sich innerhalb der Domäne befinden, muss in die Einstellung Add server exceptions in this domain aufgenommen werden. Diese Einstellung wird auf Domain Controllern gepflegt.
In einer Umgebung soll NTLM geblockt werden. Grundsätzlich können ein- und ausgehende NTLM-Verbindungen auf allen Systemen einer Domäne blockiert werden. Auf den Domain Controllern wird die Verwendung von NTLM innerhalb der Domäne zusätzlich deaktiviert. Ebenso wird auf den Domain Controllern eine Ausnahmeliste gepflegt. Zusätzlich müssen ausgehende NTLM-Verbindungen als Ausnahme auf den betroffenen Systemen deklariert werden. Diese Liste sollte auf die Bedürfnisse aufgeteilt und nicht als Ganzes verteilt werden.
Als Ausnahme wurde eine Webapplikation definiert, die einen IIS-Webserver mit Windows Authentication einsetzt. Die Angaben der involvierten Systeme sind in der folgenden Tabelle aufgelistet. Der DC
dc01 steht exemplarisch für alle Domain Controller in der Domäne.
|Hostname||IP-Adresse|
|dc01||<ip-pii>|
|web01||<ip-pii>|
|client01||<ip-pii>|
Die Einschränkung Outgoing NTLM traffic to remote servers betrifft in diesem Beispiel nur
client01, da dort die ausgehende NTLM-Verbindung zu
web01 geblockt wird (Event ID 4001). Daher wird die IP-Adresse von
web01 in die Liste der Einstellung Add remote server exceptions for NTLM authentication aufgenommen. Idealerweise wird die Ausnahmeliste nur Clients zugewiesen, die den Zugriff auf die Webapplikation benötigen.
Da die Einstellung Incoming NTLM traffic auf den Wert Deny all accounts gesetzt wurde, wird die NTLM-Verbindung von
client01 zu
web01 auf dem Webserver geblockt (Event ID 4002). Gemäss der Dokumentation von Microsoft kann für Incoming NTLM traffic die Ausnahmenliste von Add server exceptions in this domain verwendet werden. Diese Ausnahme hatte in der Testumgebung jedoch nicht funktioniert, sodass die Einstellung Incoming NTLM traffic auf
web01 auf den Wert
Allow all konfiguriert werden musste.
Um NTLM innerhalb der Domain zu deaktivieren, wird die Einstellung NTLM authentication in this domain auf den Wert Deny all gesetzt. In diesem Beispiel wird daher die NTLM-Authentisierungsanfrage des Webservers auf dem DC geblockt (Event ID 4004). Daher wird
web01 in die Liste der Einstellung Add server exceptions in this domain aufgenommen. In der Testumgebung musste der NetBIOS-Servername eingetragen werden, wenn der FQDN verwendet wurde, hatte die Ausnahme nicht geklappt.
Die Konfiguration für die Systeme inklusive den Ausnahmen sieht wie folgt aus:
|Hostname||Einstellung||Wert|
|dc01||Incoming NTLM traffic||Deny all accounts|
|dc01||NTLM authentication in this domain||Deny all|
|dc01||Outgoing NTLM traffic to remote servers||Deny all|
|dc01||Add server exceptions in this domain||web01|
|web01||Incoming NTLM traffic||Allow All|
|web01||Outgoing NTLM traffic to remote servers||Deny all|
|client01||Incoming NTLM traffic||Deny all accounts|
|client01||Outgoing NTLM traffic to remote servers||Deny all|
|client01||Add remote server exceptions for NTLM authentication||<ip-pii>|
Das Authentisierungsprotokoll NTLM ist veraltet und unsicher und wurde durch Kerberos abgelöst. Seither wird NTLM aus Kompatibilitätsgründen weiter unterstützt und ist auch in der aktuellen Version von Windows noch aktiv. NTLM wird zudem für viele Angriffe missbraucht und erleichtert Angreifern eine Active-Directory-Infrastruktur zu kompromittieren.
Die Aufgabe NTLM zu blockieren muss in mehreren Schritten durchgeführt werden. Zuerst muss festgestellt werden, welche Systeme und Dienste NTLM noch nutzen. Dazu sollten die Audit-Einstellungen aktiviert und die Logs über Monate ausgewertet werden mit dem Ziel fehlerhafte Konfigurationen zu finden und die NTLM-Nutzung reduzieren zu können. Danach müssen die Ausnahmen definiert und die Konfiguration spezifiziert werden. Danach kann NTLM innerhalb der Domäne geblockt werden.
Die Hürde NTLM zu blockieren ist hoch, es ist keine einfache Aufgabe dies umzusetzen und das Risiko von Ausfällen besteht. Aber angesichts der vielen Angriffe und Schwachstellen in NTLM ist der Sicherheitsgewinn so gross, dass es sich lohnt das Projekt anzugehen. Es ist Zeit sich von NTLM zu verabschieden. Lebewohl.
Unsere Spezialisten kontaktieren Sie gern!
Michael Schneider
Michael Schneider
Michael Schneider
Michael Schneider
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv