NTLM-Anmeldung

Im Zuge der CVE-2024-21410 Betrachtung ist immer wieder die Frage aufgekommen, wie NTLM eigentlich die Anmeldung erreicht, ohne ein Kennwort zu übertragen und wie das mit anderen Anmeldeverfahren ist. Auf dieser Seite versuche ich neben NTLM auch den Vergleich zu anderen Verfahren zu ziehen, mit denen sich Client bei Servern anmelden können.

Hinweis: NTLMv1 ist unsicher und NTLMv2 ist ohne weiteren Schutz durch Main in the Middle-Attacken gefährdet. Siehe dazu auch NTLM MITM mit Edge / PIKABOT

Microsoft wird NTLM ab Windows 2025 als "depreciated" einstufen und alle davon abhängigen Dienste umstellen. Kerberos oder OAUTH ist die Zukunft, da hier der Authentifizierungsdienst schon prüft, ob ein Token ausgestellt werden muss. Bei NTLM ist der Benutzer immer authentifiziert ehe dann erst auf dem Server selbst geprüft wird, welche Berechtigungen genutzt werden.
The evolution of Windows authentication https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848

Basic Auth

Schon bei meinen ersten Gehversuchen an Servern (DEC PDP-11, DEC VAX u.a.) musste man sich anmelden. Damals wurden Tastatureingaben über einfache serielle Leitungen (RS.232/V.24) übertragen. Das war nicht sicher aber mangels interner war das Angriffsszenario überschaubar. Später wurden die Ein/Ausgaben bei "TELNET"-Verbindungen über TCP/IP zeichenweise ebenso unverschlüsselt übermittelt. Was heute undenkbar scheint, ist leider noch viel zu häufig der Fall.

Wenn Sie in einem Browser ein Anmeldeformular ausfüllen, dann war da lange Zeit nicht verschlüsselt und selbst heute sollten Sie genau hinschauen, wie die Daten gesendet werden. Auch bei einer Anmeldung durch ein Fenster des Browsers werden die Daten oft mit "BasicAuth" übertragen, was nicht mehr als eine Codierung von Benutzername und Kennwort durch das BASE64-Verfahren darstellt. So können auch Sonderzeichen übertragen werden. Sicher ist dies aber auch nicht.

Eine Verschlüsselung per TLS verhindert einen direkte Einblick eines Angreifers aber wenn sie nicht mindestens TLS 1.2 mit entsprechenden Schlüsseln verwenden, ist auch diese Verbindung zu knacken. Wenn der Angreifer sich aber direkt in die Verbindung als Proxy einschleifen kann, weil sie z.B. auf einem PC in einem Internet Cafe arbeiten, dann kann er die Daten einfach abgreifen. Ähnliche Probleme finden sich bei Anmeldungen per FTP, SMB, POP3, IMAP4 und vielen anderen Protokollen. Das ist "kinderleicht", wie z.B. das Programm "Cain&Abel" früher einfach aufgezeigt hat.

LM, NTLM, NTLMv2

Microsoft hat schon sehr früh neue Wege gesucht, wie ein Anwender sich sicherer anmelden kann und dabei sind Protokolle wie LM, NTLM, NTLMv2 herausgekommen. Aus heutiger Sicht kann man schreiben, dass LM und NTLM als unsicher gelten und Sie mindestens NTLMv2 einsetzen sollten. Dies kann und sollte über Gruppenrichtlinien auf dem Server und Client vorgegeben werden.

Damit ist aber immer noch nicht beantwortet, wie NTLM eine Anmeldung schafft, ohne das Kennwort zu übertragen. Das Verfahren basiert darauf, dass beide Seiten schon ein gemeinsames Wissen haben und niemand Kennwort im Klartext speichern sollte. Wenn ein Konto angelegt wird, wird auch ein Kennwort gesetzt. Der Windows Server stellt aus dem Kennwort einen Hashwert und speichert diesen ab. Wenn der Anwender nun auf seinem Computer eine Anmeldung durchführt, dann gibt er sein Kennwort ein, welches auch der Client mit dem gleichen Hashverfahren wandelt. Bislang ist noch kein Paket über das Netzwerk gegangen. Erst wenn ich z.B. einen Zugriff auf einen Dateishare starte, sehe ich z.B. in WireShark einen ersten Handshake.

Die ersten 6 Pakete zwischen Client und Server dienen der Aushandlung der nutzbaren Protokolle. Ein Client wird aus Kompatibilitätsgründen erst einmal eine alte Version des Handshake verwenden und erst wenn der Server mit einer "neuen Version" antwortet, seinerseits einen moderneren Handshake wählen. hier das erste Paket und die Antwort:

In dem nächsten Paket des Clients und der Antwort des Servers geht es schon mehr zur Sache:

Das sind aber immer noch Vorklärungen und noch keine Anmeldung. Die kommt erst in Paket 36,37,38,40.

Der Client sendet einen "NTLMSSP_NEGOTIATE", auf den der Server aber mit einem "ERROR" antwortet, denn der Client hatte ja noch keine Information zu verschlüsseln. Im Paket 37 sendet der Server einen NTLMSSP_CHALLENGE an den Client.

