Active Directory: Warum NTLMv1 unsicher ist

Das On-Premises Active Directory bietet zur Authentifizierung vereinfacht gesehen zwei unterschiedliche Standards an: Kerberos und NTLM. Wird aus Sicherheitsaspekten Kerberos grundsätzlich bevorzugt, ist eine Authentifizierung darüber aufgrund der komplexeren Voraussetzungen eben nicht immer möglich. In so einem Fall gibt es beim Authentifizierungsversuch einen Fallback auf das NTLM Protokoll. Wie es in der IT allerdings üblich ist, fallen mit der Zeit immer wieder Schwachstellen in verschiedenen Protokollen auf, welche durch Hersteller mit neuen Versionen gefixt werden. So eben auch bei NTLM. Warum das für deine Active Directory Umgebung ein Problem darstellen kann und wie Administratoren darauf reagieren sollten, beleuchte ich in diesem Artikel.

Was ist NTLM?

Allgemein

Im Gegensatz zu Kerberos funktioniert die Authentifizierung nicht über sogenannte „KDC-Tickets„, sondern über einen Challenge-Response-Request. Um das Verhalten etwas klarer darzustellen, nehmen wir als Beispiel die Authentifizierung auf einem On-Premises Exchange:

Wir versuchen unser Exchange Postfach im Outlook einzurichten und bekommen das bekannte Windows Anmeldefenster. In diesem Anmeldefenster geben wir Benutzername, sowie Passwort ein, werden am Exchange authentifiziert und dürfen schlussendlich auf das Postfach zugreifen. Doch was passiert im Hintergrund?

Authentifizierungsflow

Folgende Kommunikation findet zwischen Client (Outlook) und dem Server (Exchange) statt:

1. Authentication Request: Der Client sendet im ersten Schritt den Benutzernamen und die Domäne im Klartext an den Server.
2. Challenge: Der Server generiert eine Zufallszahl und sendet diese an den Client zurück.
3. Response: Der Client ermittelt den Hash aus dem durch den Nutzer eingegebenen Passwort, verschlüsselt die Zufallszahl des Servers (Challenge) mit diesem Hash und sendet den daraus resultierenden Wert zurück an den Server. Da der NT-Hash immer deterministisch ist, beweist der Client somit, dass er das echte Kennwort des Nutzers kennt, ohne das Kennwort im Klartext oder den Hash direkt übertragen zu müssen.

Nachdem der Three-Way-Handshake erfolgreich zwischen Server und Client abgearbeitet wurde, muss der Server anschließend die Daten des Clients verifizieren. Hier kommt die Authentifizierungsstelle, unser Domain Controller ins Spiel.

Der Server übermittelt folgende drei Parameter an den Domain Controller:

• Benutzername / Domäne
• Zufallszahl aus der Challenge
• Durch NT-Hash verschlüsselte Zufallszahl aus dem Challenge Response

Der Domain Controller zieht sich nun den tatsächlichen NT-Hash des Nutzers aus der NTDS (Active Directory Datenbank in der alle Nutzerdaten liegen), verschlüsselt damit die Zufallszahl aus der Challenge und überprüft, ob der eigene Wert mit jenem des Client-Responses übereinstimmt. Falls die beiden Werte identisch sind, war die Authentifizierung erfolgreich und der Nutzer darf auf das Postfach zugreifen.

Der Vollständigkeit halber möchte ich noch hinzufügen, dass das eine vereinfachte Darstellung ist. Beispielsweise wurde hier der „Negotiate“ Teil ausgelassen, da das für dieses Beispiel nicht relevant ist.

Was ist ein NT-Hash?

Mittlerweile ist mehrmals der Begriff „NT-Hash“ gefallen und wir sollten in diesem Zuge auch noch einmal kurz umreisen, was das denn überhaupt ist. Bei einem Hash handelt es sich in der Praxis um eine Funktion, der einen leserlichen String (bspw. unser Passwort) in einen nichts aussagenden Hashwert verwandelt. Die Hauptaufgabe des Hashes ist dabei, dass dieser zum einen deterministisch ist und zum anderen unumkehrbar sein muss.

• Deterministisch: Das bedeutet, dass die Funktion auch bei einer mehrfachen Anwendung für jede Eingabe das gleiche Ergebnis liefert.
• Unumkehrbar: Die Funktion muss gewährleisten, dass die Bildung des Hashwerts „einfach“ und mit „so wenig Rechenpower als möglich“ auskommen muss. Umgekehrt darf es aber nicht möglich sein, einen Hashwert auf die ursprüngliche Eingabe zurückzuführen.

