Mit roher Gewalt

Windows-Passwörter werden verschlüsselt auf Rechnern abgelegt und im Netzwerk übertragen. Trotzdem gibt es Methoden und Tools, um an die Klartextpasswörter zu gelangen. Nur wer deren Tricks kennt, kann sich zuverlässig schützen.

02.10.2003, 15:11 Uhr

Lesezeit: 11 Min.

Security

Von

Daniel Bachfeld

Um unautorisierte Zugriffe auf Windows-PCs zu verhindern, kann man eine vorherige Authentifizierung erzwingen. Den meisten Anwendern ist dies als Windows-Login bekannt, der mit CTRL-ALT-DEL aufgerufen wird. Nur zugelassene Benutzer können sich mit Name und Passwort lokal . Ist der Rechner in ein Windows-Netz eingebunden, meldet man sich in der Regel am Domänen-Controller an. Die Eingabemaske ist die gleiche, mit dem Unterschied, dass man statt des Rechnernamens den Namen einer Domäne auswählt. Der Domänen-Controller verwaltet die Zugriffsrechte der Anwender auf Netzwerk-Ressourcen beziehungsweise die Rechte der Anwender in einer Domäne. Angemeldete Benutzer erhalten einen so genannten Access-Token, mit dem man sich anderen Systemen gegenüber autorisieren kann. Zum Schutz der Anmeldedaten vor dem Ausspähen auf dem lokalen PC und während der Übertragung im Netzwerk verschlüsselt Windows die übertragenen Daten. Spezielle Programme knacken aber auch die eingesetzte Verschlüsselung der Anmeldeinformationen.

Teile und herrsche

Die ersten Implementierungen eines Domänenkonzeptes wurden mit dem LanManager (LM) realisiert. DOS-, Windows- und OS/2-Clients konnten in einer Domäne auf Unix- und OS/2-Server zugreifen. Die Authentifizierung erfolgt über ein Challenge/Response-Verfahren. Dabei wird im Netzwerk nie das Passwort selbst übertragen, weder verschlüsselt noch im Klartext, sondern eine so genannte verschlüsselte Response als Antwort auf eine vom Server gesendete Challenge.

Passwörter speichert Windows auf Clients und Servern immer verschlüsselt. Dazu wandelt es das Passwort in eine 14-Byte-lange Zeichenkette um, in dem es zu lange Wörter abschneidet beziehungsweise zu kurze mit Nullen verlängert und alle Kleinbuchstaben in Großbuchstaben umwandelt. Zusätzlich dreht es alle Bytes um (reversed) und teilt die Zeichenkette in zwei 7-Byte-Ketten auf. Diese verwendet Windows als 56-Bit-DES-Schlüssel (7x8), um eine, in jedem Windows-PC gleiche, 8-Byte-Kette ("KGS!@#$%") zu verschlüsseln. Fügt man die zwei verschlüsselten 8-Byte-Strings wieder zusammen, erhält man einen 16 Byte langen Hash, der auf dem Client und dem Server als LanManager-Hash gespeichert wird.

Windows erzeugt den LM-Hash mit zwei 56-Bit-DES-Schlüsseln.

Die Schwächen dieser Methode liegen auf der Hand: Das Passwort ist maximal 14 Zeichen lang und verwendet nur Großbuchstaben, statt eines 112-Bit-Schlüssels (14x8) werden zwei 56-Bit-Schlüssel benutzt. Zwei kurze Schlüssel lassen sich aber schneller berechnen, als ein langer. Ist das Passwort nur 7 Byte lang, besteht ein Schlüssel sogar nur aus Nullen. Da beim Erzeugen des LM-Hashes eine zufällige Komponente fehlt, erzeugt das gleiche Passwort immer den gleichen Hash. Ein Angreifer kann damit riesige Hash-Tabellen vorberechnen, um später das Passwort zu knacken. Der Advanced Instant NT Password Cracker [8] implementiert genau diese Methode: Mit Tabellen von 2 GByte kann er 99 Prozent der Passwörter in weniger als einer Minute knacken.

Wiedervereinigung

Mit der Einführung von Windows NT hat Microsoft ein neues Verfahren etabliert, das einige Schwächen des LanManager beseitigt: NT LanManager (NTLM). Das Passwort wird weiterhin auf 14 Bytes angepasst, allerdings wird der String nun in Unicode umgewandelt, um Groß- und Kleinschreibung zu erhalten. Mit dem Hash-Algorithmus MD4 wird im Anschluss ein 16 Byte (128 Bit) langer NTLM-Hash erzeugt und in einem Stück gespeichert. Einige Schwächen bleiben jedoch: Zu kurze Passwörter füllt NT mit Nullen auf und Hashes können vorberechnet werden, da es immer noch keine Zufallswerte zum Erzeugen des Hashes verwendet. Aus Kompatibilitätsgründen erzeugt und speichert NT weiterhin zusätzlich den LM-Hash. Sowohl der LM-Hash als auch der NTLM-Hash werden lokal vorgehalten, üblicherweise in der Security Account Manager Database (SAM) als Registry-Eintrag (HKEY_LOCAL_MACHINE\SAM\SAM), auf W2K/2003-Domänen-Controllern auch im Active Directory.