Dieser Challenge ist quasi eine Zufallszahl, die der Server kennt und auch gerne ein Angreifer mitschreiben darf.

Dieser Wert wird nun vom Client mit dem Hashwert des Kennworts verschlüsselt und zurückgesendet. Auch das könnte der Angreifer noch mitlesen, da er aber das Kennwort und den Hashwert nicht kennt, müsste er nun mit viel Aufwand die vom Server gesendete Zahl mit sehr vielen Kennworten nachrechnen bis er eine Übereinstimmung. Mit entsprechenden Schlüssellängen, Zeitintensiven Verschlüsselungsfunktionen, die der Client ja nur einmal machen muss, treiben den Aufwand beim Angreifer für solche Brute-Force Attacken nach oben.

Der angesprochene Server kennt aber nicht nur den gesendeten Zufallswert und das zurückerhaltene Ergebnis sondern natürlich auch den Hashwert aus der lokalen Benutzerdatenbank. Nutzt der Server eine "Domain", dann gibt er den Challenge und den Response einfach an den Domaincontroller, der mit dem dort gespeicherten Kennwort-Hashwert die Rechnung prüfen kann.

Wenn alles passt dann hat der Server die Anmeldung des Clients erfolgreich prüfen können ohne dass das eigentliche Kennwort oder auch nur der Hashwert des Kennworts über die Leitung gegangen ist.

Sie können nun aber abschätzen, wie wichtig die Userdatenbank mit den Hashwerten ist. Kommt ihnen diese Abhanden, weil an Angreifer ein Backup-Band des DCs oder einen VM-Snapshot bekommen hat und sind die Daten nicht z.B.: per Bitlocker verschlüsselt, dann kann er sehr wohl per Rainbow-Table passende Kennworte suchen.

NTLM und MITM

Damit stellt sich natürlich die Frage, was dann bei CVE-2024-21410 schief gegangen ist. Was ich bisher zu NTLM beschrieben habe ist nur die erstmalige Anmeldung. Für die folgende Zugriffe werden weitere Daten ausgetauscht und am Ende kommt ein Hashwert für Folgezugriffe zum Einsatz. Diese Beschreibung bleibt hier absichtlich "vereinfachend". Denken Sie einfach an einen Browser, der sich am an einer Webseite anmeldet. Bei nachfolgenden Zugriffen wird auch nicht unbedingt immer wieder das Kennwort übertragen, sondern der Server stellt eine zeitlich beschränkte Information an den Client, die dieser beim nächsten Request wieder zurücksendet. Bei HTTP sind das dann Cookies oder Session-Tokens, die zeitlich beschränkt gültig sind und damit quasi eine Abmeldung bei Inaktivität erfolgt.

Bei CVE-2024-21410 ist es nun passiert, dass der Angreifer einen Anwender zu seinem Service gelockt hat und natürlich NTLM angeboten hat. Allerdings hat der Angreifer alle Anfragen des Clients zum Server dahinter gesendet und quasi alles "mitbekommen". Der Fehler lag daran, dass der Client nicht geprüft hat, ob er wirklich mit dem gewünschten Server spricht. Die Anfrage an den Server ging über den Angreifer, der die Anmeldeaufforderung einfach durch den Client "lösen" ließ und danach sich das Session-Ticket abgegriffen hat.

Die Lösung besteht darin, dass man sich nicht auf die TLS-Sicherheit und den Hashwert des Kennworts alleine verlässt, sondern externe Informationen mit einbezieht. IIS Extended Protection nutzt dazu das Zertifikat des Webservers, der die Authentifizierungsdaten empfängt, während der Client das Zertifikat nutzt, welches er von seiner Gegenstelle bekommen hat. Wenn Client und Server direkt miteinander sprechend, dann nutzen beide die gleiche Information und die Anmeldung funktioniert.

Wenn aber ein Angreifer als "Man in the Middle" die Pakete umsetzt, dann muss dieser die TLS-Verbindung aufbrechen. Damit sieht der Client ein anderes Zertifikat, als der Server nutzt und damit funktioniert die Anwendung nicht mehr, wenn jemand die Verbindung derart aufbricht. Allerdings funktioniert dann erst einmal auch keine eigene gewünschte TLS-Inspection durch eine Web Application Firewall oder einen Loadbalancer. Als Firma müssen Sie beim Einsatz solcher Systeme darauf achten, dass das der Client das gleiche Zertifikat bekommt, welche auch der Webserver nutzt, der die Anmeldung durchführt.

Die Funktion "IIS Extended Protection" steht nicht allein. Auch Paket können und sollten gegen Änderungen geschützt werden. Daher gibt es auch "PAC Signing", "RPC Sealing", "LDAP Signing" und mehr.

Aber auch hier gilt: Irgendwann findet vielleicht wieder jemand eine Schwäche in der Umsetzung oder des Protokolls.

