Seit Jahrzehnten geistern Lan Manager (LM), New Technology Lan Manager (NTLM) und NTLMv2 durch die Netzwerke. Und schon seit langer Zeit sind sie nicht mehr sicher. Zeit, sie endgültig loszuwerden. Aber schauen wir uns erst einmal an, wie lange das Thema schon existiert.
Der Lan Manager stammt noch aus der OS/2-Welt, die Authentifizierung wurde mit der Version 1.0 im Jahr 1987 veröffentlicht. Wer wissen möchte, wie (schlecht) der Algorithmus wirklich ist, dem empfehle ich einen Blick in den entsprechenden Wikipedia-Artikel.
NTLM wurde 1993 zusammen mit Windows NT 3.5 veröffentlicht. Mehr zu den Besonderheiten dieses fernen Vorfahren der aktuellen Windows-Versionen findet sich ebenfalls bei Wikipedia.
Um einige Sicherheitslücken in NTLM zu schließen, wurde später NTLMv2 entwickelt. Dies wird seit Windows NT 4.0 SP4 (21.10.1998) unterstützt, also kurz nach meinem Abitur…
Mit Windows 2000 wurde dann am 15.12.1999 Kerberos eingeführt. Leider findet man auch heute noch viele Umgebungen mit aktivem LM, NTLM und NTLMv2, aber das möchte ich mit dieser Artikelserie ändern.
Bekannte Probleme, warum LM / NTLM noch nicht vollständig abgeschaltet ist
In vielen Umgebungen sind es nicht nur inkompatible Programme, die das Deaktivieren von NTLM verhindern. Manchmal sind es auch einfach ungünstige Konfigurationen. So unterstützt Kerberos erst seit Windows Server 2016 bzw. Windows 10 1507 auch die Authentifizierung über IP-Adressen, dazu später mehr. Das erfordert aber manuelle Arbeit, normalerweise wird beim Zugriff über eine IP-Adresse NTLM verwendet. Wenn also auf einen Server mit der IP-Adresse statt mit dem Hostnamen oder dem vollständigen DNS-Namen zugegriffen wird, wird NTLM verwendet. Gleiches gilt, wenn kein passender SPN vorhanden ist, z. B. bei der Verwendung von DNS-Aliasen, z. B. bei Rechnern mit mehreren IP-Adressen und entsprechenden DNS-Aliasen.
Auch von außerhalb des AD kann es zu Problemen kommen, da auch hier nicht immer Kerberos verwendet werden kann. Zum Beispiel bei einer RDP-Verbindung mit aktivierter „Network Level Authentication“ (NLA) von einem Rechner außerhalb der Domäne. Hier hilft nur ein RDP Connection Gateway oder ein vorgeschalteter Loadbalancer mit entsprechenden Authentifizierungsmöglichkeiten.
Darüber hinaus müssen ggf. noch Webseiten bzw. Webdienste, die den IIS nutzen, entsprechend umgestellt bzw. konfiguriert werden, wenn NTLM nicht mehr genutzt werden soll. Davon ist z.B. auch das Webinterface des Microsoft Active Directory Certificate Service (MS ADCS) betroffen, Microsoft hat hierzu den KB5005413 „Mitigating NTLM Relay Attacks on Active Directory Certificate Services (AD CS)“ veröffentlicht. Und auch Microsoft Exchange benötigt je nach Konfiguration etwas Hilfe bei Kerberos, z.B. bei der „Kerberos-Authentifizierung für Clientzugriffsdienste mit Lastenausgleich„. Im Zusammenhang mit Webservices kann es sein, dass auch in den Browsern etwas konfiguriert werden muss.
Es gibt auch einzelne Anwendungen und Appliances, die Kerberos noch nicht vollständig unterstützen. Zum Beispiel die CheckPoint Firewall in bestimmten Versionen (Stand 20.12.2022).
Warum Abschalten?
Wem das Alter in der Einleitung noch nicht als Begründung gereicht hat, hier noch ein paar Gründe:
- Es gibt mehr Angriffsvektoren, als ich hier aufzählen möchte, da ich keinen abschließenden Überblick über die Anzahl habe.
- Einen guten Überblick über die Möglichkeiten und verschiedene Angriffsvektoren findet man unter NTLM – The Hacker Recipes (engl.).
- Wenn man Begriffe wie „Pass-the-Hash“ oder „mimikatz“ hört, dann geht es meistens um LM/NTLM/NTLMv2.
- Microsoft plant, NTLM mit Windows 11 abzuschaffen. Siehe: The evolution of Windows authentication | Windows IT Pro Blog (microsoft.com)
- Mit der Einführung von NIS2 gewinnt das Thema IT-Grundschutz in Deutschland zunehmend an Bedeutung.
Das BSI behandelt das Thema auch im IT-Grundschutz€ Baustein APP.2.2 Active Directory Domain Service, genauer in der Maßnahme APP.2.2.A9 (Standardanforderungen) „Schutz der Authentisierung bei der Verwendung von AD DS (S)“. Die Zusammenfassung: Alles sollte Kerberos sein, wenn das noch nicht möglich ist, Umstellung planen und bis dahin nur NTLMv2 verwenden. Dies findet sich auch im Modul SYS.2.2.3.A9 (Standardanforderungen) „Sichere zentrale Authentisierung in Windows-Netzwerken (D)“ wieder.
Wer sich noch einmal aus technischer Sicht mit NTLM beschäftigen möchte, dem empfehle ich einen Blick in die Protokollspezifikation bei Microsoft [MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol | Microsoft Learn.
Erkennen von der Benutzung von NTLM
Bevor NTLM abgeschaltet werden kann, sollte zunächst geprüft werden, wo es noch verwendet wird. Dazu muss per Gruppenrichtlinie das Auditing aktiviert werden.
Dazu müssen unter „Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Local Policies \ Security Options“ folgende Policies gesetzt werden:
- Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers => „Audit all“
- 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“
Letzteres reicht auf den Domänencontrollern aus, aber dann hat man unter Umständen keine Logeinträge bei direkter Nutzung zwischen zwei Systemen, z.B. bei lokalen Accounts. Mit der Einstellung auf Domänenebene ist man auf der sicheren Seite, hat aber mehr zu analysieren.
Damit die Ereignisse generiert werden, muss jedoch noch das allgemeine Logon Auditing aktiviert werden. Dies findet sich unter: „Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Local Policies \ Audit Policy \Audit account logon events“. Ich empfehle hier beide Einstellungen, Success und Failure, zu setzen.
Und da bei Microsoft oft eine Einstellung nicht ausreicht, muss man auch noch unter “Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Advanced Audit Policy \ Audit Policies \ Logon/Logoff \ Audit Logon“ setzen. Ich empfehle hier beide Einstellungen, Success und Failure, zu setzen.
Dabei sollte auch die Größe des Security Event Log auf die maximale Größe für das jeweilige Betriebssystem erhöht werden.
Der Bereich der Local Policies hat seinen Ursprung übrigens noch in der Zeit von Windows NT, damals war es z.B. die SecPol.inf, in die diese Einstellungen exportiert wurden. Heute haben die Local Policies aber immer noch eine Bedeutung und werden auch gelegentlich erweitert. Die automatisierte Steuerung bzw. Verarbeitung z.B. als Teil eines GPO mit PowerShell ist nicht ganz einfach.
Das entsprechende Ereignisprotokoll finden Sie unter „Event Viewer \ Applications and Services Logs \ Microsoft \ Windows \ NTLM \ Operational“
Hier ein Beispiel mit RDP über die IP-Adresse um NTLM zu erzwingen.
Zusätzlich ist auch ein Blick in das Security Eventlog interessant, hier ist besonders die Event-ID 4776 interessant, diese wird bei NTLM Anmeldungen erzeugt.
Aber auch das Standard Logon Event 4624 enthält eine Information, wenn NTLM verwendet wurde. Es gibt jedoch sehr viele solcher Ereignisse im Log.
Natürlich müssen diese Ereignisse auf allen Domänencontrollern in der Umgebung überprüft werden.
Dies ist mit der PowerShell etwas einfacher:
Get-WinEvent -LogName "Security" -MaxEvents 10000 -FilterXPath "*[System[EventID=4624]]" | Where-Object -Property Message -match "NtLmSsp"
Get-EventLog "Security" -ComputerName IFH-DC01 -InstanceId 4624 -Newest 5 -Message "*NtLmSsp*"
Die Umschaltung auf NTLMv2
Um etwas Sicherheit zu gewinnen, bis NTLM komplett abgeschaltet werden kann, sollte NTLMv2 erzwungen werden. Dies kann über Gruppenrichtlinien erfolgen. Die notwendige Richtlinie findet sich unter „Computer Configuration“ > „Policies“ > „Windows Settings“ > „Security Settings“ >“Local Policies“ > „Security Options“ > „Network security: LAN Manager authentication level“ und wählen die Option „Send NTLMv2 response only. Refuse LM & NTLM“
Eigentlich sollten alle Produkte, die noch auf NTLM angewiesen sind, und sei es nur wegen fehlender Konfiguration, mit NTLMv2 zurechtkommen. Trotzdem empfehle ich, es vorher so gut wie möglich zu testen.
Wer bereits Systeme ausschließen kann, die NTLM definitiv nicht mehr benötigen, kann mit der gleichen Policy auch NTLM für diese Systeme abschalten.
Teilweise Abschaltung von NTLM
In den Gruppenrichtlinien Sicherheitsoptionen gibt es eine Einstellung „Network security: Restrict NTLM: Add remote server exceptions for NTLM authentication“, die leider beim ersten Versuch nicht funktionierte. Hier muss der Server mit NetBios-Name (auch wenn NetBios deaktiviert ist) und FQDN eingetragen werden. Zusätzlich muss die NTLM-Authentifizierung auf dem entsprechenden Server wieder erlaubt werden.
Leider gibt es auch hier Probleme, so dass eine genauere Analyse im Einzelfall erforderlich ist.
Warum wird noch NTLM noch benötigt?
Kerberos hat einige Besonderheiten, es benötigt Service Principal Names (SPN) zur Authentifizierung. Diese werden automatisch nur mit dem Hostnamen und dem FQDN erzeugt.
Daher kann Kerberos über IP derzeit nicht funktionieren. Aus diesem Grund werden die meisten Authentifizierungen über NTLM durch die Verwendung einer IP statt eines FQDN oder Hostnamens erzeugt. Dabei ist es egal, welches Microsoft-Protokoll verwendet wird, sobald z.B. mit Remote Desktop Protocol (RDP) oder Server Message Block (SMB) über eine IP statt über einen Hostnamen zugegriffen wird, wird NTLM zur Authentifizierung verwendet.
Der andere Grund ist, dass der Zugriff von außerhalb der Domäne erfolgt, dann können auch keine SPNs verwendet werden. Auch in diesem Fall wird bei Microsoft standardmäßig auf NTLM zurückgegriffen. Wer also das Remote Desktop Protokoll von einem Nicht-Domänenmitglied verwendet, verwendet NTLM. Hier gibt es noch die Möglichkeit, dies ggf. über ein RDP-Gateway zu adressieren.
Neues bei Kerberos und IP
Seit Windows Server 2016 und Windows 10 ab 1507 unterstützt Windows auch IPv4 und IPv6 Adressen in Service Principal Names (SPN). Leider nicht im Standard, es muss ein zusätzlicher Registry-Eintrag gesetzt werden. Der Befehl dazu lautet:
reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v TryIPSPN /t REG_DWORD /d 1 /f
Leider sorgt dieser Schlüssel nur dafür, dass bei einer IP-Adresse trotzdem Kerberos versucht wird. Der passende SPN wird aber leider nicht automatisch erzeugt, sondern muss manuell gesetzt werden. Dies ist mit einigem Aufwand verbunden, weshalb viele Firmen darauf verzichten und auf die Verwendung von Hostnamen oder FQDN verweisen.
Weitere Probleme mit der Abschaltung von NTLM
Auch einige Nicht-Microsoft-Anwendungen haben Probleme mit Kerberos und verwenden stattdessen NTLM.
So hat unter anderem CheckPoint noch bis 2023 Probleme mit Kerberos und nutzt stattdessen NTLM. Auch einige andere Linux Appliances haben hier Probleme.
Die Zukunft von NTLM
Microsoft hat angekündigt, wenn auch leider ohne genauen Zeitplan, NTLM in Zukunft zu deaktivieren und dann abzuschaffen. Microsoft möchte dabei einen „Data-Driven“-Ansatz verfolgen, d.h. eine Auswertung von Telemetrie-Informationen, wenn die Auswirkungen nicht zu groß sind. Meiner persönlichen Meinung nach ist es auch an der Zeit für eine Zwangsabschaltung. Am besten mit einem Termin für die Abschiedsfeier. Wer sich also wegen der vielen Sicherheitslücken und Angriffsvektoren nicht damit beschäftigen will, hat einen weiteren Grund, sich endgültig mit dem Thema zu beschäftigen.
