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.
- Cain & Abel
https://de.wikipedia.org/wiki/Cain_%26_Abel
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
https://en.wikipedia.org/wiki/NTLMv2 - Challenge–response authentication
https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication - CRAM-MD5 Anmeldung z.B.: bei SMTP/POP
ist ähnlich
https://en.wikipedia.org/wiki/CRAM-MD5
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.
- CVE-2024-21410
- Windows Security Changes 2023
- Alte Clients Windows 2008
- Alte Clients Windows XP
- NTLM MITM mit Edge / PIKABOT
- Netzwerksicherheit: LAN Manager-Authentifizierungsebene
https://learn.microsoft.com/de-de/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level - The worst of both worlds: Combining NTLM Relaying and
Kerberos delegation
https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/ - c:\rusher I have Trust issues. Somewhere in your forest:
Combining NTLM Relaying and Kerberos delegation
https://chryzsh.github.io/relaying-delegation/
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 .
- Kerberos
- Kerberos RC4 Abschaltung
- Kerberos Encryption
- Kerberos
https://it-forensik.fiw.hs-wismar.de/index.php/Kerberos
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
-
Checkliste
Active Directory Absicherung
Keine Liste ist komplett aber fangen Sie heute an und hören sie nie auf - CVE-2024-21410 Betrachtung
- NTLM MITM mit Edge / PIKABOT
- Exchange Extended Protection
- IIS Extended Protection
- Authentifizierung im Wandel der Zeit
- Warum Kerberos besser ist
-
Active Directory Hardening
Series - Part 1 – Disabling
NTLMv1
https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/active-directory-hardening-series-part-1-disabling-ntlmv1/ba-p/3934787 -
How to Disable NTLM
Authentication in Windows Domain
https://woshub.com/disable-ntlm-authentication-windows/ -
The evolution of Windows authentication
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/the-evolution-of-windows-authentication/ba-p/3926848 - NTLM Overview
https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview - Challenge-Response-Authentifizierung
https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication
https://de.wikipedia.org/wiki/Challenge-Response-Authentifizierung - NTLM
https://de.wikipedia.org/wiki/NTLM - CRAM-MD5 Anmeldung z.B.: bei SMTP/POP ist ähnlich
https://en.wikipedia.org/wiki/CRAM-MD5 - NTLM v1 and NTLM v2 vs Kerberos
https://www.calcomsoftware.com/ntlm-v1-and-v2-vs-kerberos/