Viele Netzwerke und Server sind aber unsicherer, weil als Protokolle wie SMB1 immer noch aktiv sind, weil es vielleicht noch aus Kompatibilitätsgründen irgendwo genutzt werden könnte. Hier sind Sie gefordert schon früher die unterste Schwelle anzuheben und nicht darauf zu warten, dass Microsoft mit einer neuen Version ihnen dies abnimmt.

Sie sollten den "LmCompatibilityLevel Settings" mindestens auf 3 "Nur NTLMv2-Antwort senden" stellen.

Kerberos

Ähnliche Techniken kommen auch bei Kerberos zum Einsatz. Ich habe dazu auf Kerberos eine ganze Serie von Seiten geschrieben. Daher hier eine Kurzfassung.

Ein Client meldet sich "sicher" an und bekommt ein "Ticket Granting Ticket" (TGT), mit dem er sich neue Tickets ausstellen kann. Das Ticket ist zeitlich beschränkt aber auch vom Domain Controller digital signiert. Hier gäbe es noch viel mehr z zu erzählen aber interessanter ist der Zugriff auf einen Server. Der Client greift auf den Server zu , der wieder mit einem "Anonym verboten, bitte mit Kerberos anmelden" antwortet. Hier könnte sich natürlich ein Angreifer einschleifen. Der Client geht aber nun über die gesicherte Verbindung zu einem Domain Controller, um sich ein Serviceticket für den Server mit seinem TGT zu besorgen.

Der Domaincontroller stellt vereinfacht gesagt ein Ticket für den Anwender aus, welches nur auf dem Zielserver gültig ist. Dazu Ticket wird ebenfalls digital signiert und zudem mit dem Schlüsselmaterial des Zielservers, welches bei der Aufnahme des Servers in die Domain im Active Directory gelandet ist, verschlüsselt. Der Zielserver ist damit er einzige Server, der dieses TGS wieder decodieren und das Schlüsselmaterial nutzen kann. Natürlich sind dort auch noch Informationen enthalten, die nur der Client hat. Selbst ein Angreifer dazwischen kann diese Daten eigentlich nicht erhalten.

Ich habe absichtlich "eigentlich" geschrieben, denn natürlich hat die ein oder andere Implementierung Schwächen. Kerberos wurde schon 1978 durch Steven Miller und Clifford Neumann entwickelt und damals war Rechenleistung beschränkt. Daher wurden zuerst vermeintlich gute Verfahren wie DES und RC4 genutzt, die mit der heutigen Rechenleistung nicht mehr als sicher gelten.

Daher ist DES seit Windows 7 per Default deaktiviert aber RC4 noch möglich. Durch die Einführung der Windows Security Changes 2023 wurde nicht nur AES zum neuen Standard sondern auch PAC Signing umgesetzt. Die Kerberos RC4 Abschaltung wird von Microsoft sicher irgendwann in der Zukunft aktiviert. Aber Sie können dies auch heute schon machen .

SAML/OAUTH

In der Cloud gibt es wieder eine neue Variante. Wobei Sie so neu gar nicht ist, denn mit einem Browser melden Sie sich eigentlich klassisch in einem "Web Formular" an. Wenn hier ein Angreifer als Proxy "dazwischen" hängt, kann er ihre Anmeldedaten natürlich sehen. Daher ist hier 2FA so wichtig, damit der Angreifer erst einmal mit den Anmeldedaten nichts anfangen kann. Das ist aber auch ein deutlicher Fingerzeig, dass Sie die gleichen Anmeldedaten nicht bei verschiedenen Diensten nutzen sollten.

Sobald der Anwender aber angemeldet ist, stellt auch der Service ein Bearer-Token aus, welches möglichst sicher vom Authentifizierungsserver (login.microsoftonline.com) zum Client übertragen werden muss. Auch hier vertrauen viele Dienste auf TLS als Transportverschlüsselung aber übersehen dabei, dass ein Angreifer als Proxy dies natürlich mitlesen kann.

Solange ich mit Fiddler auf einem PC die TLS-Kommunikation eines anderen Clients mitschneiden und decodieren kann und das Bearer-Token extrahieren kann, gehe ich davon aus, dass dies auch ein Angreifer kann.

IIS Extended Protection funktioniert nur mit der "Windows Integrated Authentication". Ich könnte mir aber vorstellen, dass immer mehr Webseiten z.B. auf dem Client ebenfalls per JavaScript hier die Daten des Zertifikats einbeziehen. Das Problem dabei ist natürlich, dass ein Angreifer auch das JavaScript beim Download verändern könnte. "Modern Apps" sind ja nicht klassische lokal installiert, sondern laden Code von Webseiten herunter. Hier könnte eine digitale Signierung des Code helfen, um den Aufwand für Angreifer zu erhöhen. Wenn der Browser entsprechende lokale APIs anbieten würde, könnte das ein Sicherheitsgewinn sein. Zumindest wenn der Angreifer nicht ihr eigener Dienstleister oder Betreiber des Internet Cafe ist.

NTLM abschalten/einschränken/sichern

Siehe dazu die eigene Seite NTLM Deaktivierung

Weitere Links