Teil 3: Risiken bei NTML und was man dagegen tun kann

Beim Thema „Pass the Hash“ sollte man sich unbedingt in Erinnerung rufen, dass die im Speicher abgelegten (und von Hackern entwendeten) Passwort-Hashes aufgrund von Single Sign On’s existieren. Die meisten Organisationen wollen nicht auf ihr SSO-System verzichten und nehmen daher die bereits in den vorigen Beiträgen (Teil 1, Teil 2) erläuterten PtH-Risiken in Kauf. Hier hatte ich beschrieben, wie man die Risiken zumindest mindern kann. Komplett ausschließen kann man sie nicht.

Und noch ein paar besorgniserregende Fakten mehr
Es gibt einen weiteren Punkt, den Sie definitiv berücksichtigen sollten. Authentifizierungs-Protokolle unter Windows, die Passwort-Hashes benutzen, haben eine lange Historie von Problemen. Seit Januar 2013 empfiehlt Microsoft daher, die erste Version von NTLM nicht mehr zu nutzen. Die empfohlene Nachfolgeversion weist zwar ebenfalls Schwachstellen auf, gilt jedoch im Allgemeinen als sicherer.

Daher sollten Sie sofern möglich von NTLM zu Kerboros wechseln. Damit würden sich die vorhandenen Sicherheitslücken erheblich reduzieren. Das Problem dabei: Viele IT-Gruppen und Bereiche können nicht von jetzt auf gleich ihre NTLM-Verbindungen kappen – denn etliche ihrer Client-Anwendungen (E-Mail, Browser, VPN, Filesharing) funktionieren nur im Zusammenspiel mit NTLM. Und dann gibt es noch SAMBA. Eine Suite, welche Windows-Fileservices und Druckerdienste auch unter UNIX und Linux-Systemen ermöglicht und ebenfalls NTLM verwendet.

Unser vorläufiger Fazit lautet also: NTLM ist tief in Windows verankert.

Noch beunruhigender – dieses Wissen verdanke ich IT-Sicherheits-Blogger Mark Gamache – ist, dass auf allen Windows XP-Systemen ein enormes Sicherheitsrisiko existiert – mindestens 20 Prozent aller Computer basieren auf W3-Daten. Deren Standardauthentifizierung ist – Sie ahnen es – die erste Version von NTLM.

Ein wenig über NTLM
Um die Problematik von NTLM zu verstehen, müssen wir uns ein wenig mehr mit dem hier genutzten Challenge-Response Modell beschäftigen.

Um die Auflistung eines ewig langen Syntax-Protokolls zu vermeiden, fassen wir die Interaktion von NTLM 1 einfach als kleinen Dialog zusammen:

Server: Hallo. Sie behaupten Nutzer XYZ zu sein, aber Sie müssen sich verifizieren. Doch Vorsicht – sagen Sie mir Ihr Passwort nicht laut, schließlich könnte uns jemand belauschen! Stattdessen erfüllen Sie bitte die folgende Aufgabe: Verschlüsseln Sie das Wort “Schwertfisch” und teilen Sie mir dann Ihr Ergebnis mit. Dazu können Sie den DES (Data Encryption Standard) verwenden.

Nutzer: Und welchen Schlüssel soll ich für DES benutzen?

Server: Nutzen Sie den MD4-Hash ihres Passworts.

Nutzer: Okay, ich habe “Schwertfisch” mit dem Passwort-Hash verschlüsselt und habe nun einen seltsamen 24-Byte-String heraus bekommen. Ist es das, was Sie wollen?

Server: Ja.

Der Nutzer übermittelt den verschlüsselten String an den Server. Der Server vergleicht diesen anschließend mit seiner Verschlüsselung von Schwertfisch. Im Erfolgsfall stimmen beide Versionen überein.

Server: Alles in Ordnung. Treten Sie ein.

Die wichtigste Neuerung bei NTLMv1gegenüber noch älteren Versionen von Windows-Authentifizierungsmethoden ist, dass das Kennwort nur indirekt übertragen wird. Der Hash des Passwortes genügt, um den jeweiligen Nutzer zu identifizieren.

Die erste NTLM-Version stammt noch aus der Zeit als NT-Systeme noch nicht mit dem Internet verbunden waren. NTLM ist seit damals die Kurzform für NT LAN Manager.

Zu Beginn der 90er Jahre ging man noch nicht unbedingt davon aus, dass sich jemand in das LAN-Netzwerk eines Büros einhacken oder einen Man-in-the-Middle-Angriff durchführen würde. Eine vergleichsweise unschuldige Zeit also, weswegen auch noch keine entsprechenden Vorsichtsmaßnahmen durchgeführt wurden.

Doch mit der Zeit wurde NTLMv anfällig für die Art von Angriff, bei dem die Nutzer auf einen bösartigen Server umgeleitet werden. Hier finden Sie einen ausführlichen Artikel rund um dieses Thema. Dieser Server sendet eine Anfrage an den Nutzer und hat bereits im Voraus mehrere Millionen Passwort-Hashes berechnet und sie in einer gigantischen Datenbank gespeichert. Sobald der Fake-Server dann einen Match mit seiner Datenbank feststellt, hat dieser automatisch den richtigen Passwort-Hash für den jeweiligen Nutzer parat.

