Von: Eric Tierling
Den Enthusiasmus, mit dem Computer-Freaks versuchen, Windows NT zum Absturz zu bringen, hatte Microsoft anfangs wohl nicht erwartet. Und längst ist die Bedrohung aus dem Internet nicht die einzige. Immer mehr Unternehmen berichten, daß bei einigen Mitarbeitern der Spieltrieb geweckt sei: Sie unterzögen die Stabilität der im Intranet vorhandenen Server ausgiebigen Prüfungen.
Einbruch serienmäßig
Zu diesem Verhalten haben zahlreiche Meldungen über die Verletzbarkeit von Windows NT beigetragen. Dazu gehört nicht zuletzt eine Nachricht von Anfang Juli 1997, nach der Hacker den Web-Server von Microsoft zum Stillstand gebracht hätten.
Als Tool kam dabei nicht etwa ein selbstgeschriebenes Utility, sondern das bei Windows 9x und Windows NT serienmäßig mitgelieferte Kommando ping zum Einsatz. Dieser DOS-Befehl nutzt das Protokoll "Internet Control Message Protocol" (ICMP) der TCP/IP-Suite, um ein Echo von einem Host zu erhalten. Indem ein Host auf ping antwortet, läßt sich daraus seine Existenz ableiten.
Ping erlaubt nicht nur die Diagnostizierung der grundlegenden TCP/ IP-Connectivity. Wer Ping ohne weitere Angaben aufruft, bekommt eine Auflistung der einzelnen Parameter angezeigt. Diese lassen sich nutzen, um ein ICMP-Paket mit einer höheren als der üblichen Größe zu senden. Der Ziel-Host empfängt das Ping-Paket in Fragmenten und beginnt daher, es korrekt anzuordnen. Wieder zusammengesetzt, ist das Paket jedoch so groß, daß es den Puffer des Host überlaufen beziehungsweise aus dem Tritt geraten läßt.
Dienstverweigerung
Der TCP/IP-Stack einer standardmäßig operierenden NT-Maschine kann damit nicht korrekt umgehen, so daß die Maschine hängen bleibt oder unter Umständen sogar abstürzt. Aus diesem Grund spricht man von einem "Ping of Death". Durch den Angriff gelangen auch andere Betriebssysteme ins Stolpern - es handelt sich also nicht um ein Microsoft-spezifisches Problem.
Ping of Death führt dazu, daß ein bestimmter Dienst, in diesem Fall der TCP/IP-Stack, nicht mehr zur Verfügung steht. Attacken, welche Services abstellen, sind unter dem Oberbegriff "Denial of Service" zusammengefaßt.
In diese Kategorie fällt auch der "Out-of-Band"-Angriff: Der Sender schickt dem Ziel-Host eine Nachricht an Port 19 oder 139, in dem das Out-of-Band-Flag gesetzt ist. Dieses gibt in der Regel an, daß die nachfolgenden Daten Eilsache sind. Eine NT-Maschine stellt sich darauf ein, doch es folgen gar keine Daten, worauf der Rechner seinen Dienst einstellt.
Bei der "Überflutung" handelt es sich um eine andere Denial-of-Service-Methode. Um das Verfahren zu verstehen, muß man wissen, wie TCP/IP Verbindungen in einem "Handshake" aufbaut. Der Client schickt eine SYN-Anfrage in Form eines TCP/IP-Pakets an den Host. Auf dessen Bestätigung hin antwortet der Client und die Konversation kann beginnen. Beim "SYN-Flooding" schickt der Client ununterbrochen Anfragen mit einer falschen Quell-IP-Adresse, die nicht seiner eigenen entspricht. Konsequenz: Die Antworten des Host landen im leeren Raum. Der Client stellt fleißig weiter Anfragen, was die Ressourcen des Host bindet. Nach ein paar Minuten versucht der Host zwar nicht weiter, auf die Bestätigungsmeldungen seiner Antworten zu warten, bis dahin ist der Rechner jedoch gut beschäftigt.
Eine Variante dieser Attacke stellt "Land" dar, ein Flooding-Angriff, bei dem die Quell-IP-Adresse gleich der Ziel-IP-Adresse ist. Resultat ist eine Schleife, bei der sich der Host selbst antwortet.
Es gibt noch andere Denial-of-Service-Mittel: Bei "Teardrop" beispielsweise schickt ein Client UDP-Pakete, die einen veränderten Header aufweisen, mit denen der Ziel-Host nicht korrekt umzugehen vermag, worauf das System hängenbleibt. Während hiervon auch andere Betriebssysteme betroffen sind, zeigt sich vor allem Windows NT verletzbar, wenn es um das Ansprechen bestimmter Ports geht.
Sinnlose Telnet-Verbindungen
Wer mit Telnet Ports von Diensten anspricht, die nicht auf dem Telnet-Protokoll aufbauen, kann Überraschungen erleben. So führt eine Telnet-Verbindung über den Port 135, gefolgt von der Eingabe mehrerer beliebiger Zeichen und einem Enter, zu einer erhöhten Auslastung des NT-Host, so daß die Maschine zu 100 Prozent mit sich selbst beschäftigt ist. Diese CPU-Attacken funktionieren auch bei anderen Ports - beispielsweise bei 53, falls der DNS-Server auf dem NT-Rechner läuft.
Das System läßt sich sichern, indem bestimmte Dienste erst gar nicht installiert oder geblockt werden. Wer die einfachen TCP/IP-Dienste wie Chargen nicht benötigt - das dürfte in den meisten Fällen zutreffen - sollte diese nicht einrichten oder aus dem Netzwerk von Windows NT entfernen.
Beschränkung auf das Nötige
Eine andere Möglichkeit besteht darin, nur bestimmte Ports freizuschalten. Dies läßt sich über die Eigenschaften des TCP/IP-Protokolls bei der Konfiguration des Netzwerks steuern. Komfortabler geht der Vorgang unter Zuhilfenahme des Tools "Routing and RAS" (RRAS), das als Add-On für den NT-Server zu haben ist (Bild 1).
Generell läßt sich die Registerkarte "Bindungen" bei der Konfiguration des Netzwerks unter WindowsNT nutzen, um in Verbindung mit einzelnen Netzwerkkarten nur solche Dienste zu erlauben, die benötigt werden. So ist es beispielsweise nicht zwingend erforderlich, daß ein Web-Server für die Netzwerkkarte, über welche Anfragen von Web-Clients zu ihm gelangen, auch Netbios oder Wins verwendet.
Weitere Wege, sich unberechtigt Zugang zu Windows NT zu verschaffen, resultieren aus der Konzeption des Betriebssystems. Einen der Schwachpunkte stellt Netbios über TCP/IP dar. Wer NBTSTAT - A eingibt, erhält Informationen über den Ziel-Host wie Domänen- und Benutzernamen. Voraussetzung ist, daß sowohl der Client als auch der Host mit Netbios über TCP/IP (NBT) kommunizieren. Auf dem NT-Host läßt sich das durch Blockieren der Ports 137 bis 139 unterbinden.
Unsichere Paßwörter
Verfahren zum Ermitteln des Paßworts beruhen auf der in Windows NT 4.0 eingebauten Abwärtskompatibilität zum LAN-Manager. Um das zu verstehen, sollte man sich ansehen, wie Windows NT mit Paßwörtern umgeht. Eine gute Informationsquelle ist der Knowledge-Base-Artikel Q102716, der auf dem Ftp-Server von Microsoft zu finden ist (ftp://ftp.micro soft.com/bussys/winnt/kb).
In der Datenbank des "Security Accounts Manager" (SAM) legt das Betriebssystem den Namen eines Benutzers ab. Das Paßwort befindet sich in verschlüsselter Form in der SAM-Datenbank. Jedes Benutzerkonto weist zwei kodierte Paßwörter auf: Ein zum LAN-Manager kompatibles und eines für Windows NT.
Das verschlüsselte Paßwort, das vom LAN-Manager beziehungsweise vom Betriebssystem generiert wird, wird als "Hash" bezeichnet. Grundlage dafür ist das Kennwort, das der Benutzer im Klartext eingegeben hat. Die NT-Ausführung des Paßwort-Hash erfährt eine relativ sichere Verschlüsselung mit dem Verfahren MD4.
Reine Windows-NT-Netze
Das Paßwort des LAN-Managers wird hingegen nur mit DES chiffriert. Hinzu kommt, daß ein LAN-Manager-Paßwort einfacher beschaffen ist. Als Grundlage dient ein 8-Bit-Zeichensatz, so daß 255 Zeichen zur Wahl stehen. Alle Kleinbuchstaben werden automatisch in Großbuchstaben umgewandelt. Von den übrig bleibenden Sonderzeichen lassen sich nur einige, aber nicht alle nutzen. Insgesamt darf das Paßwort eine Länge von maximal 14 Zeichen aufweisen.
Windows NT hingegen benutzt den Unicode-Zeichensatz, der 65536 Zeichen umfaßt. Zwischen Groß- und Kleinschreibung findet dort eine Unterscheidung statt, und die Paßwort-Länge kann bis zu 128 Zeichen betragen.
Hacker-Software, die eine "Brute-Force"-Attacke vornimmt, versucht das LAN-Manager-kompatible Paßwort für einen Benutzernamen zu entschlüsseln. Das wohl bekannteste Tool dieser Kategorie heißt "L0phtcrack". Es kursieren auch Brute-Force-Programme, die es auf den MD4-kodierten NT-Hash abgesehen haben. Solange das Paßwort lediglich einfache Buchstaben enthält und kurz ist, besteht Aussicht auf Erfolg.
Ideal wäre es, die LAN-Manager-konforme Verschlüsselung nicht zu verwenden. Das geht jedoch nur dann, wenn sich ausschließlich NT-Clients im Intranet befinden, die nur solche Paßwörter verwenden, für die kein LAN-Manager-konformer Hash möglich ist. Es genügt, wenn das Kennwort die Länge von 14 Zeichen überschreitet. In diesem Fall wird lediglich der NT-Paßwort-Hash generiert.
Andere Clients wie beispielsweise Windows-9x-Rechner arbeiten noch mit dem vom LAN-Manager her bekannten Protokoll. Sie kennen die NT-konforme Verschlüsselung nicht, was dazu führt, daß neben dem NT-Hash auch der LAN-Manager-konforme erzeugt wird.
Seit dem Service Pack 2 gibt es darüber hinaus einen Paßwort-Filter als DLL. In den SYSTEM32-Ordner kopiert und über einen Registry-Eintrag aktiviert, zwingt diese Funktion zur Verwendung von Paßwörtern mit einer Länge von mindestens sechs Zeichen. Der Benutzername oder Teile davon dürfen nicht vorkommen. Außerdem muß jedes Paßwort Zeichen aus mindestens drei der folgenden Klassen enthalten: Großbuchstaben, Kleinbuchstaben, Ziffern und nicht-alphanumerische Zeichen wie Punkt, Komma oder Semikolon. Details sind der Readme-Datei des Service Pack zu entnehmen.
Zugriff auf SAM
Es stellt sich die Frage, wie ein Eindringling an die SAM-Datenbank gelangt. Sie befindet sich als Datei SAM im Ordner %systemroot%\system32\config. Weil die Datei vom System genutzt wird, ist sie ständig geöffnet und läßt sich daher nicht kopieren.
Während der Installation und bei jeder Erstellung einer Notfalldiskette legt das Betriebssystem im Ordner %systemroot%\repair eine Kopie der SAM-Benutzerdatenbank in Form der Datei SAM._ ab. Für diesen Ordner besitzt die Gruppe "Jeder" Leserechte. Alle Anwender, die über das Benutzerrecht "Lokale Anmeldung" verfügen, können sich lokal am NT-Server anmelden und anschließend auf die Kopie der SAM-Benutzerdatenbank zugreifen. Standardmäßig nennen nicht nur die Gruppe "Administratoren", sondern auch zahlreiche Operatoren-Gruppen dieses Benutzerrecht ihr eigen.
Wer nicht allen Benutzern traut, die zu einer dieser Gruppen gehören, sollte die Mitgliedschaften restriktiv handhaben. Die Notfalldiskette ist an einem sicheren Ort aufzubewahren, denn das Utility Rdisk legt auch dort eine Kopie der Datei SAM._ ab.
Um die Auslesbarkeit der SAM-Benutzerdatenbank und ihrer Kopien zu verbessern, hat Microsoft ab dem Service Pack 3 das Programm "Syskey" eingeführt (Bild 2). Durch seinen Aufruf findet eine 128-Bit-Verschlüsselung der SAM-Benutzerdatenbank statt, was ein simples Auslesen der Dateien SAM und SAM._ verhindern soll. Weitere Details hierzu offeriert der Knowledge-Base-Artikel Q143475 (ftp://ftp.microsoft.com/bussys/winnt /kb).
Verschlüsselte Paßwortübertragung
"Server Message Block" (SMB) ist ein Protokoll, das mehreren Rechnern den Zugriff auf gemeinsam genutzte Ressourcen wie Dateien und Drucker erlaubt. Im Laufe der Jahre sind verschiedene SMB-Varianten entwickelt worden.
Zur Wahrung der Verständigungfähigkeit mit älteren LAN-Manager-Dialekten und anderen SMB-Server-Implementationen sendet Windows NT das zur Authentisierung erforderliche Paßwort eines Benutzernamens auf Anforderung unverschlüsselt.
Durch Aufspielen des Service Pack 3 überträgt der SMB-Redirector von Windows NT solche Paßwörter nur noch verschlüsselt. In der Readme-Datei des Service Pack finden sich weitere Hinweise hierzu. Zusätzlich gibt es die Option, SMB-Übertragungen signieren zu lassen, um Manipulationen der darin enthaltenen Informationen zwischen Sender und Empfänger auszuschließen.
Mitunter existieren aber auch kritische Funktionen im Betriebssystemkern, die nichts mit TCP/IP, Paßwörtern oder Protokollen zu tun haben. Ein Beispiel hierfür bildet "Getadmin", ein Utility, das einen Benutzer unberechtigt zum Mitglied der Administratoren-Gruppe erhebt. Weitere potentielle Risiken liegen in der Art und Weise, in der die Registry Zugriffe gestattet, die einen Mißbrauch erlauben. Während einige Fehler von Windows NT im Design des Betriebssystem-Kerns zu finden sind, ergeben sich andere Lücken aus der Bemühung um Abwärtskompatibilität und aus TCP/IP-Schwächen, von denen andere Systeme gleichfalls betroffen sind. (kpl)