NT erzeugt den NTLM-Hash in einem Stück.

Da Windows beide Hashes erzeugt, geht der Vorteil der verbesserten NTLM-Verschlüsselung verloren. Ein Angreifer versucht, zuerst an den einfacher zu knackenden LM-Hash zu gelangen, um aus ihm das Passwort zu berechnen. Angriffe gegen LM-Hashes dauern, je nach Rechenleistung und Qualität des Passwortes, von wenigen Sekunden bis zu einigen Wochen, bei NTLM-Hashes wesentlich länger. Zwar kann man ab Windows 2000 SP2 das Speichern des LM-Hashes deaktivieren. Tut man dies auf einem Domänen-Controller, können sich aber Windows-98-Clients nicht mehr .

Knack die Nuss

Bei L0phtcrack kann man die Quelle der Hashes selbst bestimmen.

Das bekannteste Tool zum Knacken von Hashes ist L0phtCrack Version 4.0 (LC4) [1]. Für 350 Dollar bekommt man ein grafisches Universal-Werkzeug zum Testen der Qualität von Windows-Passwörtern oder um sich an vergessene Passwörter zu "erinnern". Natürlich lässt sich solch ein Werkzeug auch für Angriffe missbrauchen, sofern man an die LM- und NTLM-Hashes herankommt. Auf die SAM kann nach dem Start nur das SYSTEM-Konto zugreifen, alle anderen Zugriffe, wie etwa mit dem Registry-Editor, werden verwehrt. Mit einigen Tricks greift LC4 trotzdem auf die SAM zu, ein Administratorkonto vorausgesetzt. Alternativ kann man auch im Repair-Ordner auf die Sicherungskopie der SAM zugreifen oder mit Linux oder NTFS-DOS booten und auf die Hashes zugreifen. Mit dem Tool SYSKEY reagierte Microsoft auf dieses Problem. Der Zugriff auf die Hashes ist zwar weiterhin möglich, SYSKEY chiffriert sie aber mit einem zusätzlichen 128-Bit-Schlüssel. LC4 und Tools wie pwdump2 [2] knacken aber auch diese Verschlüsselung, immerhin ist damit ein Schritt mehr zum Ziel erforderlich.

LC4 versucht zunächst eine Wörterbuch-Attacke gegen die Hashes, indem es eine Wortliste durchprobiert. Schwache Passwörter lassen sich damit in relativ kurzer Zeit ermitteln. Führt die Wörterbuchattacke nicht zum Ziel, startet LC4 einen Brute-Force-Angriff, indem es mit wachsender Wortlänge alle möglichen Kombinationen alphanumerischer Zeichen plus Sonderzeichen durchprobiert. Derartige Angriffe dauern natürlich ungleich länger, insbesondere wenn die Passwörter sorgfältig ausgewählt wurden. Beim Hybrid-Angriff kombiniert LC4 Elemente aus der Wortliste mit weiteren Zeichen.

Andere Tools wie John-the-Ripper [3] und Cain & Abel [4] verfügen über ähnliche Funktionen zum Knacken der Hashes. Beide sind kostenlos und ebenfalls sehr leistungsfähig.

Ping Pong

Die Response wird aus der Challenge berechnet.

Ist der lokale Zugriff auf ein System nicht möglich, kann LC4 auch im Netzwerk mitlauschen, um die Hashes aus Anmeldeinformationen zu gewinnen. Zur Benutzer-Authentifizierung im Netzwerk sendet der Domänen-Controller (DC) einen 8-Byte-langen pseudo-zufälligen Wert (Challenge) über das Netzwerk an den Client. Sowohl der LM-Hash, als auch der NTLM-Hash, werden mit 5 Nullen auf 21 Bytes erweitert und in drei Schlüssel à 56-Bit aufgeteilt. NT chiffriert die Challenge mit jedem Schlüssel einmal und sendet die drei 8-Byte-Ketten als 24-Byte-Response an den DC zurück. Der DC führt die gleiche Prozedur durch und vergleicht die Antwort des Clients mit dem eigenen Resultat. Sind diese identisch, hat der Benutzer das richtige Passwort eingegeben.

In der Grundeinstellung knackt LC4 keine Passwörter, die Sonderzeichen enthalten, einfache Passwörter berechnet LC4 innerhalb weniger Minuten.

Anhand der übertragenen Challenge und Response versucht LC4, Rückschlüsse auf das Passwort zu ziehen. Mit einer Wörterbuch- oder Brute-Force-Attacke versucht es, das Passwort zu ermitteln, indem es die unverschlüsselt vom DC gesendete Challenge mit Hashes verschlüsselt, bis sie mit der Response identisch ist.

