Schau mal, ein Regenbogen! - Wieso Google dich bei NTLM zum Handeln zwingt
1007457
wp-singular,post-template-default,single,single-post,postid-1007457,single-format-standard,wp-theme-bridge,wp-child-theme-bridge-child,bridge-core-3.3.4.6,metaslider-plugin,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.8.8.6,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-8.7.2,vc_responsive
Blog Headerbild ntlm.png

Schau mal, ein Regenbogen! – Wieso Google dich bei NTLM zum Handeln zwingt

Schau mal, ein Regenbogen

So schön ein Regenbogen als Naturschauspiel auch sein mag, mit der von Google angekündigten Veröffentlichung von Rainbow Tables hat das nichts zu tun. Rainbow Tables sind ein probates Mittel, um NTLMv1 Passwörter innerhalb von Minuten und mit handelsüblicher Hardware zu entschlüsseln und damit den betreffenden Account unter Kontrolle zu bekommen. Geschieht dies für einen hochprivilegierten Account, wie zum Beispiel das Computerkonto des Domain Controllers, kann unbemerkt jeder andere Account kompromittiert werden.

All das wurde schon Ende der 90er herausgefunden und gängige Härtungsempfehlungen (wie z.B. von Microsoft oder CIS) drängen seit Jahren darauf, NTLMv1 zu deaktivieren. Durch die Veröffentlichung der Rainbow Tables wird der Handlungsdruck jedoch nochmal deutlich erhöht.

Konkret sollten also folgende Maßnahmen kurzfristig vorgenommen werden:

        1. Abschaltung von LM/NTLMv1 über Gruppenrichtlinie
        2. Überwachung der Domain Controller Logs auf die Verwendung von LM oder NTLMv1 und entsprechende Alarmierung

NTLM, die Zweite

Was NTLMv1 betrifft, ist damit die „Kuh vom Eis“. Jedoch wurden auch in der bereits 1998 eingeführten Nachfolgeversion NTLMv2 über die Jahre eklatante Schwachstellen entdeckt. Inzwischen ist vor allem die nicht mehr zeitgemäße HMAC-MD5 Verschlüsselung eine für Angreifer leicht zu überwindende Hürde. NTLM ist ein Challenge/Response-Verfahren und damit Design-bedingt für Pass-the-Hash, NTLM-Relaying und Offline-Cracking anfällig.

Die Alternative zu NTLM* heißt Kerberos und ist bereits seit dem Jahr 2000 in Active Directory integriert. Wichtigster Unterschied zu NTLM ist die Einbindung eines Key Distribution Center (KDC) Dienstes auf den Domain Controllern. Kerberos arbeitet mit Tickets und fordert eine beiderseitige Authentifizierung. Die parallele Unterstützung verschiedener Verschlüsselungstypen (Cipher Suites) erlaubt die Verwendung der höchstmöglichen Verschlüsselungsstufe (aktuell AES-256) bei Erhalt einer definierten Abwärtskompatibilität.

Kerberos ist deshalb seit Jahren Standard in Active Directory.

* Eine weitere Alternative zu NTLM ist OAuth. Dieses moderne Verfahren basiert jedoch auf Web-Tokens und spielt deshalb für Active Directory-integrierte Dienste nur eine untergeordnete Rolle.

Also schnell weg mit NTLM, oder?

Dank Kerberos ist der Weg grundsätzlich frei, um NTLM komplett abzuschalten. Und TEAL empfiehlt, dieses Ziel konsequent zu verfolgen.

Leider existiert jedoch oft gerade in historisch gewachsenen Umgebungen eine relevante Zahl an Anwendungsfällen bzw. Produkten, bei denen NTLM unumgänglich ist oder Kerberos aufgrund technischer Abhängigkeiten schlicht nicht einsetzbar ist. Der Fallback auf NTLM kann deshalb deutlich häufiger sein, als vermutet, und bei vorschneller Abschaltung von NTLM ungeahnte Probleme verursachen.

Eine Voraussetzung für Kerberos ist die Vertrauensstellung zwischen den beteiligten Systemen:

    • dem System, auf dem die Authentifizierung initiiert wurde
    • dem Domain Controller
    • dem Zielsystem

Für Mitglieder (sprich: Windows Systeme) einer Domain ist diese Vertrauensstellung grundsätzlich gegeben.

Darüber hinaus erfordert Kerberos eine jederzeit funktionierende Namensauflösung (DNS) und die Verwendung des Fully-Qualified Domain Name (FQDN) des Zielsystems. So bewirkt zum Beispiel schon die Verwendung von Netbios Namen oder IP-Adressen in RDP-Verbindungen einen Fallback auf NTLM.

Außerdem ist es wichtig, dass alle beteiligten Systeme nach derselben Uhr ticken. Ein Zeitunterschied von mehr als 3 Minuten kann bereits zu Fehlern im Authentifizierungsprozess führen. Deshalb dienen idealerweise die DCs als Quelle für die Synchronisation des Zeitsignals.

Wir raten deshalb zur Abschaltung von NTLM nach folgendem groben Fahrplan:

      1. Sicherstellung der Kerberos Voraussetzungen auf allen betreffenden Systemen
      2. Überwachung der NTLM-Authentifizierungsvorgänge mit Hilfe konsolidierter Event Logs
      3. Identifikation und Behebung der betreffenden Anwendungsfälle und Dienste
      4. Test und Pilotierung
      5. Vollständige Abschaltung von NTLM

Du möchtest mehr zum Blogbeitrag erfahren und dich mit einem Experten von TEAL dazu austauschen, dann buche hier ein Beratungsgespräch!

LATEST POSTS