So wird beispielsweise aus dem Klartextpasswort „DasIstEinPasswort01!“ der Hashwert „4D5AF35DB554556579C95FCD85F224CA„. Und genau dieser Hashwert wird auch in der Active Directory Datenbank abgelegt und zur Authentifizierung von NTLM verwendet.

Wer das selbst einmal testen möchte, kann folgende Website verwenden: NTLM HASH Generator.

Probleme von NTLM

Veraltete Protokolle

NTLM hat eine lange Historie und wie jedes Protokoll mit einer langen Historie, haben sich auch bei NTLM mit der Zeit Schwachstellen aufgetan. Diese wurde seitens Microsoft zwar mit neuen Iterationen behoben, allerdings bietet das Active Directory aufgrund der Abwärtskompatibilität nach wie vor standardmäßig (fast) alle NTLM-Versionen an:

• LM & NTLMv1
• NTLMv2

Welche Probleme bringt denn NTLMv1 mit? Die Verschlüsselung bei NTLMv1 basiert auf DES (einem Verschlüsselungsstandard aus den 1970er Jahren). DES wird seit Jahrzehnten als unsicher betrachtet. Einer der Gründe ist die Schlüssellänge, die es modernen Rechnern erlaubt, relativ problemlos durch Brute-Force Angriffen den verschlüsselten Wert zu knacken. Damit wird es Angreifern ermöglicht, den NTLM-Challenge-Response Handshake als MITM (Man in the Middle) abzufangen und mittels Brute-Force Angriffen auf den NT-Hash zurückzuführen.

Sobald der NT-Hash bekannt ist, kann dieser durch den Angreifer zur Authentifizierung verwendet werden. Dazu muss nicht einmal das Klartextpasswort bekannt sein.

Pass the Hash

Pass the Hash ist ein Angriffsvektor, der sowohl bei NTLMv1 als auch NTLMv2 ausgenutzt werden kann. Ist der NT-Hash des Nutzers erst einmal bekannt (beispielsweise weil er durch die unsichere NTLMv1 geknackt wurde), kann der Angreifer relativ einfach die Funktionsweise von NTLM ausnutzen, um sich am Server (bspw. auf einem ungesicherten Exchange) zu authentifizieren.

Warum nicht gleich Kerberos?

Nun darf man sich wohl die Frage stellen, warum man nicht einfach vollständig NTLM deaktiviert und ausschließlich auf Kerberos setzt? Kerberos ist definitiv sicherer und bietet eine nicht so große Angriffsfläche, wie es bei NTLM der Fall ist.

Das hängt mit der Art und Weise zusammen, welche Voraussetzungen Kerberos mit sich bringt, damit es verwendet werden kann. Bleiben wir zum besseren Verständnis beim Beispiel Exchange. Wie oben angeführt kontaktiert der Client bei NTLM den Exchange Server. Der Exchange übernimmt dabei die komplette Kommunikation mit dem Client und validiert die Credentials beim Domain Controller. Kerberos funktioniert allerdings vollständig anders. Bei der Kerberos Authentifizierung kommuniziert der Client hauptsächlich mit dem KDC (Domain Controller), bezieht darüber sein Ticket und sendet das Ticket an den Exchange. Durch dieses Ticket wird dem Exchange mitgeteilt, dass der Client autorisiert ist. Hier verschiebt sich also die Authentifizierung in Richtung Client und Domain Controller.

Neben einigen weiteren Hürden wie dem SPN gibt es aber ein großes Problem: Wie kann ein externer Client über das Internet mit einem internen Domain Controller kommunizieren? Genau, gar nicht. Daher bedarf es an einem Protokoll, das eine solche Authentifizierung umsetzen kann und genau hier kommt NTLM ins Spiel. Auch dieses Beispiel ist wieder stark vereinfacht dargestellt, sollte aber die grundsätzliche Problematik etwas klarer machen.

Zusammengefasst bedeutet das: Kerberos kann nur zum Einsatz kommen, wenn der Client netzwerktechnisch Kontakt zum Domain Controller aufnehmen kann. Außerdem muss der Client (oder die Software) Kerberos implementiert haben – das sollte aber klar sein.

Aus diesem Grund sehen wir durchaus die Notwendigkeit NTLM innerhalb der AD-Domäne zu verwenden. Doch wir als Administratoren sollten sicherstellen, dass NTLM so sicher als möglich eingesetzt wird.

Maßnahmen

Warum NTLMv1 unsicher ist und innerhalb einer Active Directory Umgebung nicht verwendet werden soll, dürften wir nun ausreichend beleuchtet haben. Doch wie können wir uns dagegen schützen? Glücklicherweise kann LM & NTLMv1 mittels GPO deaktiviert und somit ausschließlich auf Kerberos und NTLMv2 gesetzt werden. Wie wir das umsetzen können, schauen wir uns im nächsten Beitrag genauer an.