Auch hier versucht ein Angreifer zuerst die schneller berechenbare LM-Response nachzubilden. Windows hilft hier sogar: Aus Kompatibilitätsgründen antworten Windows-Clients in der Grundeinstellung auf eine Challenge sowohl mit einer LM-, als auch mit einer NTLM-Response. Mit der LM-Kette errechnet man das LM-Passwort und variiert dann dessen Groß- und Kleinschreibung, um auch das NTLM-Passwort zu rekonstruieren. Seit Service Pack 4 für Windows NT 4.0 kann man den Kompatibilitätsmodus abschalten und nur noch NTLM-Antworten zulassen.

Harte Nuss

Erhebliche Verbesserungen bei der Übertragung der Response brachte NTLMv2 mit sich, das seit NT 4.0 SP4 verfügbar ist. Der NTLM-Hash wird zwar weiterhin verwendet, allerdings wird die Client-Antwort sehr viel aufwendiger berechnet. Aus dem Benutzer- und Domänennamen wird mittels HMAC-MD5 und dem NTLM-Hash ein 16-Byte-NTMLv2-Hash gebildet. Zusätzlich bildet der Client einen 32-Byte-Block, in dem ein Zeitstempel, die Server-Challenge und eine zufällige Client-Challenge enthalten sind, aus dem er mittels HMAC-MD5 und dem NTMLv2-Hash einen neuen 16-Byte-Wert berechnet. Daran hängt er den 32-Byte-Block im Klartext und schickt das Ganze als NTLMv2-Response an den DC.

Die NTLM-Response kann aufgrund der Client-Challenge nicht mehr vorberechnet werden.

Aufgrund der zufälligen Client-Challenge und des Zeitstempels, beide ergeben das so genannte Salt, ist das Vorberechnen von NTLMv2-Hashes nicht mehr möglich. Zudem ist eine NTLMv2-Response nur über einen kurzen Zeitraum gültig, um Replay-Attacken zu erschweren. Im Netzwerk aufgefangene NTLMv2-Responses können nicht mehr mit vertretbarem Zeit- oder Rechenaufwand durch Wörterbuch- oder Brute-Force-Angriffen geknackt werden. Ein Cluster [5] mit sechzehn 1,4GHz Athlon-CPUs benötigte bei einem achtstelligem Passwort 21 Monate zur Berechnung, bei sechs Zeichen allerdings weniger als vier Stunden.

Hintertüren

Leider ist NTLMv2 in Windows-Netzwerken standardmäßig nicht aktiviert, stattdessen überträgt selbst Windows 2003 Server immer noch LM- und NTLM-Hashes im Netzwerk. Seit Windows 2000 ist zwar Kerberos V5 als Authentifizierungsmechanismus implementiert und standardmäßig auch die bevorzugte Methode. Allerdings funktioniert dies nur in reinen W2K-Domänen zuverlässig, andernfalls schaltet Windows automatisch wieder in den LM/NTLM-Mode. Dort hat man aber die Wahl aus sechs Kompatibilitätsstufen, erst in der höchsten benutzen Domänen-Controller, Memberserver und Clients auschließlich NTLMv2. In einigen heterogenen Netzen ist diese Einstellung jedoch nicht möglich, da Server, beziehungsweise Applikationen von Drittherstellern kein NTLMv2 unterstützen. Auch Windows 98 benötigt die Active Directory Client Extension, um sich in solchen Netzen zu können. Setzt man Samba als File-Server ein, so steht erst ab Version 3.0 NTLMv2-Support zur Verfügung.

Fazit

Die Sicherheit in Windows-Netzen ist im Wesentlichen von zwei Faktoren abhängig: Die Qualität der Passwörter und dem Einsatz starker Kryptographie. Beides sinnvoll kombiniert, erschwert Angreifern die Möglichkeit Passwörter zu knacken, -- der Zeitaufwand steigt extrem an. Ein Passwort sollte mindestens 8 Zeichen lang sein und zudem über Sonderzeichen verfügen. Der Schlüsselraum vergrößert sich damit erheblich, Programme wie LC4 und John-the-Ripper benötigen sehr lange, um aus dem Hash das Passwort zu berechnen. In der Grundeinstellung berücksichtigt LC4 ohnehin nur alphanumerische Zeichen und kann solche Hashes nicht berechnen. Verhindert man dann noch das lokale Speichern [6] des LM-Hashes und verwendet im Kompatibilitäsmodus nur noch NTLMv2 [7], nimmt man einem Hacker den Großteil der Angriffsfläche. Wenn möglich sollte man in Windows-Netzen gleich Kerberos einsetzen, dies erhöht die Sicherheit ein weiteres Stück. Leider hat das Wettrennen auch hier schon begonnen, Passwort-Cracker [9] sind für Kerberos mittlerweile frei verfügbar.