NTLM ist tatsächlich anfällig
Microsofts reagierte und verbesserte das Challenge-Response-Protokoll in NTLMv2, um solche serverbasierten Datenbank-Attacken zu vermeiden. Dennoch verblieb eine Sicherheitslücke mit der PtH und man-in-the-middle Exploits weiterhin genutzt werden konnten.

Bis vor kurzem existierte dennoch ein Grund, Version 1 von NTLM zu nutzen:

Im Jahr 2012 machte auf der Defcon eine erstaunliche Nachricht die Runde. Mit speziell auf diesen Zweck ausgerichteter Hardware konnten IT-Sicherheitsforscher die DES-Verschlüsselung des im NTLMv1genutzten Challenge-Response-Austausch knacken.

Mit anderen Worten: Die Forscher beobachteten die Aktivitäten innerhalb der jeweiligen Infrastruktur und fassten sowohl die Pakete der Server-Passwortabfragen als auch die verschlüsselten DES-Antworten ab. Mit Brute-Force-Angriffen konnten Hacker anschließend den passenden Schlüssel finden – beispielsweise den dem Passwort zugeordneten Hashwert. Die Forscher stellten danach einen auf der DES-Verwundbarkeit basierenden Service (CloudCracker) für Penetrationstester zur Verfügung.

Ich möchte an dieser Stelle nicht mehr viele Worte über diesen schwerwiegenden Fehler in NTLMv1 verlieren. Zusammengefasst: NTLMv1 schöpft die Möglichkeiten der vollen 128-Bit-Ausgabe des MD4-Hash als DES-Schlüssel nicht aus. Stattdessen nutzt es niedrigere 56-Bit-Gruppierungen; dadurch kann die Client-Antwort bei einem Leak mithilfe eines leistungsfähigen Computers geknackt werden kann. NTLMv2 benutzt mittlerweile den vollständigen 128-Bit-Schlüssel.

Und zukünftig?
Diese Krypto-News hat schließlich auch Microsoft vernommen. Und daraufhin (wie bereits erwähnt) eine Warnung zu NTLMv1 veröffentlicht.

Was ist also der nächste sinnvolle Schritt? Die erste Maßnahme der IT sollte sein, aktuelle LAN-Authentifizierungsstufen (GPO oder lokale Sicherheitsrichtlinien) zu prüfen. Es ist nicht ungewöhnlich, NTLMv2 zwar als Standard festgelegt zu haben, aber immer noch mit älteren LM zu interagieren. Wenn es umsetzbar ist, sollten Sie die Interaktionen mit LM und NTLM in den Netzwerksicherheitseinstellungen unterbinden.

NTLMv2 ist – soweit wir wissen und vorausgesetzt, Sie arbeiten nicht mit der NSA zusammen – immun gegen das sogenannte DES-Cracking. Der Nachteil ist, dass Benutzer-Passwörter mindestens 8 Zeichen lang sein müssen. Sonst ist auch die neue Version anfällig für Brute-Force-DES-Angriffe. Es ist innerhalb des eigenen Unternehmens unbedingt notwendig eine strikte Passwort-Politik durchzusetzen.

Das Challenge-Response-Protokoll von NTLMv2 kann dennoch von Servern ausgetrickst werden und sich zwischen dem Client und dem eigentlichem Server platzieren. Auch die zweite Version von NTLM nutzt nicht alle Möglichkeiten, um PtH-Angriffe vollständig zu unterbinden. Eine simple Faustregel sollten Sie sich daher unbedingt merken: Gehen Sie immer davon aus, dass der Hacker es in ihr System schafft.

Dementsprechend benötigen Sie einen sinnvollen „Plan B“ als Verteidigungsstrategie. In meinem vorigen PtH-Artikel hatte ich empfohlen die Option Remote-Zugriff für den normalen Benutzer zu deaktivieren. Das verhindert, dass Hacker ohne weiteres von einem System zum anderen gelangen. Das ist auch hier sinnvoll. Ihre letzte Verteidigungsmauer sollte eine standardmäßige Datenüberwachung sein, inklusive Alarmierungsfunktion. In der Metadaten-Ära ist es möglich, vertrauliche Daten zu finden und ihren rechtmäßigen Benutzern zuzuordnen. Stellen Sie sicher, dass Benutzer nur einen limitierten Zugang zu solchen Daten haben – und diesen auch tatsächlich aufgrund ihrer Position benötigen. Ein effektives Monitoring ist ein grundlegendes Feature, das Sie nutzen sollten. Verschafft sich ein Hacker Zutritt, kann er zumindest nicht auf alle Daten zugreifen, und er hat es deutlich schwerer, sensible Daten abzuziehen. Dafür sorgt der limitierte Zugriff.

The post „Pass the Hash“-Angriffe genauer betrachtet, Teil 3 appeared first on Varonis Deutsch.